[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Renumbering...
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