[rbridge] A "multiple VLAN Hello" proposal

[Eastlake III Donald-LDE008]

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