<I know this is rather a slow reply, but it has some points at the
end which
I really thought deserved a substantial reply...>
From: "Fleischman, Eric" <[email protected]>
Date: Mon, 1 Dec 2008 10:45:43 -0800
Map-and-encaps shields the host from knowing the actual network
topology such that an arbitrarily complex network topology can be
created that is transparent to the end user host
This is also true of the existing internetwork layer, though... It's
an
interesting point as to whether this is a correct architectural
choice, or
whether some applications want/need to be _able_ to see more (i.e.
it would
not be mandatory, and those applications which didn't need it could/
would
continue in blissful ignorance, just as most applictions now don't
care about
virtual memory) - but that's not the main point I want to go over
here, so
I'll pass on, and leave that for another day/thread.
I believe that map-and-encaps should solely be a network
infrastructure
design alternative. To be effective, the hosts should not be aware
that
map-and-encaps .. exists.
.. claims such as "LISP provides an identifier-locator split" is
fundamentally unrelated to the fact that HIP provides an
identifier-locator split. Quite obviously, HIP does so in a manner
that
is real to the host (including applications) while LISP does so in a
manner that is known to routers only. [My own bias is that LISP's
claims in this regard are marketing while HIP's claims are close to
what the ROAD Group originally intended.]
You've made a number of points here, both explicitly and implicitly,
that I
want to respond to.
Most importantly, I want to talk about your point that LISP is a
router-only
solution, and its implication that LISP is therefore a limited
solution. If
one is only talking about what's in LISP documents so far, that's
accurate,
but my hopes for the long-term future of LISP - or rather, the path
on which
LISP is but a first step - are much larger than that. (Based on
discussions
I've had, those hopes are to some degree shared by some - perhaps
many? - of
the people working on LISP - although each individual will no doubt
have
varying degrees of agreement with my ideas, and I'll have let them
speak for
themselves.) And I wouldn't have the slightest interest in working
on LISP if
all it was, and would ever be, was a router-based M+E system using
IPv4/v6.
Why?
I think the past decade or so (as far back as ROAD, in some sense)
has taught
us that replacing the internetwork layer with something superior is
not easy.
Whether or not one believes that IPv6 is viable on an architectural
level (a
discussion I don't want to derail into), its deployment history has
made us
all aware that 'forklift upgrades' don't work, and that viable
deployment
strategies for anything new have to have economic benefit for early
adopters.
In fact, I'd now say that when analyzed from a practical angle,
what's _most_
important about any replacement piece of the internetwork
architecture is not
how nice a design it is, but how good its deployment path is -
including
especially the very earliest stages. I might have the world's best
clean-slate design, but if I don't have a deployment plan which is
economically feasible, it's just a very mildly interesting piece of
paper.
It is from that mindset that I look at LISP. LISP as currently
documented is
just, to me, a first step on a longer road - but one that passes
that key
test of 'can it take off, to start with'? I liken the problem of
deploying
entirely new replacement subsystems (such as a new internetwork
layer) to
rolling a snowball down a hill - unless you can start with a big
enough
initial snowball to start with, and find a hill of the right
steepness (i.e.
the right path for it to travel, once it starts moving), your
snowball isn't
going to go anywhere.
In fact, even though LISP was designed with a heavy focus on passing
this
'initial deployment' bar, there are still concerns that it won't
make it,
through lack of enough compelling features for people to change. In
particular: i) simpler multihoming is a good feature, but people may
be happy
with the existing expensive/unscalable solutions; ii) freeing up
address
space (since EIDs can be allocated more densely, and the amount of
address
space needed for RLOCs is an order of magnitude or more less than
that needed
for end hosts) is nice, but 'tragedy of the commons' means if a site
already
has addresses, they don't care about the new guys ('I'm all right,
Jack -
they can NAT').
Yes, as initially deployed, LISP is targeted at deployment in
routers at the
edge of sites (precisely to minimize the impact on existing plant),
and uses
existing protocols. But the concept is that, _if done right, with
the right
hooks, and thinking forward about the future_, it can be the first
step on a
path to something better. The exact path is way too complicated to
put in
this margin, but here are some examples.
- The initial spec provides for use of IPv4 between xTRs - but with
a system
of xTRs deployed, it would be feasible to replace that inter-xTR
protocol
with something better - a layer that e.g. recognized traffic
aggregates as
first-class objects (so that traffic engineering would no longer
have to rely
on routing hacks), or had built-in tools for aggregation of routing
information (think a hierarchy of nested areas), instead of having
to have it
be hand-configured as now. I think we've seen that deploying new
stuff like
this is virtually impossible _if the hosts have to understand it_ -
so it
makes great sense to initially hide it behind a set of mapping boxes
- but
how does one get the mapping boxes deployed to do it? Well, you have
to offer
them some short-term benefit....
- The initial concept is that routers and hosts would not need to be
modified, to make deployment feasible. (See Figure 1.) However, once
there is
some added value to what's on the other side of the xTR, it might
make sense
to incrementally move that boundary closer and closer to the hosts,
and
perhaps eventually expose the hosts to the new inter-xTR protocol
directly.
I'm not sure the xTRs would ever go away completely; as long as we
have
unmodified hosts - which is something we _have_ to support, and
support well
- we'll need them. However, there is at least a feasible and viable
migration
path which allows us to eventually see a new architecture deployed.
The key is to have this future path in mind while one is building
the initial
snowball, as it were. For example, any identity->locator resolution
system
needs to be able to handle mappings that map not just to IPv4/6
addresses,
but other syntaxes as well, so it would be possible (without a great
headache) deploy a new locator namespace in the future.
So far, there aren't many people, and not a lot of resources, so the
future
can only get so much thought. Right now it has to all be focussed on
getting
that initial snowball moving - because with that, detailed plans for
the
future are a waste of energy...
In any event, as I recently pointed out to a bunch of LISP people,
the lesson
of large projects is that one can't plan it all out beforehand (even
if we
had the resources/personnel for such an effort, which we don't), and
expect
it to work. One has to have, as Corbato said, an ability to change
course
based on experience, without which a large project is a ship without
a rudder
(which, IIRC, was his simile). So the basic concept is to get
something
rolling down the hill, and then go around the design -> implement ->
deploy
-> gather-real-experience loop as fast as possible, while proceeding
down the
general path to a more capable system.
As far as HIP goes, I think it's a neat concept, includes good
ideas, and I
hope it catches on. However, two things. First, the installed-base/
evolution
issues are significant - while new applications can use it, HIP
isn't a great
deal of help when dealing with legacy hosts/applications/etc.
Second, HIP
does nothing to provide us with a superior internetwork layer
(including a
new routing architecture).
Please, do not take this is a smack against HIP - as I said above, I
think
it's good, and I hope it catches on. But it is primarily a shim
layer between
the internetwork layer and transport/application modules - and it's
the
internetwork layer which I am interested in.
While LISP clearly doesn't provide the same degree of separation of
location
and identity as HIP, I think it's incorrect to say any claims it
makes to
separation of location and identity are '[purely] marketing'. LISP
EIDs may
initially have limited location scope, but they certainly don't have
global
location scope - and the design is the way it is for seem like good
reasons:
the ability to work with _unmodified_ hosts and routers - needed to
make that
initial snowball feasible. We either have to give up making EIDs
purely
identifiers (i.e. retain some location semantics, within a local
scope), or
else we have to modify all the internal routers at a site - and the
latter is
a non-starter for deployment.
LISP certainly does allow an organization to do a number of
_practical_
things, like change its ISP without changing its host addresses -
and not
just inside the site, but in external places as well, such as
configuration
data on other sites (e.g. for access control).
If LISP wasn't intended to allow _some_ degree of separation of
location and
identity, we wouldn't have put so much time into CONS, which does
nothing
more than... provide a mapping from identity to location! (Although
I do
concede that in a blank-slate architecture, this function might not be
needed, alas, we have to deal with the deployed base/architecture we
have.)
The fact that it's not on the front burner has a lot more to do with
'focus
on getting that initial snowball together' than anything else.
LISP is certainly not the architecture I would come up with, given a
clean
slate - but we obviously don't have the luxury of a clean slate.
Noel
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
