[rbridge] VLAN registration

[Eastlake III Donald-LDE008]

See below at ### 

-----Original Message-----
From: James Carlson [mailto:james.d.carlson at Sun.COM] 
Sent: Thursday, March 20, 2008 9:33 AM
To: Eastlake III Donald-LDE008
Cc: Radia Perlman; Developing a hybrid router/bridge.
Subject: Re: [rbridge] VLAN registration

Eastlake III Donald-LDE008 writes:

### (Actually, the "> " prefixed lines immediately below were, I
believe, from Radia Perlman.

> 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.

That implies that RBridges need to manipulate MVRP messages in order
to play at this game.  The MVRP request that an RBridge sends out
needs to be the bitwise sum of all of the requests received on all
other LANs by the RBridge cloud plus the list of enabled VLANs known
in the LSP database.

### I don't think so. MVRPs can be handled locally at each port based on
the configuration and state of that port and the link state database. I
don't think there is a dependence on requests received except to the
extent they change the state of a port and that in turn affects the link
state database. Perhaps I should write up a more detailed description of
how this would work.

> @@@ Although you can generally tell if you have an IP-derived
multicast
> listener, can you generally tell if you have a VLAN-x receiver?

No, because of manual configuration.  VLANs can lurk.

### Right. So really my point was that, since you can't tell if there is
a VLAN-x listener, if you are sending MVRPs, you have to formulate them
based not on some other Rbridge in the campus having a VLAN-x receiver
but just on some other Rbridge in the campus being a VLAN-x appointed
forwarder, which is what is reported in the link state database.

I suspect that SHOULD for MVRP carries a bit too much force here.
It's an optional part of the IEEE world, and, as best I can tell, it's
not really used anywhere (yet?).  SHOULD means that vendors need to
have a very good reason to avoid implementing, and not just that their
target markets use .1d bridging only.

### I wish, when people slam MVRP, they would make it clear if they are
slamming dynamic VLAN registration or just MVRP.

### As per my other messages, I think we have been targeting 802.1Q
bridges. Lots of things could be vastly simplified in Rbridges if they,
like 802.1D bridges, didn't need to support VLANs at all. And, as far as
I can tell, MVRP is a mandatory to implement part of 802.1Q. And I don't
think we should look only at today's deployment. Presumably Rbridges
should be aimed at a future state of deployment.

I think optional parts ought to be listed as MAY in the base
specification or -- much better yet -- listed in a separate document
(or documents) where you can be free with the MUSTs as needed.

### It seems like you should still say something about what you do when
you receive a VLAN registration frame.

Things we list in the base document need to be the things that are
required to build an implementation.  Is MVRP really one of those
things?

### Well, the group gets to decide that. But I suspect that dynamic VLAN
registration, either GVRP or MVRP, takes at least an order of magnitude
fewer lines of code that implementing SNMP and static VLAN
configuration. And in 802.1Q, MVRP is mandatory while configuration by a
management protocol is optional.

### Thanks,
### Donald

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677