[RRG] RE: [RAM] application endpoint identifiers in map-and-encaps schemes

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

Tony, 
 
> I'll have to dissent.  We have, for a VERY long time recognized that  
> as soon as a host was multi-homed, we had a need to give it an  
> 'address' that was functional and independent of any of the variety  
> of physical layers.  We've solved this in some systems by using a  
> "loopback" interface.  We should recognize this for what it is: a  
> pure system identifier.  Like it or not, we have a requirement for  
> system identifiers and so are following the obvious path and  
> recreating them.

I agree completely with assigning identifiers (i.e., addresses)
to loopback interfaces, but would observe that a single node
could have *many* such loopback interfaces and assigned
identifiers. So, it isn't really a "system identifier" so much
as the identifier of a virtual host that resides within the
system. This might also be quite useful for the situation of
complex networks within a single host, such as when multiple
OS instances are being virtualized and running concurrently. 

> That said, I think we want to be VERY careful about assuming that we  
> want identifiers to point to physical interfaces.  Consider, for  
> example, the virtualization that we see with VMware and Parallels.   
> These run a client OS as a process inside of the guest OS.  If we  
> identify only physical interfaces, what does the guest OS do?  Does  
> it share the address with the host OS?  How is that going to 
> work, in  
> general?  There are many failure modes where the guest OS assumes  
> that it has full autonomy over the address and does something in  
> conflict with the host OS.  Should we then instead consider it to be  
> a virtual interface?  Does it then deserve a separate identifier?

What I was thinking was:

  1) "locators" are assigned to a physical interface of what LISP is
     calling the Egress Tunnel Router. They are routable within the
     global Internet and possibly also routeable within sites.
  2) "physical interface identifiers" are addresses assigned to the
     physical interfaces of end systems. They may be the same as the
     locator, or they may be "site-local" addresses such as an IPv4
     privacy address or an IPv6 unique-local address.
  3) "virtual inteface identifiers" are addresses assigned to the
     virtual interfaces (i.e., virtual hosts) within the end systems.

It could be argued that 2) is more of a locator than it is an
identifier; the terminology gets a bit fuzzy here. But, I think
the function is the same any way you choose to look at it.

> Similarly, one of the functionalities that we might well want to  
> support is process migration in a large multi-computer (e.g., 
> a blade  
> server, or grid-computing cluster).  To support that, we might want  
> the identifier namespace to be mapped to transport protocol endpoints.

This could possibly be addressed by having many virtual interfaces
(possibly loopback interfaces) within the end system; each with their
own assigned identifiers.

> There are a large variety of possibilities here, and I think 
> that the  
> issue deserves careful thought.

Right; the other thing to consider is that as virtual machines
become more deeply embedded and deeply nested within end devices
there may be need to expand the three layer identifier/locator
decomposition above into many more layers.

Fred
fred.l.templin@boeing.com 

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg