[rbridge] Two "shared VLAN" alternative proposals

[Joel M. Halpern]

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


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

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

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.

Yours,
Joel