Subject: Re: [lisp] LISP and IPv6

From: [email-masked] (Noel Chiappa)
Date: Tue, 24 May 2011 15:33:47 -0400 (EDT)

> From: "Templin, Fred L" <[email-masked]>

    > Inbound traffic engineering is what I seem to be hearing about the
    > most ... Can you say more about "many more"?

Alas, I'm not really up on how all this stuff gets _used_, operationally - I
just think about how to make the mechanisms work! :-) So, others will have to
fill that in. I think there are a bunch of white papers which talk about what
one can do with it, perhaps those would answer this.

    > HIP has something that closely resembles a true endpoint identifier.

This raises an interesting and important point, one that I don't think
gets enough attention.

For very _practical_ reasons, LISP is currently using the existing IPvN
namespaces for _both_ EIDS and RLOCs _in deployed gear_. These choices
means that we don't have to change hosts, we can use existing
infrastructure to move packets between xTRs, etc, etc. 

However, the basic architecture, packet formats, etc can support other
namespaces - e.g. the Map-Request and Map-Reply support namespaces other than
the two IPvN namespaces. So once the basic operational mode (IPvN only) is
established, we may do other things with it.

For instance, some years back I proposed a variant of LISP (LISP-M) which used
an inter-xTR data carriage protocol that ran directly on top of an MPLS
network, not IPvN (useful only among a group of xTRS directly connected to an
MPLS backbone, of course); in that case, LEIDs would translate to RLOCs which
were useful on that MPLS network (whether some new kind of address, or paths,
or something is open).

It can also support other EID namespaces. So I can easily envisage
extending LISP to support HIP identifiers, as yet one more LEID namespace.
(Communication between different LEID namespaces is beyond the scope of
LISP, of course - it doesn't support IPv4<->IPv6 intercommunication
either).

    > The address therefore names the internal vir[t]ual interface, but
    > the end system may have multiple of those - each associated with a
    > different stack.

I don't see this as a problem. (In fact, if one wants to have something
like virtual machines (very popular these days, I gather), mobile
processes, etc, etc, one more of less has to be able to have multiple
endpoints on/at a single physical machine/interface, etc.)

    > But, the end system still has a single *identity* which is not fully
    > captured by any one of the address-to-loopback assignments.

I agree we need to be able to name the interface, so we can deliver
packets to it, and we need to be able to name the end-end entities
(endpoints), for the management of end-end communications (e.g. TCP
connections). But why do we need a namespace to identify the 'end system'
(which I take to be the physical machine)? Sure, it's useful to have
a name for it for the _humans_, but why does the _network_ need to be
able to name it?

    > Without changing all hosts, however, LISP can only reach in as far
    > as the site border router.

Yes and no. It has been worked out, for instance, how to support mobile
LISP hosts which move into a site (either LISP, or non-LISP). So in that
case, it is reaching past the site border router. Yes, that particular
host had to be changed, but not "all [the] hosts" at that site.

This whole business of changing hosts is a case of the old bug/feature
paradigm. To some people, it's a feature that we don't _have_ to change hosts
to make _some_ use of LISP. To other people, it's a bug that we aren't
changing hosts.

    > In that case, the "EID" is a prefix that names a network; not an
    > address that names an end system interface.

LISP, like most major architectural upgrades, is a toolbox, which can be used
in a many different ways.

If one doesn't want to have to change one's hosts or internal routers, one
can run it as a border router, and then, yes, the LEID block names a
network. But one can also run in a way in which an LEID names a single
host or stack. You pays your money and you takes your choice...

	Noel

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 24 May 2011 13:08:33 -0700

Hi Noel, 

> -----Original Message-----
> From: Noel Chiappa [mailto:[email-masked]] 
> Sent: Tuesday, May 24, 2011 12:34 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [lisp] LISP and IPv6
> 

OK.

> infrastructure to move packets between xTRs, etc, etc.

OK, so for the time being it is a router<->router system
and not so much a router<->host or host<->host system.

> established, we may do other things with it.

Anything can be tunneled inside of anything. Some of my
uses actually still consider OSI/CLNP as an inner network
layer protocol for transport over IPv* networks.

> LISP, of course - it doesn't support IPv4<->IPv6 intercommunication

This gets into the discussion as to whether the identities
are routable vs not routable. The LISP EIDs are routable
within a certain scope. HIP HITs are not routable within
any scope.

> endpoints on/at a single physical machine/interface, etc.)

Suppose I had a laptop that made a VPN connection into my
home enterprise network for enterprise-local communications
and simultaneously connected to the (LISP-serviced?) public
Internet for public-side communications. The enterprise
network knows my laptop by one IP address while the public
Internet knows it by another. But, my laptop only has a
single *identity* ("Fred's Laptop").

> a name for it for the _humans_, but why does the _network_ need to be

Take another example. Suppose you did business with two
major financial institutions and you "VPN'd" into each
institution to conduct your transactions. The first
institution knows you as userid 12345678 and the second
knows you as userid 87654321. But, both know you as "Noel
Chiappa". So, the userids (like LISP EIDs) are routable
within a limited scope, but the true identity is known
globally to all. 

> to make _some_ use of LISP. To other people, it's a bug that we aren't

We already have an intra-site tunneling system called
ISATAP [RFC5214] that is widely deployed in major host OSs
today. Surprisingly enough, it assigns an "EID" IPv6 adddress
to a tunnel virtual interface, so it is already implementing
the very paradigm we have been discussing:

http://tools.ietf.org/html/draft-templin-v6ops-isops

ISATAP is for host<->host within the site and host<->router
to get into and out of the site. The router in this case
could be either a native IPv6 router or a LISP border router.

> host or stack. You pays your money and you takes your choice...

Please have a look at ISATAP and the related operational
draft I mentioned above. I think you'll see how it is
already implementing your "highest level of aspiration"
vision of assigning an EID address directly to a virtual
interface of an actual end system. You should also notice
that it can be used even within LISP EID sites.

Thanks - Fred
[email-masked]