Subject: [rbridge] On Nick-Names

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Thu, 2 Nov 2006 14:01:36 -0500

Radia,

	I was under the impression that - while the "random approach"
has been discussed - there was some concerns about the fact that this
approach is inherently non-deterministic.  I don't recall exactly the
conversation I over-heard, but I thought there were concerns that this
may lead to management difficulties, etc.

	Also, this would mean that an RBridge would rarely use the same
nick-name in later negotiations, possibly leading to inconsistencies 
in forwarding entries and difficulties in defining a graceful restart
approach later on.

	However, even if this is - indeed - the approach we're going to 
use, the probability of a collisions is clearly 8 times as great with
16 bits as it is with 19 (16 times as great with 16 bits in comparison
with 20 bits).  That is true irrespective of the "sparseness" of usage
of the nick-name space.

--
Eric 

--> -----Original Message-----
--> From: Radia Perlman [mailto:Radia.Perlman at sun.com] 
--> Sent: Wednesday, November 01, 2006 9:58 PM
--> To: Gray, Eric
--> Cc: rbridge at postel.org
--> Subject: Re: [rbridge] On Nick-Names
--> 
--> I thought the spec did say how to choose nicknames.
--> 
--> I think it should be done based on choosing them at random, 
--> (rather than 
--> some substring
--> of the MAC address) and if someone with higher priority
--> asks for the same nickname you did, you have to choose a 
--> different one. 
--> Priority is
--> based on lower MAC address.
--> 
--> It will converge more quickly if the nickname space is not 
--> very densely 
--> used of course. But I really
--> think that people are not talking about building campuses 
--> with more than 
--> 1000 RBridges, so
--> with 16 bits it wouldn't be densely assigned.
--> 
--> I don't care what size the nickname is. 16 bits seemed to 
--> align nicely, 
--> but as I said, I don't care.
--> 
--> Radia
--> 
--> 
--> 
--> Gray, Eric wrote:
--> 
--> >Folks,
--> >
--> >Another thing to consider in potentially reducing the size of 
--> >the RBridge ID name space is that reducing the number of bits
--> >also increases the probability of "name collisions" during the
--> >process of nick-name negotiation - further complicating the
--> >RBridge interactions by increasing the probability that "name
--> >collisions" will result in multiple retries.
--> >
--> >Last I heard, the protocol specification was going to spell
--> >out how nick-names would be negotiated.  As I understand it,
--> >the plan was to assert a nick-name based on some substring of
--> >the MAC-derived system ID.  Since this is at least 48 bits
--> >(with perhaps fewer bits relevantly significant), a reduction
--> >to 19 bits was felt to introduce a collision probability that
--> >is not too bad.
--> >
--> >Do people feel that collisions are likely to remain rare if 
--> >the name space is reduced to 16 bits?  IMO, that may be an
--> >unreasonable assumption...
--> >
--> >--
--> >Eric
--> >_______________________________________________
--> >rbridge mailing list
--> >rbridge at postel.org
--> >http://mailman.postel.org/mailman/listinfo/rbridge
--> >  
--> >
-->