Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks]

[Owen DeLong <[e-mail]>]

On May 30, 2014, at 13:26 , Brian E Carpenter <[e-mail]> wrote:

> On 31/05/2014 02:44, Owen DeLong wrote:
> ...
>>> And I think that every SME who has lost business with the unreliability
>>> of their ISP will want multi-homing and will think that with IPv6 and PI
>>> the constraints have gone, and the number of such SMEs can only approach
>>> 10M over time.
>> 
>> All the more reason this issue needs to get addressed instead of ignored.
> 
> We agree on that.
> 
>> 
>>> So, Brian is spot on, and just as the IETF did little about IPv4
>>> addresses running out until the event loomed large, so I expect history
>>> to repeat itself with the growth of PI in IPv6.
>> 
>> He’s somewhat right about the problem. He’s absolutely wrong in believing that
>> the current limitations are a solution.
> 
> As far as I can parse that last sentence, I'm not sure I said that.
> 
> It isn't beyond the bounds of physics to believe that a 10 million
> entry 128-bit wide FIB would be possible. (After all, we believe that
> fully portable 10-digit phone numbers are possible.) But I'd rather
> see a more elegant solution. Whether the RRG has found it yet is
> another discussion.

Agreed.

My point is that continuing to reject the idea of quasi-universal PI utilization and accepting that as a given limitation of the internet as a whole is an obsolete idea and continuing to treat it as axiomatic only delays the possibility of a genuine solution.

I think we could, actually, learn a little from the phone system here. They provide number portability by using two separate (but similar looking) address spaces operated in a process not significantly dissimilar from DNS. The dialed number is looked up in a map which provides a connecting address which is topologically based. LISP sort of looks like this, except that it is much more complicated in its implementation than I believe is warranted for the actual problem space.

It's really too bad we didn't tackle this problem when designing the IPv4 header. An additional 32 bit wide field for Destination ASN may have been all we needed.

Owen