<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
