[rbridge] Proposed details for announcing endnodes

[Steve Dalberg]

> Radia Perlman wrote:
> > Yeah. Moving endnodes is always an issue. Even with bridges. The 
> > problem with having R1 (the one announcing that endnode E 
> is attached 
> > to R1) having a very short learning cache is that makes 
> R1's endnode 
> > announcement LSP information annoyingly volatile. The 
> problem with the 
> > learning cache timer being long is that R1 can be a black hole, 
> > sucking traffic away from where E really is.
> > 
> > There are some layer 2 protocols, I believe, with explicit 
> > registration and keep-alives. (anyone care to chime in about which 
> > protocols these are?). Endnodes learned that way are good 
> candidates 
> > for explicitly advertising.
> > 
> > For attached IP endnodes, R1 could do something like, if it seems 
> > someone else advertise E, R1 could do an ARP to see if E is still 
> > there. And there might be similar purely layer 2 "pings". 
> (are there?)
> 
> I do not believe rbridges should ever issue ARPs. Silent 
> movement is a known problem with existing bridges; this is 
> not an issue we should be solving.
> 
> Joe

I agree, although from a protocol level, what is the fallout from
conflicting MAC's?  Will it cause protocol thrashing in any way?  

As for the Layer 2 "pings" question, you'd be better off just looking
for traffic sourced by the MAC in question over a couple of second
period.  Not sure what you would want to do with that, but if you don't
see anything you can safely clear your forwarding table 

Steve