Re: [RRG] Renumbering...

[Dino Farinacci <dino@cisco.com>]

> > > > 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 rrg-request@psg.com 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