[rbridge] VLAN registration

[Dinesh G Dutt]

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