[rbridge] Two "shared VLAN" alternative proposals
Joel M. Halpern
jmh at joelhalpern.com
Tue Apr 3 11:43:53 PDT 2007
I don't follow the connection.
At 01:28 PM 4/3/2007, Caitlin Bestler wrote:
> > -----Original Message-----
> > From: rbridge-bounces at postel.org
> > [mailto:rbridge-bounces at postel.org] On Behalf Of Joel M. Halpern
> > Sent: Tuesday, April 03, 2007 10:04 AM
> > To: rbridge at postel.org
> > Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
> > I think we can take the description a step further.
> > As long as we do not insist that all special cases must be
> > solved optimally, it seems that this particular case, as
> > described, can be solved with no modification to the protocol
> > just by special behavior of the RBridge at the router. Given
> > that it is a special case, and that it can be solved
> > externally to the protocol, it would seem to make sense for
> > the protocol not to solve this problem.
> > We do not normally specify what additional features, outside
> > of the spec, an implementation may or may not perform.
> > Hence, the most we might consider doing for this is an
> > infromational appendix that describes how this particular
> > case is solved. (And remember, we can not describe how to
> > solve all the possible special cases.)
>What started this whole line of discussion was that the protocol
>specification at the time explicitly stated that end node discovery
>was only shared with the VLAN. That leads to problems when RBridges
>that are not part of VLAN A need to know of a discovery in VLAN A
>because it implies removal of conflicting key addresses (IP or MAC)
>in their own data structures.
Discover that MAC address X is on VLAN B should not always imply
removal of MAC address X from VLAN A. A device may use the same
address on multiple VLANs. I understand that there are cases where
such sharing of information may be necessary.
But those cases have nothing to do with the situation of a router
unknowingly serving several VLANs all within the same subnet. In
fact, as far as I can tell, that scenario is best dealt with if the
routers MAC address is permitted to appear in several different VLANs
>So, the specification could merely state that RBridges MAY
>communicate endnode discovery with other RBridges for whatever
>reasons. It could even cite shared IP subnets as an example
>of a special feature that specific RBridges MAY chose to
The problem of proper removal of stale information (either because of
exclusive VLAN usage where the end station is not permitted to be on
several VLANs, or because of physical movement, is generally best
addressed by explicit and direct support, if it is desired. Trying
to have unspecified behavior produce consistent result just doesn't work.
However, it also does not seem to be related to the scenario as
described in Radia's email and the IEEE spec. There is no change in
what VLAN can be used to reach any given MAC address in those situations.
>That might make sense if we adopt the "it's not a general problem
>that should be handled by the default zereo configuration solution"
the grouping of VLANs (whether for an end-RBridge support or for
Radia's proposal 1 advertisement, or any other approach) is clearly
not going to supported by the zero-configuration case. It can't be.
More information about the rbridge