Subject: [rbridge] announcing vlans question

From: "Jeff Pickering" <[email-masked]>
Date: Mon, 15 Feb 2010 06:18:32 -0800

If a non-drb is configured to announce on all vlans, but does not have the vlan enabled that is the designated vlan
announce by the drb, the non-drb will send helos only on vlan for which it is avf. But if such an rb is not avf on any
vlans, it looks like it will send no hellos. Or does such an rb not accept the drb's desginated vlan in such a case?
Is there text addressing this is the spec?  All I see is the following from 4.4.3:

RBridges send TRILL Hellos Outer.VLAN tagged with

   the Designated VLAN, unless that VLAN is not enabled on the port.

Jeff
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 15 Feb 2010 12:22:56 -0500

Hi Jeff,

On Mon, Feb 15, 2010 at 9:18 AM, Jeff Pickering <[email-masked]>wrote:

> announce by the drb, the non-drb will send helos only on vlan for which it
> is avf.
>

This is all on a per port basis.

I assume you mean by "configured to announce on all vlans" that the
Announcing Set for that port is set to all VLANs. Yes, in that case the
non-drb's port will send Hellos only on VLANs for which it is an appointed
forwarder.

Generally speaking, if there are RBridge ports that don't have the
designated VLAN enabled, arguably your network is mis-configured. Most
commonly one would expect all the RBridges in a campus to be configured to
designated the same VLAN if they are DRB and one would expect that that VLAN
would be enabled on all RBridge ports connected to inter-RBridge links. But,
of course, more complex configurations may be fine.

> But if such an rb is not avf on any
> vlans, it looks like it will send no hellos. Or does such an rb not accept
> the drb's desginated vlan in such a case?

Right, the RBridge port does not send any Hellos, because sending Hellos
would generally just add useless traffic. Consider:

(1) Since the designated VLAN is disabled at the port, no inter-rbridge
traffic can flow through the port (i.e., no TRILL encapsulated data or LSPs
...)

(2) Since the port is not an appointed forwarder for any VLAN, no native
traffic can flow through the port (i.e., no data will be picked up and
encapsulated and no data will be decapsulated and sent.

So the port is basically orphaned from the link, although there still are
frames that could flow on the port, such as LLDP frames.

There was considerable controversy in the working group over how many Hellos
to send and the provisions in the current draft are the compromise that was
arrived at. The parenthetical at the top of page 51 of the draft
contemplates sending more Hellos than called for by the set operation
expressions.

Thanks,
Donald

Jeff

---

From: Anil Rijhsinghani <[email-masked]>
Date: Mon, 15 Feb 2010 13:23:48 -0500

Donald,

> non-drb's port will send Hellos only on VLANs for which it is an appointed

If the desig-vlan is not enabled on the non-drb rbridge, then it can't be appointed forwarder for anything as it can't communicate with the DRB. Right?

There's a chicken and egg issue here: during DRB election -- when the desig VLAN isn't yet established -- what's the outer VLAN tag? It's not specified.

The draft should probably state that the default VLAN 1 is used in the outer tag during election.

> would be enabled on all RBridge ports connected to inter-RBridge links.

Elsewhere in the draft, there's this: "TRILL requires at least one VLAN per link that gives full connectivity to all the RBridges on that link. The default VLAN is 1, though RBridges may be configured to use a different VLAN. "

This implies we need a per-port "Trill Vlan" in the MIB, which is enabled in all Rbridges on the link and should (must?) be used as desig vlan on that link. The default value of this is 1.

When you're as config-free as possible, 1 is used for outer VLAN in all Trill frames on all links.

Regards,
Anil

---

From: "Jeff Pickering" <[email-masked]>
Date: Mon, 15 Feb 2010 11:35:21 -0800

I understand the "cosiderable controversy" and think the argument goes something like this:

- there should be a single designated vlan which is shared enabled among all rbs, in which case sending hellos only on that dvid is sufficient and safe.
- but there may be a misconfiguration where this is not the case and multiple rbs may be appointed avf causing loops if you only send on the dvid.
- to solve this problem the full announcing set is defined in the spec. this may still, in patholgical cases, result in multiple rbs being
  appointed avf for the same vlan, but the AF bit and inhibition will result in only a single forwarder per-vlan.
- in order to ensure safety in the zero configuration case, the full announcing set is the default.

I am still concerned with scalability in cases of lots of adjs and lot of vlans, but also want to allow for "misconfiguration". I think there could be a way
to start announcing on the "full set" as defined and then fall back to only the dvid if yoiu discover the dvid is enabled on all rbs on a link. It would
work like this:

- An rb that is not DR would only choose as desginated vlan one of its enabled vlans. Its view of the dvid would be included in the vlaf subtlv.
- Such an rb that could not accept the DRs view of the dvid would continue to hello on its view if the dvid.
- All rbs announce on the full set (per-spec DR status dependent) when an interface is enabled or the vlan set changes.
- When any rb hears a hello that has in its vlaf subtlv a dvid value not equal to its dvid, it sets a timer.
- When the timer expires, an rb can fall back to only sending on the dvid.

I dont think this requires any spec change except for a non-dr refusing to accept as dvid a non-enabled vlan id. This would not affect anyone not
desiring to implement the above. And it would also address the case of an RB sending absolutely no hellos, which IMO is extermely counter-intuitive and
will cause network managers a lot of confusion.

Jeff

________________________________
From: Donald Eastlake [mailto:[email-masked]]
Sent: Monday, February 15, 2010 12:23 PM
To: Jeff Pickering
Cc: [email-masked]
Subject: Re: [rbridge] announcing vlans question

Hi Jeff,

On Mon, Feb 15, 2010 at 9:18 AM, Jeff Pickering <[email-masked]<mailto:[email-masked]>> wrote:

If a non-drb is configured to announce on all vlans, but does not have the vlan enabled that is the designated vlan
announce by the drb, the non-drb will send helos only on vlan for which it is avf.

I assume you mean by "configured to announce on all vlans" that the Announcing Set for that port is set to all VLANs. Yes, in that case the non-drb's port will send Hellos only on VLANs for which it is an appointed forwarder.

Generally speaking, if there are RBridge ports that don't have the designated VLAN enabled, arguably your network is mis-configured. Most commonly one would expect all the RBridges in a campus to be configured to designated the same VLAN if they are DRB and one would expect that that VLAN would be enabled on all RBridge ports connected to inter-RBridge links. But, of course, more complex configurations may be fine.

Right, the RBridge port does not send any Hellos, because sending Hellos would generally just add useless traffic. Consider:

(1) Since the designated VLAN is disabled at the port, no inter-rbridge traffic can flow through the port (i.e., no TRILL encapsulated data or LSPs ...)

(2) Since the port is not an appointed forwarder for any VLAN, no native traffic can flow through the port (i.e., no data will be picked up and encapsulated and no data will be decapsulated and sent.

So the port is basically orphaned from the link, although there still are frames that could flow on the port, such as LLDP frames.

There was considerable controversy in the working group over how many Hellos to send and the provisions in the current draft are the compromise that was arrived at. The parenthetical at the top of page 51 of the draft contemplates sending more Hellos than called for by the set operation expressions.

Thanks,
Donald

Jeff

_______________________________________________
rbridge mailing list
[email-masked]<mailto:[email-masked]>
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: "Jeff Pickering" <[email-masked]>
Date: Mon, 15 Feb 2010 11:51:31 -0800

btw:  lets say an rb doesnt send any hellos per the case mentioned. Then lets say it enables a vlan on which
nobody is avf. How does it send something to the DR to let it know that it shoudl get appointed?

Jeff

Hi Jeff,

Thanks,
Donald

Jeff

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 15 Feb 2010 16:14:55 -0500

Hi Anil,

On Mon, Feb 15, 2010 at 1:23 PM, Anil Rijhsinghani <[email-masked]> wrote:

> Donald,
>
> > On Mon, Feb 15, 2010 at 9:18 AM, Jeff Pickering <[email-masked]
> >wrote:
> >
> > >
> > > If a non-drb is configured to announce on all vlans, but does not have
> the
> > > vlan enabled that is the designated vlan
> If the desig-vlan is not enabled on the non-drb rbridge, then it can't be
> appointed forwarder for anything as it can't communicate with the DRB.
> Right?

Not really. By default, bridge ports will accept frames in any VLAN.
Disabling a VLAN on a port just stops the bridge from outputting frames in
that VLAN unless you have the bridge port parameter "Enable Ingress
Filtering" turned on. RBridge ports are exactly list 802.1Q-2005 ports in
regards VLAN processing. So it is quite possible for an RBridge to see TRILL
Hellos on the Designated VLAN from the DRB on a port where that VLAN is not
enabled. And, in any case, it might see its appointment in Hellos on other
VLANs.

> There's a chicken and egg issue here: during DRB election -- when the desig
> VLAN isn't yet established -- what's the outer VLAN tag? It's not specified.
>

I actually don't like the word "election" for what happens, although it is
the official IS-IS term that everyone uses. It seems to imply a start/stop.
It is really a continuous process whereby each RBridge determines who it
believes is the DRB and acts accordingly.

Also, while the network always has to be safe, it is probably not worth
worrying all that much about bizarre configurations where the RBridges on a
link have different ideas about what the Designated VLAN should be and/or
have the Designated VLAN not enabled on a port and the like...

> outer tag during election.

This is discussed in the last paragraph of 4.4.3. If a bunch of RBridge
ports come up simultaneously on a link, they will all initially transmit a
Hello specifying the Designated VLAN to be what they want it to be. This
will be resolved as soon as they see Hellos from any other RBridges on the
link.

> Elsewhere in the draft, there's this: "TRILL requires at least one VLAN per
> link that gives full connectivity to all the RBridges on that link. The
> default VLAN is 1, though RBridges may be configured to use a different
> VLAN. "
>
> This implies we need a per-port "Trill Vlan" in the MIB, which is enabled
> in all Rbridges on the link and should (must?) be used as desig vlan on that
> link. The default value of this is 1.
>

That sentence is right after a paragraph talking about how certain
configurations can cause partitions of a link. But in any case, all this is
in Section 2 which is explicitly labeled in its first sentence as giving a
high level overview omitting some details. There is no "TRILL VLAN" per port
other than the already specified Desired Designated VLAN and actual
Designated VLAN per port.

> Trill frames on all links.

Right.

Thanks,
Donald

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 15 Feb 2010 17:28:13 -0500

> nobody is avf. How does it send something to the DR to let it know that it

It doesn't, at least not within the TRILL protocol as specified. But why is
it so important for a misconfigured RBridge to be able to try to get itself
made an appointed forwarder?

There is an Enabled VLANs sub-TLV that an RBridge can optionally include in
Hellos and that a DRB could use, if it was so implemented, as one element in
determining which RBridges to make appointed forwarders. Just fix the
configuration of this misconfigured RBridge and it could send that sub-TLV
in a Hello to the DRB. But how the DRB figures out or is configured to
appoint other RBridges on a link as appointed forwarders is left for
implementations to decide. By default, the DRB is the appointed forwarder
for all VLANs.

Thanks,
Donald

>  ------------------------------
> *From:* Donald Eastlake [mailto:[email-masked]]
> *Sent:* Monday, February 15, 2010 12:23 PM
> *To:* Jeff Pickering
> *Cc:* [email-masked]
> *Subject:* Re: [rbridge] announcing vlans question
>
> Hi Jeff,
>
> There was considerable controversy in the working group over how many
> Hellos to send and the provisions in the current draft are the compromise
> that was arrived at. The parenthetical at the top of page 51 of the draft

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 15 Feb 2010 17:18:34 -0500

Hi Jeff,

On Mon, Feb 15, 2010 at 2:35 PM, Jeff Pickering <[email-masked]>wrote:

> - there should be a single designated vlan which is shared enabled among
> all rbs, in which case sending hellos only on that dvid is sufficient and
> safe.
> - but there may be a misconfiguration where this is not the case and
> multiple rbs may be appointed avf causing loops if you only send on the
> dvid.
> - to solve this problem the full announcing set is defined in the spec.
> this may still, in patholgical cases, result in multiple rbs being
>   appointed avf for the same vlan, but the AF bit and inhibition will
> result in only a single forwarder per-vlan.

That all sounds right to me.

> I am still concerned with scalability in cases of lots of adjs and lot of
> vlans,
>

There were people who argued very strongly for all RBridges always sending
Hellos on all enabled VLANs on all enabled port (except on ports configured
to use point-to-point Hellos).

> but also want to allow for "misconfiguration". I think there could be a way
> to start announcing on the "full set" as defined and then fall back to only
> the dvid if yoiu discover the dvid is enabled on all rbs on a link. It would
> work like this:
>
> - An rb that is not DR would only choose as desginated vlan one of its
> enabled vlans. Its view of the dvid would be included in the vlaf subtlv.
> - All rbs announce on the full set (per-spec DR status dependent) when an
> interface is enabled or the vlan set changes.
>
or a port becomes uninhibited.

> - When the timer expires, an rb can fall back to only sending on the dvid.

I dont think this requires any spec change except for a non-dr refusing to
> accept as dvid a non-enabled vlan id. This would not affect anyone not
> desiring to implement the above. And it would also address the case of an
> RB sending absolutely no hellos, which IMO is extermely counter-intuitive
> and

I'm not sure what's so counter-intuitive about a misconfigured RBridge
acting oddly and not sending any Hellos. If all the RBridges on a link
aren't configured to have the same Desired Designated VLAN and to have that
VLAN enabled on their ports that connect to that link, something odd and
probably wrong is going on with the configuration. This is one of the first
things TRILL campus configuration tools should check for. Under your scheme,
I guess such a misconfigured RBridge would send Hellos, unless no VLAN was
enabled on the port, but there is no guarantee that any other RBridge could
hear the Hellos it was sending, so I'm not sure how much point there is to
it.

Thanks,
Donald

---

From: Anil Rijhsinghani <[email-masked]>
Date: Tue, 16 Feb 2010 09:54:44 -0500

> There's a chicken and egg issue here: during DRB election -- when  
> the desig VLAN isn't yet established -- what's the outer VLAN tag?  
> It's not specified.
>
> I actually don't like the word "election" for what happens, although  
> it is the official IS-IS term that everyone uses. It seems to imply  
> a start/stop. It is really a continuous process whereby each RBridge  
> determines who it believes is the DRB and acts accordingly.

In most network protocols, the word "election" is used in a continuous  
manner. In spanning tree too, the root is "elected" but its validity  
is continuously evaluated.

> Also, while the network always has to be safe, it is probably not  
> worth worrying all that much about bizarre configurations where the  
> RBridges on a link have different ideas about what the Designated  
> VLAN should be and/or have the Designated VLAN not enabled on a port  
> and the like...

Is that such a "bizarre configuration"?  If every rbridge were  
required to have the same configuration of Desig Vlan on all ports,  
the DRB wouldn't need to select it. No need for "Desired Desig Vlan",  
etc.

> This is discussed in the last paragraph of 4.4.3. If a bunch of  
> RBridge ports come up simultaneously on a link, they will all  
> initially transmit a Hello specifying the Designated VLAN to be what  
> they want it to be. This will be resolved as soon as they see Hellos  
> from any other RBridges on the link.

Agreed but what's the outer VLAN tag in these simultaneous hellos?  
This needs to be spelt out, not implied, for interoperability reasons.

> Elsewhere in the draft, there's this: "TRILL requires at least one  
> VLAN per link that gives full connectivity to all the RBridges on  
> that link. The default VLAN is 1, though RBridges may be configured  
> to use a different VLAN. "
>
> This implies we need a per-port "Trill Vlan" in the MIB, which is  
> enabled in all Rbridges on the link and should (must?) be used as  
> desig vlan on that link. The default value of this is 1.
>
> configurations can cause partitions of a link. But in any case, all  
> this is in Section 2 which is explicitly labeled in its first  
> sentence as giving a high level overview omitting some details.  
> There is no "TRILL VLAN" per port other than the already specified  
> Desired Designated VLAN and actual Designated VLAN per port.

IMO, the draft correctly says that there must be at least one VLAN per  
link that's enabled on all rbridges, and that VLAN 1 is a good  
candidate. Putting 2 and 2 together, I'm thinking this is the VLAN on  
which the election takes place.

However someone in the WG must have felt there are scenarios in which  
VLAN 1 cannot be used. From material elsewhere in the draft, my guess  
is this has to do with the possibility that rbridges are connected via  
a provider cloud which restricts what VLANs may be available. Then,  
configuration of desired desig vlan is the solution.

In any case, all this stuff needs to be made clear if rbridges are to  
interoperate.

> all Trill frames on all links.

Keep in mind, this means it's legal for Trill frames to have no outer  
VLAN at all, which is the normal form of default-Vlan packets. In fact  
even if rbridges create 1-tagged packets, bridges may strip it out  
during forwarding.

Regards,
Anil

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 16 Feb 2010 11:13:56 -0500

Hi Anil,

On Tue, Feb 16, 2010 at 9:54 AM, Anil Rijhsinghani <[email-masked]> wrote:
>> ...
>>> VLAN should be and/or have the Designated VLAN not enabled on a
>>> port and the like...
>
> the DRB wouldn't need to select it. No need for "Desired Desig
> Vlan", etc.

Having the designated VLAN be selectable was motivated by such
considerations as incrementally upgrading bridges to RBridges in an
existing bridged LAN where any particular VLAN, including VLAN 1, may
have a prior use that would be inconvenient to change right away and
cases such as carrier provided links who connectivity might be
restricted to an arbitrary particular VLAN. While these motivate being
able to select the Designated VLAN, they don't provide any reason why
you would want different RBridge ports connected to the same link to
have different Desired Designated VLANs. So that still seems like a
pretty bizarre configuration to me.

Simply imposing a requirement in the specification that all RBridge
ports on a link be configured with the same Designated VLAN seems much
more brittle and error prone than providing a mechanism which assures
this. You have to elect a Designated Intermediate System anyway, for
IS-IS to work, and it is common in spanning tree and IS-IS for the
root/DIS to dictate some parameters, so it just seems natural to have
the DRB dictate the Designated VLAN.

(Of course, P2P is an exception.)

>> initially transmit a Hello specifying the Designated VLAN to be
>> what they want it to be. This will be resolved as soon as they see
>> Hellos from any other RBridges on the link.
>

Sorry, to be more explicit, there are multiple Hellos. On start-up,
before it has seen a higher priority Hello, each RBridge thinks it is
DRB and, as stated in the specification, sends Hellos on that
basis. So, unless the Announcing VLANs set for the port has been
configured otherwise and unless the port has been configured to use
P2P Hellos, it initially sends TRILL Hellos on all enabled VLANs. Each
of those Hellos appears on the wire either tagged with its VLAN or
untagged if the port is configured to strip (or not add, depending on
how you look at it) the VLAN tag.

The DRB election doesn't occur "on a VLAN", it always occurs across
all VLANs at a port.

>> > Generally speaking, if there are RBridge ports that don't have
>> > the designated VLAN enabled, arguably your network is
>> > mis-configured. Most commonly one would expect all the RBridges
>> > in a campus to be configured to designated the same VLAN if they
>> > are DRB and one would expect that that VLAN would be enabled on
>> > all RBridge ports connected to inter-RBridge links.
>>
>>> that link. The default VLAN is 1, though RBridges may be
>>> configured to use a different VLAN. "
>>>
>> sentence as giving a high level overview omitting some
>> details. There is no "TRILL VLAN" per port other than the already
>> specified Desired Designated VLAN and actual Designated VLAN per
>> port.
>
> IMO, the draft correctly says that there must be at least one VLAN
> per link that's enabled on all rbridges, and that VLAN 1 is a good
> candidate. Putting 2 and 2 together, I'm thinking this is the VLAN
> on which the election takes place.

There "must be at least one VLAN per link that's enabled on all
rbridge" ports connected to that link only if you want full
connectivity. (I'll admit this is usually considered desirable.) As
above, all Hellos received at a port on any VLAN are considered in the
DRB election process at that port.

> However someone in the WG must have felt there are scenarios in
> which VLAN 1 cannot be used. From material elsewhere in the draft,
> my guess is this has to do with the possibility that rbridges are
> connected via a provider cloud which restricts what VLANs may be
> available. Then, configuration of desired desig vlan is the
> solution.

As above, there is also the legacy case where it is inconvenient to
change a pre-existing use of VLAN 1.

> In any case, all this stuff needs to be made clear if rbridges are
> to interoperate.

Possibly things could be clearer but I think RBridges interoperate
just fine with the existing specification. Perhaps there should be an
additional Tutorial or Implementation Guidance document with more
discussion and rationale and/or giving some implementation details
that have been discussed on the list, such as a recommended encoding
of the zero area number for IS-IS.

> Keep in mind, this means it's legal for Trill frames to have no
> outer VLAN at all, which is the normal form of default-Vlan
> packets. In fact even if rbridges create 1-tagged packets, bridges
> may strip it out during forwarding.

All this was taken into account in the design of TRILL. See, for
example, the discussion in base protocol specification Section 4.4.5.

Thanks,
Donald