[rbridge] Preview of changes for VLANs, etc.

[Radia Perlman]

Good question. Once an RBridge knows it isn't the DRB, it seems like the 
only
VLAN it should need to send or receive Hellos on is the one that the DRB 
specifies
should be used for interbridge communication.

I think the "safety" case is to maximize the probability that RB1 and 
RB2 can hear
each other if they both believe they are DRB. That was why I was suggesting
that the DRB continue to send Hellos on all the VLANs that it is 
configured to
send Hellos on, which is hopefully a much smaller set than the set of 
VLANs it supports.
In other words, even if an RBridge is configured to accept frames with 
any of the
4000 VLANs on a link, that doesn't mean it would send Hellos on all 
4000. It would
have to be separately configured for the set of VLANs to send Hellos on, 
and hopefully
it would only be configured to send Hellos on a handful of VLANs (3 or 4).

But...if an RBridge is configured to accept frames with any VLAN tag, is 
it burdensome
for it to accept Hellos on any of those VLANs?

Radia


Anoop Ghanwani wrote:
> Hi Radia,
>
> I think the proposal is reasonable in that per-VLAN
> hellos are now optional (and can be made use of in
> certain scenarios).  However, what is not specified
> is the recipient behavior.  Can an RBridge choose
> to ignore hellos from all other VLANs except the
> one it is configured to send hellos on?  It seems
> like that should be allowed because it won't do 
> anything other than detect misconfigurations that
> can also be detected by other means (although 
> perhaps taking slightly longer to be detected).
>
> If that recipient behavior is not allowed, we will
> still get into scaling issues with having to receive
> and process hellos from potentially all VLANs 
> configured on a port.
>
> Anoop 
>
>   
>> -----Original Message-----
>> From: rbridge-bounces at postel.org 
>> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
>> Sent: Monday, November 05, 2007 2:52 PM
>> To: Developing a hybrid router/bridge.
>> Subject: [rbridge] Preview of changes for VLANs, etc.
>>
>> Based on talking to people, here is how I'm assuming the VLAN 
>> stuff will look. The main points are
>>
>> a) single DRB per link (rather than DRB election per VLAN).
>>
>> b) that DRB can delegate to another RBridge on the link the 
>> job of forwarding VLAN-x data to/from the link.
>>
>> c) RBridges MAY be configured to send Hellos on a set of 
>> VLANs, though VLAN 1 is the default. They are also configured 
>> with a single preferred VLAN "V". If RBridge RB1 is DRB, it 
>> tells all the other RBridges on the link to send ALL 
>> RBridge-Rbridge traffic (Hellos, LSPs, forwarded encapsulated 
>> data traffic) with outer VLAN tag "V".
>>
>> d) For safety, the DRB RB1 continues to send Hellos not only 
>> on V, but on all the VLANs that RB1 is configured to send Hellos on.
>>
>> e) The set of VLANs that RB1 is configured to support on the 
>> link may be greater than the set of VLANs that RB1 is 
>> configured to send Hellos on
>>
>> f) We use all the link-avoidance stuff we'd discussed before 
>> (don't decapsulate from ingress RBx unless you have RBx's LSP 
>> and all pseudonodes that RBx claims to be attached to, and 
>> can verify that none of them have the same root bridge ID as 
>> the link you are about to decapsulate onto -- also, be 
>> conservative about when you start encapsulting data off the 
>> link by waiting a few Hello intervals, and waiting until 
>> you've synchornized LSP databases with your neighbors).
>>
>> g) IS-IS Hellos list the set of neighbors from which Hellos are heard.
>> Once the DRB RB1 specifies "V" as the VLAN, the only 
>> neighbors listed in IS-IS Hellos are those from which a Hello 
>> is received on VLAN V.
>>
>> _______________________________________________
>> rbridge mailing list
>> rbridge at postel.org
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>