[rbridge] VLAN registration

[Eastlake III Donald-LDE008]

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