[rbridge] VLAN registration

[Dinesh G Dutt]

Typing with one hand is a pain.

I meant to say MVRP support is not required in .1d bridges and so 
neither should it be in Rbridges,

Dinesh
Dinesh G Dutt wrote:
> I'm firmly opposed to having MVRP support a SHOULD or a MUST. We have 
> found no customers wanting it so far. I don't see why RBridge spec needs 
> to say anything more than how VLANs are advertised. How they discover 
> what VLANs to advertise is a specific RBridge implementation detail. 
> Some may use MVRP, some may use some proprietary protocol (this is not 
> the reason for my opposition) and some may use local configuration. MVRP 
> support is not a MUST or a SHOULD and I don't want RBridge support to be 
> so either.
>
> Dinesh
> Eastlake III Donald-LDE008 wrote:
>   
>> Hi Radia,
>>
>> See below at @@@ 
>>
>> -----Original Message-----
>> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
>> Behalf Of Radia Perlman
>> Sent: Wednesday, March 19, 2008 10:29 AM
>> To: Developing a hybrid router/bridge.
>> Subject: [rbridge] VLAN registration
>>
>> Just noticed this section got added to the spec. Some people expressed 
>> privately to me  (and I share
>> their concern) a concern that
>> if RBridges had to support every new feature and protocol that IEEE 
>> comes up with, that we'll never be finished.
>> And that at the very least supporting most of these should be MAYs 
>> rather than MUSTs or even SHOULDs.
>>
>> @@@ I agree that Rbridges don't have to support new 802.1 features and
>> protocols and, if they do, it should generally be a separate document,
>> rather than part of the base protocol specification. However, I don't
>> think dynamic VLAN registration is a particularly recent 802.1 feature.
>> I haven't tried tracing back all the way back but dynamic VLAN
>> registration is certainly there five years ago in 802.1Q-2003 and I
>> suspect that it was added at the time or very shortly after VLANs were
>> added. It is true that 802.1 recently replaced GVRP with MVRP but, while
>> not backward compatible, this logically is a minor change. It primarily
>> replaces a frame which indicates registration for one VLAN with a frame
>> which allows you to provide indications for multiple VLANs.
>>
>> @@@ I think that many of those to whom it had occurred at all believed
>> that the previous provision, that all the 802.1 bridging registration
>> protocol frames would just be treated as non-IP derived multicast, would
>> do the trick. And, in fact, I still believe that provision works fine
>> for the 802.1 bridge multicast address registration protocol frames and
>> will probably work in the unlikely event that 802.1 specifies any
>> additional registration protocols that use multicast addresses in the
>> currently reserved block.
>>
>> @@@ But, the strategy of just treating as non-IP derived multicast is
>> completely broken for VLAN registration frames. It doesn't work for
>> Rbridge ports, which had been previously overlooked, and it doesn't work
>> for remaining bridges in the campus. So I didn't think of this as adding
>> support for a feature but rather fixing completely broken support that
>> was there. I posted a preliminary discussion of the issue here
>> http://www.postel.org/pipermail/rbridge/2008-February/002871.html
>> and talked about it at the March TRILL meeting as a technical change
>> (see
>> http://www.ietf.org/proceedings/08mar/slides/trill-1.ppt
>> slide 5).
>>
>> @@@ I personally don't have much problem with making MVRP support a
>> SHOULD but it really doesn't seem like that much of a burden. It only
>> requires some additional local behavior at Rbridge ports. There is no
>> additional inter-Rbridge traffic and no change, by current thinking, in
>> the link state database.
>>
>> As for the VLAN registration frame -- it seems like R2, if it is VLAN x 
>> forwarder, should only send a VLAN x registration
>> frame if R2 sees, in its LSP database, that some other RBridge in the 
>> campus has a VLAN x receiver. If VLAN x is
>> dynamic, then R2 should not announce VLAN x in its LSP unless there is a
>>
>> VLAN x receiver on the link.
>>
>> @@@ Although you can generally tell if you have an IP-derived multicast
>> listener, can you generally tell if you have a VLAN-x receiver?
>>
>> @@@ The current TRILL specification also says that, by default, you only
>> send VLAN registration frames out a port if you see a bridge out that
>> port, although the port can also be configured to always or never send
>> VLAN registration frames (keeping in mind that if you are not appointed
>> forwarder, etc., for any VLAN it is perfectly reasonable to send VLAN
>> registration frames that attempt to de-register all VLANS).
>>
>> @@@ Thanks,
>> @@@ Donald
>>
>> If we think that RBridges should be supporting this at all...
>>
>> Radia
>> _______________________________________________
>> 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
>>
>>   
>>     
>
>   

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan