[rbridge] A "multiple VLAN Hello" proposal

[Anoop Ghanwani]

Donald,

Once you've established connectivity over VLAN 1,
you can then exchange the list of VLANs that are
configured on that RBridge port and arbitrate 
which RBridge becomes designated for each VLAN.
For example, if RB1 has VLANs {2,4,6,8} and
RB2 has VLANs {3,5,7,9} configured, then they
will both become DRBs for those set of VLANs 
because there is no overlap.  For the ones that
there is overlap, there will need to be a tie
breaking mechanism.

Anoop 

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Thursday, October 25, 2007 9:43 PM
> To: Radia Perlman
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] A "multiple VLAN Hello" proposal
> 
> Hi Radia,
> 
> The proposal below appears to be written from the "one DRB per link"
> point of view while the current draft claims to support "one 
> DRB per VLAN per link". Even if you have complete VLAN 1 
> connectivity and use single Hellos, I'm not quite sure how 
> the one DRB per VLAN per link would work. In principle, the 
> per VLAN priority for a Rbridge port for all its configured 
> VLANs might not fit into a Hello...
> 
> Thanks,
> Donald
> 
> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> Sent: Thursday, October 25, 2007 2:56 PM
> 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
>