[rbridge] Proposed details for announcing endnodes

[Eastlake III Donald-LDE008]

See below at @@@

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Steve Dalberg
Sent: Tuesday, April 29, 2008 10:33 AM
To: rbridge at postel.org
Subject: Re: [rbridge] Proposed details for announcing endnodes

...

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

@@@ If you are just doing data plane learning (i.e., learning from
received frames and decapsulated frames), it's pretty much like 802.1
bridges. Frames addressed to a MAC address can get sent out the wrong
port until an old learned MAC address that is no longer correct times
out. If you are listening to the VLAN end station address IS-IS frames,
there could be multiple other Rbridges advertising that the have the
same end station MAC address attached. The various different sources of
information as to what Rbridge an end station address is attached two
all have a one byte unsigned confidence level associated with them. If
there are more than one with the same confidence, the current spec does
not say how to choose but it seems likely that most implementations
would just end up using whatever information they had most recent
processed as, in general, "newer" information of equal confidence to
what an Rbridge is currently using over-rides older information. See
Section 4.6 of the current base protocol specification
draft-ietf-trill-rbridge-protocol-07.txt. In any case, there isn't
anything I would call "thrashing".

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 

@@@ I don't see how you can say that for all layer 2 interfaces. IEEE
802.11, for example, rapid movement of end stations from one network
attachment point to another has always been an assumed part of the
protocol. It has explicit association, disassociation, and
re-association messages (although it is really a bit more complex with
authentication and security ...).

@@@ Thanks,
@@@ Donald

Steve