Re: [rbridge] announcing vlans question

["Jeff Pickering" <[e-mail]>]

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:[e-mail]]
Sent: Monday, February 15, 2010 12:23 PM
To: Jeff Pickering
Cc: [e-mail]
Subject: Re: [rbridge] announcing vlans question

Hi Jeff,

On Mon, Feb 15, 2010 at 9:18 AM, Jeff Pickering <[e-mail]<mailto:[e-mail]>> 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.

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?
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.

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
[e-mail]<mailto:[e-mail]>
http://mailman.postel.org/mailman/listinfo/rbridge

_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge