[rbridge] A "multiple VLAN Hello" proposal

Eric Gray eric.gray at ericsson.com
Sun Oct 28 10:43:40 PDT 2007 

Donald,

	We do not have carte-blanch in saying what is correct
and incorrect behavior for RBridges, unless we want to give
up on a large number of common concerns - compatibility with
existing/deployed technologies, software/hardware re-use and
just plain taking advantage of results of past experience,
to name a few.

	In saying that it is alright - at the protocol level 
(what people actually do is their business) - for a device
to treat VLAN traffic promiscuously is assuming both a level
of complexity and a degree of risk in achieving long term 
interoperability between RBridges and other potential VLAN
forwarding devices.

	Also, in establishing a precedent for ignoring what is
"common accepted practice" in existing VLAN devices, we may
expose ourselves to reciprocal future activities.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Friday, October 26, 2007 12:45 AM
> To: Anoop Ghanwani
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] A "multiple VLAN Hello" proposal
> 
> Hi Anoop,
> 
> I don't look at it that way at all. We get to say what "correct" and
> "incorrect" behavior are for Rbridges.
> 
> TRILL Ethertype frames are special. The Outer VLAN tag on a TRILL
> Ethertype frame is just a transport artifact added to enable the frame
> to get through a Bridged LAN that is in the way. It is unnecessary on
> point-to-point links. If an Outer VLAN tag is present on a 
> TRILL frame,
> it shouldn't affect whether the frame is processed.
> 
> Donald
> 
> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On
> Behalf Of Anoop Ghanwani
> Sent: Thursday, October 25, 2007 5:39 PM
> To: Radia Perlman; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] A "multiple VLAN Hello" proposal
> 
> Radia,
> 
> Step "e" would be considered incorrect behavior
> w.r.t. VLANs.  If an end station is not configured
> with a certain VLAN, it should not be receiving and
> trying to process packets from that VLAN.  In this
> case, the end station is the management port running
> IS-IS.
> 
> Anoop 
> 
> > -----Original Message-----
> > From: rbridge-bounces at postel.org 
> > [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> > Sent: Thursday, October 25, 2007 11:56 AM
> > To: Developing a hybrid router/bridge.
> > Subject: [rbridge] A "multiple VLAN Hello" proposal
> > 
> > It's a bit difficult to argue on the list about proposals 
> > when one of them has not been specified, especially since I 
> > can imagine lots of variations on multiple VLANs, and lots of 
> > questions about choices for the details.
> > 
> > Here's an attempt to specify a "send Hellos on multiple 
> > VLANs" proposal. 
> > I've chosen details
> > where in many cases there are other options I could have 
> > chosen. But I think we need some tangible proposal with 
> > details worked out before advocating for it. 
> > People should feel free
> > to suggest modifications to the details below, but I, as I 
> > said, cannot argue between proposals if the proposals aren't 
> > concrete. I've tried to make it as simple as possible, as low 
> > overhead as possible, while adding the ability to configure 
> > sending Hellos on lots of VLANs.
> > 
> > 
> > a) RBridges send and receive IS-IS Hellos on VLAN 1
> > 
> > b) In addition, RBridges MAY be configured to send and 
> > receive Hellos on some set of VLANs in addition to 1
> > 
> > c) If R1 is the DRB, R1 sends Hellos on VLAN 1, plus all the 
> > VLANs that
> > R1 is
> > configured to send (and receive) on. To clarify, as long as 
> > R1 thinks itself is DRB, it will send Hellos on the complete 
> > set of VLANs that R1 is configured to send on. In addition 
> > (see point "e"), R1 may wind up having to send Hellos on some 
> > set of VLANs in addition to those it was configured to send on.
> > 
> > d) In IS-IS's Hello, R1 reports the set of neighbor RBridges 
> > R1 has heard Hellos from. In addition,
> > R1 reports in R1's Hello, for each neighbor R2, *one* VLAN 
> > that R1 hears hellos from R2 on.
> > The one VLAN that R1 reports is the lowest numbered VLAN that 
> > R1 hears a Hello from R2 on.
> > 
> > e) If R1 does not hear a Hello from R2 on any of R1's 
> > configured VLANs, but does hear on some other VLAN, say VLAN 
> > x, then R1 adds "x" to the set of VLANs that
> > R1 transmits on, as long as it continues to hear Hellos on 
> > VLAN x (and no other VLANs) from R2. Note that if R2's Hello 
> > gives R2 better priority for being DRB, then R1 will not be 
> > DRB any more, but MUST continue sending Hellos on VLAN x 
> > (even though x is not in the set of VLANs that R1 was 
> > configured to send on) to ensure that R2 continues to send 
> > its Hellos on VLAN x.
> > 
> > e) if you are *not* the DRB, you send Hellos on VLAN 1 plus 
> > the VLAN that the DRB reports that it has heard from you on. 
> > This cuts down on Hellos since it means that non-DRB RBridges 
> > will send on at most two VLANs.
> > {Note: An alternate option would have had every RBridge send 
> > Hellos always on all VLANs they have been configured to send on}.
> > 
> > f) all RBridge-RBridge traffic (other than Hellos) is always 
> > sent on VLAN 1. So if R2 cannot reach the DRB via VLAN 1, 
> > then R2 cannot forward data to/from that cloud, or receive 
> > LSPs on that cloud. In other words, that link will be broken 
> > for R2. The purpose of the Hellos is only to notice (through 
> > a means *in addition* to the safeguards in the other
> > proposals)  that R2 is not DRB for the link.
> > 
> > g) We do the same safeguards as in the other proposals 
> > (report the bridge root ID in the pseudonode LSP, don't 
> > decapsulate from ingress Ra unless you have all the relevant 
> > pseudonode LSPs attached to Ra to ensure that none of them 
> > have the same root RBridge, and that you delay before 
> > encapsulating data off the link until you've been DRB for 
> > enough time to synchronize LSP databases with your neighbors)
> > 
> > **************
> > My thoughts on this:
> > 
> > a) I assume the only reason to send Hellos on multiple VLANs 
> > is to minimize the probability of accidentally having two 
> > DRBs, and therefore loops. I'm not convinced this adds safety 
> > over the safeguards in the single VLAN proposals.
> > 
> > b) this winds up with sending lots more Hellos, but does not 
> > create additional pseudonodes, or complicate data forwarding, 
> > because the Hellos is only to find neighbors, not to repair 
> > use of the link for forwarding data (or propagating LSPs) if 
> > VLAN 1 is partitioned on the link
> > 
> > c) This is a lot more complicated. It might seem simpler to 
> > not try to optimize the number of Hellos (like I did in point 
> > e), but there seem to be scary corner cases where all the 
> > VLANs common to R1 and R2 are partitioned. Saying there must 
> > be an unpartitioned VLAN 1 seems the safest.
> > 
> > So, I still like the "just use VLAN 1" proposal.
> > _______________________________________________
> > rbridge mailing list
> > rbridge at postel.org
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>

More information about the rbridge mailing list