[rbridge] A "multiple VLAN Hello" proposal

[Radia Perlman]

Hmm. I was wondering if an RBridge might be able to receive on a VLAN 
that it
isn't configured to officially support. But actually, what I meant was 
that I was
assuming there might be a large subset of VLANs that the RBridge can 
send and
receive on. and some smaller subset of those that it is configured to 
send IS-IS Hellos on.
So if an RBridge does support all 4000 VLANs, by default it would only 
send IS-IS Hellos
on VLAN 1, but would receive on any of them. And it might be configured 
to send on
a subset of the supported VLANs, but hopefully not all 4000. So that's 
what I was trying to get at.

Radia


Anoop Ghanwani wrote:
> 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
>>
>>