<Apologies for the slow reply - been diverted to other stuff...>
> From: Scott Brim <[email protected]>
> Excerpts from Noel Chiappa on Fri, Mar 13, 2009 02:12:21PM -0400:
>>> From: Margaret Wasserman <[email protected]>
>>> I am concerned about the accuracy of calling this mechanism an
>>> ID/Locator split mechanism
>> Well, if it is not intended to separate location and identity, what's
>> the point of creating a mapping database, to maintain maps from one
>> namespace to another?
> In both cases you are dealing with things that name network attachment
> points.
OK, here's a point of non-clarity. IPvN addresses are 'mixed together' along
_two_ mostly orthogonal axes. The first one, the one that gets most attention,
is the location/identity one: i.e. the _semantics_ of the name itself. The
second one is about _what_ is named: a network interface or a 'stack' - and an
IPvN address is used to name _both_.
In an ideal architecture, one namespace would name NAPs, with a name with
useful semantics for those entities (i.e. location); stacks would be named
from a different namespace, one with different semantics, likewise useful to
them (i.e. stable identity). However, that's not what we have....
It's going to be just as hard (and maybe harder) to disentangle _that_ axis
as the name/location axis - I can see how to slowly migate the 'location'
part of the IPvN addresses into two separate namespaces, but migrating
interface names is tricky.
Maybe the hack Fred Templin alluded to (having a loopback interface, and
assigning the 'pure identity' IPvN address to that, as the stack's name) is a
direction to be explored (at least, for implementations which support such
shenanigans).
I won't mention this in each section below, but take it is an additional
comment in all places where you use the term "network attachment point".
> It maps between routing scopes. ... However, even though they all name
> network attachment points they are not _routed_ the same.
Here's where I start to apply the 'walks like a duck test'. To me, a routing
name is one used by the routing, i.e. the path selection computations. If one
doesn't (and can't) make any 'chose outbound path A or B' decisions with it,
it's not a routing name.
Again, let's talk in my hypothetical future scenario where the
mapping/encapsulation takes place at the first-hop router. In such a
situation, the LISP EID is indeed a name for the NAP - one with global
_uniqueness_ (modulo NAT), but with zero _inherent_ location. (That inherent
location information is only available in _another_ name, to which the LISP
EID must be mapped, before one can determine location.)
To put it another way, in such a scenario the LISP EID is _directly_ of no
more use to that last-hop router than a packet with an IEEE 48-bit interface
ID on/in it - and I hope you're not going to try and convince me that an IEEE
IID is a routing name! All either one does is allow the last-hop router to get
the packet to the correct (globally identified) interface. Yes, of course the
LISP EID (because it's an IPvN address) also has _other_ functionality, as
alluded to at the top - it's also a stack name.
Yes, initial LISP deployments might not look like this - but it requires no
changes in the LISP archicture or protocols to bring us to this point. All it
requires is deployment of LISP functionality in the first-hop router.
The _right_ way, IMO, to look at this whole scenario is to view the process of
'leeching' location out of IPvN addresses is both gradual (i.e. it doesn't all
happen in one step, for any given IPvN address), and non-synchronized
(i.e. some IPvN addresses may have less 'location' in them than others, at any
given point in time).
I fully expect to see a mix of non-mapped IPvN addresses (i.e. full
location), partially location-independent IPvN addresses (i.e. ones which are
mapped at a border router), and fully location-independent IPvN addresses
(i.e. ones which are mapped at a first-hop router), all flying around the
system at the same time.
However, that is, I maintain, an _inevitable_ property of any _realistic_
deployment scheme.
>> And two of the capabilities [LISP] explicitly provides/supports are
>> provider independence and multi-homing - two things for which
>> separation of location and identity are generally held to be fairly
> crucial.
> They provide provider independence at the site level, not endpoint.
In initial deployments, probably, yes. But what about if/when
mapping/encapsulation happens at the first-hop router (for which, again, no
protocol changes would be required)?
And I don't think this in any way negates the value of the point I was
making, in response to Margaret's concern over whether 'separation of
location and identity' was an appropriate label for LISP. If the ability to
take a collection of hosts with globally visible/unique IPvN addresses (i.e.
no NAT) and move them to a different ISP without either i) having a routing
entry for them in the DFZ, or ii) changing their IPvN addresses _isn't_
"separation of location and identity", then what is it?
Yes, it's not a pure/clean/perfect architecture - but it also support
unmodified hosts/routers, and that forces painful compromises. How clean we
get it is more of a _deployment_ issue than a protocol one.
> The endpoint still does not have any kind of topology-independent
> identifier it can use if it, itself, is multihomed or mobile.
This is a complex issue.
First, there is the confusion _inside hosts_ over the names of interfaces and
stacks. As long as those two things are intermingled in the very code in
hosts, we can't provide a perfect solution.`Individual host multi-homing is
one thing that will be impacted by this - depending on the exact code in the
hosts, it may or may not be multi-homable (e.g. through a loopback interface
hack).
Second, portability (which I know you didn't mention) and mobilty are in
architectural terms the same thing, but just at different time scales.
Whether one can support both all depends on the mapping system - some kinds
of movement may be too dynamic to support in the 'main' mapping system
(although perhaps it could devolve such mappings to a specialized one that
can support 'high-speed' mapping updating).
Third, whether _global_ portability for individual machines will be supported
is, again, a deployment issue - it depends on whether a map-and-encapsulate
first-hop router is available. One way to look at this is to say that the set
of areas to which an individual machine is portable is the set of areas which
have a map-and-encapsulate router attached to them (modulo authentication,
access control, etc). That set will start out small, and grow over time - but
again, it's a deployment issue, not a protocol one.
>> Yes, [LISP] is not absolute separation of location and identity (at
>> least in the short term), but that is because LISP made the strategic
>> choice to support _unmodified hosts and site-local routers_
> Right. However, over the months we've realized that in a world where
> MOST devices will be wireless and many will have multiple radios, we
> will have multihoming and mobility in the endpoints, so this isn't
> enough.
Sure, but support of such things is still, in part, a deployment issue. Even
if one adds support for the FooBar ID/Location mechanism, which provides
perfect separation, if one take one's FooBar-equipped laptop to a part of the
network which doesn't support FooBar, one may not be any better off.
> Endpoints need to be able to use multiple attachments and change
> their attachment points at will. They need identifiers that
> support that. They can use either higher layer identifiers (e.g.
> Trilogy multipath) or lower layer ones (MIP, HIP) that decouple
> the usual tuple from actual addresses.
If the rules of the game are that one can modify hosts, a whole new world
opens. However, the ability to talk to unmodified devices may be impacted.
And if one is allowed to modify hosts, on can do all sorts of interesting
extra capabilities with map-and-encapsulate systems like LISP....
Noel
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
