<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
