[rbridge] On Nick-Names

[Gray, Eric]

Caitlin,

	Anything more explicit than "it magically happens" would
be an improvement.  However, disadvantages in what you suggest
include the "new" requirement for persistent storage (this is
not implicit in typical plug and play hardware), and the fact
that we might have to be pretty explicit about when we require
this to happen (i.e. - at what point can other implementations
assume this has been done?).

--
Eric

--> -----Original Message-----
--> From: Caitlin Bestler [mailto:caitlinb at broadcom.com] 
--> Sent: Thursday, November 02, 2006 5:37 PM
--> To: Gray, Eric; Eastlake III Donald-LDE008
--> Cc: rbridge at postel.org; Radia Perlman
--> Subject: RE: [rbridge] On Nick-Names
--> 
--> rbridge-bounces at postel.org wrote:
--> > Donald,
--> > 
--> > 	Yes, this sounds familiar.  There are issues with this
--> > negotiation approach, however.  For example, because it is
--> > non-determinstic, some of the assumptions in this text are
--> > either incorrect, or subject to race-conditions.
--> > 
--> > 	For example, the statement "once it is stable,
--> > nicknames should remain stable even as routers go up or down"
--> > appears to either assume that a nick-name is presistent
--> > across a system's reset/reboot, or assume that this approach
--> > will (somehow) result in selecting the same nick-names again.
--> > 
--> > 	Also, the statement "To minimize the probability of a
--> > new RBridge usurping a nickname already in use, an RBridge
--> > should wait to acquire the link state database from a
--> > neighbor before it announces its own nickname" seems to have
--> > built-in difficulty in boot-strapping.  Exactly _how_ does
--> > this occur without the possibility of two devices each
--> > believing the other is the one doing the "usurping"?
--> > 
--> > 	I am also very uncomfortable with the idea of allowing
--> > any implementation choice possible, for nick-name selection,
--> > to be used, under the assumption that convergence will
--> > eventually happen, and that persistant nick-names will be a
--> > natural result of this chaotic assumption.
--> > 
--> Why not explicitly state that an RBridge SHOULD use its
--> prior nick-name as its first choice after a reset/reboot?
-->