Dino Farinacci wrote:
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?
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.
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.
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.
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.
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.
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.
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.
S
--
to unsubscribe send a message to [EMAIL PROTECTED] 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