[rbridge] area addr question

[Radia Perlman]

Just to clarify the reason for allowing area address to be configurable: 
it is in case someone wants to
build two TRILL campuses that someone could inadvertently interconnect, 
and they want to
prevent them from merging. This might be because of wanting to limit the 
size of each of the
campuses, or because the VLANs are used in overlapping ways in the two 
campuses. I'm not sure
whether there's any other way besides area addresses of preventing two 
TRILL clouds from merging
if someone interconnects them.

The way it would work is that if there were two campuses, and someone 
wanted to ensure they
don't get inadvertently interconnected, *every* RBridge in one of the 
campuses would be configured
with an area address, of, say X.

What would need to be in the spec to ensure these campuses are not 
interconnected would be
words something like:

"If R1 receives a TRILL-Hello on port p, with area address X, not equal 
to R1's area address Y,
then if X > Y, R1 does not transmit anything on port p (including 
Hellos), until all Hellos with
area address X have expired."

I don't understand the comment about "equivalent of "root bridge ID" in 
connection to the issue
of allowing configuration of area address.

Radia





James Carlson wrote:
> Donald Eastlake wrote:
>   
>> Wait a second... Before worrying about additional complexities to handle
>> adjacent TRILL clouds with different area numbers, why is this
>> happening? The spec requires them all to use area zero. The address
>> space is flat so there doesn't seem to be any advantage to breaking it
>> up.... And you will get more efficient routing paths if they all peer.
>>     
>
> To be clear: I don't want to use different area numbers.  The current
> spec says area zero only, and that's all I ever want to use.
>
> Radia asked whether it was possibly configurable, and it is, and we were
> discussing the implications of doing that.
>
>   
>> PS: If you do want the equivalent of the "root bridge ID" for RBridges,
>> it is easy enough. They all have to determine the RBridge with
>> the highest priority to be a distribution root for multidestination
>> frames. The SystemID of that RBridge could serve as a "root RBridge ID"
>> and could be included in TRILL Hellos. But, as I say, I just don't see
>> the need or motivation for this.
>>     
>
> You would also need to carry this information around through other areas
> -- just as we currently do for root bridge IDs.
>
>