Subject: Re: [RRG] Renumbering...

From: Dino Farinacci <[email-masked]>
Date: Sun, 7 Sep 2008 21:45:08 -0700

>>>> 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?
>
> I don't see the connection between what I said and that question.
>
> FWIW, I'm against _requiring_ DPI because it introduces state and  
> causes scaling and reliability problems.  I can see reasons it might  
> be useful as an optimization, or at borders between sites to enforce  
> security, but IMHO a generic router shouldn't need anything that  
> isn't in the (fixed) outer header to decide what to do with a packet.

Since you deal with locators at the routing level and then decouple an  
ID to another level, then when you do policy on IDs, you'll have to  
look at a different place.

I was wondering if changing DPI boxes is a non-starter. But from your  
response you don't want to use them anyhow. So the question was  
answered.

>>> 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.
>
> Actually, my comment was referring to how an EID is still overloaded  
> to be a locator within the leaf site, just like an "address" is  
> today.  I much prefer OSI's model which ignored subnets and instead  
> had a protocol (ES-IS) that registered the location of a particular  
> host within the site.  That gets back to the "modify the stack"  
> problem, but for intra-site protocols, that might be feasible.

Right, but incremental deployment is king.

>>>> 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?
>
> My assumption is that, at first, it will be ISPs deploying LISP on  
> behalf of their existing PI customers, because they are the ones  
> that will get the direct benefit from pulling those routes out of  
> the DFZ.

Okay.

>> Should sites do it on their own because they like the simpler use  
>> of multi-homing and not to ever have to consider renumbering?
>
> Sites that already have PI space will not "do it on their own"  
> unless there is an incremental benefit (such as more detailed  
> control) vs. having their upstream do it for them.

They do get more detailed control.

> Sites that cannot get PI today, but who can get EIDs tomorrow, will  
> have no choice but to run their own ETR if they want effective  
> multihoming.

Right, good point. Assuming ISPs will reject their PI advertisements.

>> Or, should registries push it for the good of the Internet and get  
>> incentives to both sites and SPs?
>
> I don't think it's the registries' place to provide incentives.   
> IMHO, it's more likely that the existence of LISP would cause the  
> communities to reduce or eliminate the bar to getting direct  
> assignments, which would force ISPs' hands.

I mean registries could sell more address management services.

>>> 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?
>
> Want?  Probably.  Willing to pay for it and take on the legal  
> risks?  That's the big question.

Yes, new revenue opportunities.

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