Subject: Re: [rrg] [Re: [lisp] [ipdir] LISP WG]

From: [email-masked] (Noel Chiappa)
Date: Tue, 17 Mar 2009 13:57:50 -0400 (EDT)

<Apologies for the slow reply - been diverted to other stuff...>

    > From: Scott Brim <[email-masked]>

    > Excerpts from Noel Chiappa on Fri, Mar 13, 2009 02:12:21PM -0400:

    >>> From: Margaret Wasserman <[email-masked]>

    >>> 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

---

From: Scott Brim <[email-masked]>
Date: Tue, 17 Mar 2009 16:57:32 -0400

Excerpts from Noel Chiappa on Tue, Mar 17, 2009 01:57:50PM -0400:
>     >>> 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. 

> 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

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).
> 
> 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

---

From: Scott Brim <[email-masked]>
Date: Tue, 17 Mar 2009 17:03:27 -0400

I have a few questions about LISP-in-the-host:

  - Liveness: Compare draft-meyer-loc-id-split-implications.  What
    level in what stack discovers that packets are not getting
    through, and deals with it?  The network layer is the only one
    that knows what RLOCs are possible.

  - Goodput: is there any way for us to change to using a different
    src/dst RLOC pair based on performance?

By the way see also
http://www.dagstuhl.de/Materials/Files/09/09102/09102.BrimScott1.Slides.pdf
("REAP or Multipath: Should We Bother?").  I'm not sure I would still
agree with my conclusions but I believe some of the thoughts are useful.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 17 Mar 2009 14:42:23 -0700

Scott,

> -----Original Message-----
> From: Scott Brim [mailto:[email-masked]]
> Sent: Tuesday, March 17, 2009 2:03 PM
> To: Noel Chiappa
> Cc: [email-masked]
> Subject: Re: [rrg] [Re: [lisp] [ipdir] LISP WG]
> 

I haven't heard about LISP-in-the-host, but if we are
talking about a *pure* host (i.e., and not a router that
acts like a host) we already have a widely-deployed
mechanism for that [RFC5214][draft-templin-isatapv4].
If we are talking about a router that acts like a host,
we have VET for that [draft-templin-autoconf-dhcp].

>     that knows what RLOCs are possible.

[RFC5214], section 7.2 covers RLOC failure detection through
negative acknowledgments, and [RFC5214], Section 8.4 covers
RLOC liveness testing through positive acknowledgements:

"7.2.  Handling ICMPv4 Errors

   ISATAP interfaces SHOULD process Address Resolution Protocol (ARP)
   failures and persistent ICMPv4 errors as link-specific information
   indicating that a path to a neighbor may have failed (Section 7.3.3
   of [RFC4861]).

...

8.4.  Neighbor Unreachability Detection

   ISATAP hosts SHOULD perform Neighbor Unreachability Detection
   (Section 7.3 of [RFC4861]).  ISATAP routers MAY perform Neighbor
   Unreachability Detection, but this might not scale in all
   environments.

   After address resolution, ISATAP hosts SHOULD perform an initial
   reachability confirmation by sending Neighbor Solicitation messages
   and receiving a Neighbor Advertisement message.  ISATAP routers MAY
   perform this initial reachability confirmation, but this might not
   scale in all environments."

>     src/dst RLOC pair based on performance?

If there are multiple RLOCs, why not?

Fred
[email-masked]

> By the way see also
http://www.dagstuhl.de/Materials/Files/09/09102/09102.BrimScott1.Slides.
pdf
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 17 Mar 2009 14:47:31 -0700

> If we are talking about a router that acts like a host,

In many low-end system use cases (laptops, etc.), it
might be more natural to think of this as a "host that
acts like a router".

Fred

> From: Templin, Fred L
> Sent: Tuesday, March 17, 2009 2:42 PM
> To: 'Scott Brim'; Noel Chiappa
> Cc: [email-masked]
> Subject: RE: [rrg] [Re: [lisp] [ipdir] LISP WG]
> 
> Scott,
>

---

From: Patrick Frejborg <[email-masked]>
Date: Mon, 23 Mar 2009 18:31:21 +0200

>>     > 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.
>>

I agree here with Scott

> True.  We should compare LISP-in-the-host with other

By adding features to the current stack that will solve something for
the enterprises will make it attractive for them to apply an upgrade.
Enterprises are struggling today with slow performance of TCP and UDP
over long distances, if that can be solved the upgrade of hosts will
happen because the enterprises can actually consolidate even more
their data centers (and hence save money). But if the stack will only
save the Internet then nobody is interested to upgrade the hosts,
there has been too much cried wolf about the collapse of Internet and
exhaust of IPv4 addresses.
Also the new stack must be compatible with the current IPv4 stack - no
dual stack with a totally new protocol in parallel - the new stack
must be backward compatible adding new extensions that solves issues
for both service providers and enterprises. Not all hosts will be
upgraded and either every host must be upgraded if the new stack is
backward compatible.
IEEE and the switching guys have succeeded with that, a 10 Mbps
half-duplex Ethernet is a quite different thing from a 10 Gbps
full-duplex jumbo and FCoE enabled Ethernet - I believe the similar
can be done with IPv4

-- patte