Excerpts from Noel Chiappa on Tue, Mar 17, 2009 01:57:50PM -0400:
> <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_.
Agreed, but to be exact, Mr Thompson: current stack names are tuples
of which an IP address is a component (thus the whole tuple is
topology-dependent, thus the locator/identifier separation problem).
IP addresses by themselves don't name stacks.
That wouldn't be important except ...
> 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.
... imho stack names do not have to be both atomic and persistent,
while you and others apparently assume they do. We need:
- Something to name a stack in order to contact in the first place.
- Something for referrals by third parties. The issue is shared
scope.
- Something for session continuity across multiple addresses as in
multihoming and mobility.
The three do not have to be covered by one identifier. It would be
quite legitimate to use domain names to get locators to use as part of
a tuple for initial contact with a "stack", just as we do now; to use
the same for third party referrals; and to use temporary identifiers
exchanged and authorized after initial contact for the final need.
See below for what a stack name needs to name.
> 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).
Sure that would work, but outside of the target endpoint that's the
same as having a 'primary' address, which we could do with DNS.
> 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.
Well, we've had so many discussions about this. You say that any name
a routing/forwarding function uses is a routing name; Tony says that
anything that is not topology-dependent is NOT a routing name :-p.
This is why I say routing/forwarding functions use whatever they want
(and they do -- they really don't care if they're supposed to or not),
and functions that want to identify things use whatever they want, and
I'm not going to try to split those "whatevers" into locators,
identifiers, dessert toppings or floor waxes.
> 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 -
Agree so far.
> and I hope you're not going to try
> and convince me that an IEEE IID is a routing name!
Just to point out to you that you said a routing name is one used by
routing, and at least ISIS and DECnet ... and maybe IPv6 ... do just
that. :-)
> 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.
An EID is a stack name? That surprises me. An EID gets you to a
particular endpoint but doesn't get you anywhere up the stack. A
stack name needs to name the ultimate consumer of the packet.
> 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.
Yah. It's an attractive scenario to enable. However, with or without
changes to routing and addressing, we need changes in endpoints to
deal with multihoming and mobility, since they'll cross domains no
matter what. If we're going to have that anyway, that relieves some
of the requirements from what we do in routing. By the time our
routing solution percolates out to the endpoints, the endpoints will
have solved their own problems already. So the only real requirements
for routing are that routing info is aggregatable and networks can
protect themselves from renumbering.
> 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?
It depends on what locator and identifier are, and I'm not stepping in
that one again. :-)
> > 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).
True.
> 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).
With "mobility", as opposed to "portability" (aka "nomadicity"), there
is an option for session continuity. This changes everything by
bringing in the need to support continuity already-established
sessions, at whatever layer 2-7. Supporting already existing sessions
in map-and-encap adds a lot more complexity than just rapidly updating
mappings. Well, supporting them at any layer does. Anyway, I
wouldn't say mobility and portability are the same problem.
> 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.
I don't understand this very well but okay. I could imagine that I
connect to a new network, do 802.1X or whatever, get an IP address,
and then send an update to my mapping service announcing that as one
of my RLOCs. That doesn't require anything of the visited network
that we don't have now.
> 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.
Endpoint mechanisms don't _have_ to require anything of the network.
Well, some do (e.g. GSE) but it's not a pure endpoint mechanism. We
already have foobar-equipped laptops attached to networks that don't
support foobar.
> > 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,
One must.
> a whole new world opens. However, the ability to talk to unmodified
> devices may be impacted.
Try to tune in on a discussion Iljitsch will be leading in TSVarea on
Wednesday:
1320-1350 Multipath TCP Opportunities and Pitfalls
Iljitsch van Beijnum
About the advantages we can gain from making TCP work over
multiple paths, and the issues that need to be solved in
order to make it work. This includes discussion about a
multipath TCP that is supported on both ends and a
multipath TCP that is implemented in just the sender and
works with unmodified receivers.
> And if one is allowed to modify hosts, on can do all sorts of
> interesting extra capabilities with map-and-encapsulate systems like
> LISP....
True. We should compare LISP-in-the-host with other
things-in-the-host.
Scott
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
