Subject: Re: [RRG] Renumbering...

From: Dino Farinacci <[email-masked]>
Date: Sun, 7 Sep 2008 15:18:28 -0700

Stephen, thanks for the input. See comments inline.

> [Edited and resent due to nutty email filters on the list]
>
> Dino Farinacci wrote:
>>> SHIM6, HIP, and multiple PA blocks were not, and are still not,  
>>> considered viable options; my understanding of this RRG was to  
>>> come up with something that the "un-stoppable force" would find  
>>> acceptable so that it could be redirected that way.
>>
>> Stephen, in your own words, why are they not viable?
>
> SHIM6 and HIP are immediately out because they required a change to  
> all hosts before benefits accrued (see also: a last-mover  
> advantage), which could not be fully deployed soon enough to matter,  
> based on the industry's track record so far of implementing even  
> _basic_ IPv6 support.
>
> Multiple PA blocks is slightly more attractive because it is (in  
> theory) incrementally deployable, but it requires that every time an  
> upstream link goes up or down, you have to renumber your entire  
> network (including DNS, DHCP, etc.), plus lose any open TCP sockets  
> that were bound to addresses in the block being removed.  Compared  
> to the mostly external costs of PI, that's out as well.

Right, a level of indirection is needed.

>> And does the registry community think a Loc/ID split solution is  
>> acceptable? I mean, maybe not the specific solutions that deliver  
>> Loc/ID split but the concept?
>
> The concept of a Loc/ID split is very attractive, and many folks  
> over the years have been clamoring for that for a variety of  
> different reasons.  It fits the mental model of how people view  
> networks (or any objects) better than the current (flawed) model of  
> overloading locators to also serve as identifiers.

So, you think its not a non-starter to have devices that DPI, to look  
a little deeper into the packet to look for identifiers?

> The current proposals only take that split to a site level, and  
> conceptually that's still not ideal, but it's a lot better than what  
> we have today and could provide a base for further (intra-site) work  
> if desired.

We have documented in LISP how you can use yet another level of  
indirection to allow LISP to be used inside an SP network for SP based  
TE. We refer to the nodes that do that are TE-ITRs and TE-ETRs. The  
mapping system you run among TE-ITRs and TE-ETRs can be anything you  
want but doesn't need to, and probably be separate, from the mapping  
database used by ITRs and ETRs at sites for Loc/ID split purposes.

>> And if you have opinions why LISP would be acceptable (or not)  
>> please provide.
>
> I like the concept of LISP, but I need to spend a lot more time  
> studying the specifics of the mapping systems before I can offer my  
> own comments on individual proposals, but at a high level, I don't  
> see any specific problems with Map&Encap.  The cost is low and  
> benefits accrue immediately to the people who pay it, and no change  
> to hosts or most routers is required.  Of course, I'm only speaking  
> for myself here, not the entire PI horde ;-)

So who do you think should push/lobby for it. Should SPs lobby for  
their customers to deploy it by creating some unknown incentive at  
this point? Should sites do it on their own because they like the  
simpler use of multi-homing and not to ever have to consider  
renumbering?

Or, should registries push it for the good of the Internet and get  
incentives to both sites and SPs?

> There's still the looming question of who's going to provide the  
> initial Anycast ITRs that are needed to make incremental deployment  
> and reaching critical mass possible, but there are several different  
> reasonable solutions to that problem and so I'm not very concerned  
> about it at this point.

Would registries want to do this?

Dino

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg