Geoff, Now I understand your argument, I don't think it holds water. The fact that there is a 50% chance of a conflict somewhere inside a set of a million enterprises doesn't bother me in the least.
If an enterprise has direct interconnection to 2**8 other enterprises, in a space of 2**40 random numbers, that enterprise is looking at a 2**-32 chance of hitting a conflict and being forced to renumber. That's acceptable. Even if an enterprise expects direct interconnecion to 2**20 other enterprises, the chance of having to renumber is 2**-20, i.e. one in a million. That's probably acceptable. If an enterprise network manager doesn't think it's acceptable, s/he can wait until IANA has set up the centrally allocated solution, or use a PA prefix. Brian Geoff Huston wrote: > > You are correct in that the "conflicts" matters at the point that the two sites > want to interact in such a fashion that the expose their local use addresses > to each other, now or at any time in the future. > > Now if you have a random selection algorithm that truly has 2**40 bits > of entropy the chances of any two identified random draws from > this space having a clash remains 1 / (2**40), but if you take the total > pool of such randomly drawn numbers and ask "how big does the pool > need to get to lift the change of a clash within the pool above 0.5?", > then the pool size is 1.24 million. If the expectation that this address > format is to be used extensively for local connectivity independently of > upstream connectivity then I would contend that uniqueness is essential, > and the local selection methodology should not be proposed, as its > uniqueness properties are flawed. > > So I suppose I am saying that this is "nowhere near unique", and that if > the entire idea > of this concept is to avoid the use of reused private RFC1918-styled addresses > and the associated NAT functionality, then this local selection algorithm > should > not be included in this proposal. > > regards, > > Geoff > > At 10:03 AM 28/08/2003 -0400, Hans Kruse wrote: > >But don't "conflicts" matter only for separate sites that later decide to > >connect to each other using these addresses? > > > >In that context 1 out of 1.24 million seems small. That does not mean we > >should not include that math, just that the conclusion is valid, > >especially for an address type that is designed to be near-unique as > >opposed to guaranteed unique. > > > >--On Thursday, August 28, 2003 08:14 +1000 Geoff Huston <[EMAIL PROTECTED]> > >wrote: > > > >>The likelihood of conflict exceeds 0.5 after only 1.24 million draws. I'd > >>contend that this is definitely not "small" as described in the draft. > > > > > > > >Hans Kruse, Associate Professor > >J. Warren McClure School of Communication Systems Management > >Adjunct Associate Professor of Electrical Engineering and Computer Science > >Ohio University, Athens, OH, 45701 > >740-593-4891 voice, 740-593-4889 fax > >-------------------------------------------------------------------- > >IETF IPng Working Group Mailing List > >IPng Home Page: http://playground.sun.com/ipng > >FTP archive: ftp://playground.sun.com/pub/ipng > >Direct all administrative requests to [EMAIL PROTECTED] > >-------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS <[EMAIL PROTECTED]> PLEASE UPDATE ADDRESS BOOK -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
