[rbridge] Two "shared VLAN" alternative proposals

[Caitlin Bestler]

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Eric Gray (LO/EUS)
> Sent: Tuesday, April 03, 2007 6:08 AM
> To: Radia Perlman; rbridge at postel.org
> Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
> 
> Radia,
> 
> 	I imagine there are many more ways to answer this 
> question than the three alternatives you've offered as examples.
> 
> 	I would answer this way:
> 
> .	neither approach is required to solve the problem, hence I
> 	suggest we concentrate on not breaking solutions that work
> 	now;
> 
> 	And:
> 
> .	Here is a better option - we specify that an RBridge may be
> 	configured to provide an inter-VLAN proxy ARP service in a
> 	manner that is compatible with similar services offered at
> 	present and the mechanisms and potential protocols needed
> 	to accomplish this are out of scope for TRILL.
> 

I think this may be a good approach. The only RBridge related
problem with inter-VLAN quasi-routing that has been identified
is an artifact of the ARP Proxy functionality. It makes sense
to fix it there.

But I do agree with Radia that there are two essential ways
to solve this:

	Extend the information collected during RBridge discovery
	so that this problem will be taken care of automatically.

	or, require the RBridges that have this special problem
	to solve it amongs themselves and leave everyone else
	out of it.

With the first method you retain zero configuration for
this feature by advertising VLAN groupings that require
what would otherwise be excessive distribution of endnode
discovery announcements. What Radia proposed works, but
alternate approaches are possible if there is something
inherently wrong about explicitly exporing FID info.

With the second method you would be explicitly configuring
each RBridge within the group with the additional export
rules. Zero configuration is lost for those RBridges, but
kept simpler for most RBridges.

But unless I'm missing something, the only special action
required is to ensure that when a group of VLANs share an
IP subnet that all Proxy ARP tables that reference the 
shared IP subnet will be told of new discoveries.