[rbridge] Global MAC Addresses

[Caitlin Bestler]

Radia Perlman wrote:
> I think I understand the issue Caitlin is raising. MAC
> addresses might not be globally unique, and therefore some
> applications that depend on it might fail in weird ways,
> (such as IP with addresses derived from MAC addresses).
> 
> I don't think this is really a problem within RBridges. I do
> not think RBridges should try to enforce uniqueness, or flag
> duplicates, by trying to compare endnode data on different VLANs.
> 
> I think this problem (potential nonuniqueness of MAC
> addresses) should be addressed within the context in which it
> actually causes a problem, and RBridges should just ignore
> the issue. Within a VLAN if a MAC address appears twice, an RBridge
> could 
> 
> a) assume the endnode is multiply connected, and not worry
> about it at all
> b) have Designated RBridge R1 "worry" if endnode E, which R1
> thinks is on R1's own link, gets announced by R2 as being
> connected to R2, and have R1 ping E in some way, and
> periodically, to reassure R1 that E is still connected.
> RBridges other than R1 or R2 will treat E as reachable via either R1
> or R2. c) and/or log the fact that E seems to be multiply connected.
> 
> Other than potentially doing b) or c), I don't see what else
> an RBridge should do in this case.
> 
> Radia
> 

I agree that there is no problems for RBridges themselves.
The RBridges collectively are implementing a distributed
location database and ARP/ND proxy system. Having inconsistent
semantics as to what constitutes a unique L2 address would be
just asking for problems. The current drafts avoid that trap.
And having stated those expectations, I do not believe that
we need to mandate or suggest any enforcement mechanisms.

But by specifying that RBridges will track end-nodes on a per
VLAN basis (rather than tracking what VLAN, if any, each end
node is attached to) the RBridge drafts would acknowledge
and therefore implicitly bless the practice of having "global"
MAC Addresses with less than global scope.

Whether this practice should be merely noted or more formally
recognized/endorsed, is an issue that should probably be
considered by some other group with the IETF. I'm not sure if
it would be tsvwg, tsvarea or an IPV6 group.