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

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 19 Mar 2007 07:03:07 -0700

During the RRG meeting on Saturday, Lixia presented a slide
suggesting that not only locators and identifiers are desired,
but also a possible separation in the identifer in terms of
what the physical interface of the end node sees and what the
*application endpoint* within the end node sees. I interpret
this as follows:

 - let locators be assigned to the tunnel interfaces of
   ingress/egress tunnel routers
 - let *node* identifiers be assigned to the physical
   interfaces of end systems
 - let *application* identifiers be assigned to virtual
   interfaces (e.g., loopback interfaces) within end
   systems

This could allow for the Ethernet-to-WiFi handoff Lixia referred
to in her slide with no need to readdress the application endpoint
identifiers, since only the node identifier changes.

The following text from (IPvLX, Section 3) speaks to this:

"3.  Addressing and Routing Assumptions

   While IPv4 addresses in the current Internet are typically assigned
   to devices, IPvLX assumes that IPv6 addresses will also be assigned
   to application endpoints and data objects [NAME].  This new model
   would provide greater flexibility such that each end-node might host
   many different IPv6 application endpoints and data objects, and that
   those entities could migrate to other end-nodes.  In this model, each
   IPv6 addressable entity would access other endpoints via an IPv6
   router."

Fred
[email-masked]

--
to unsubscribe send a message to [email-masked] 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

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 19 Mar 2007 10:40:33 -0700

Louise,

Thanks for this, and you are certainly correct that an address
is ultimately assigned to an *interface*; not an application, or
a node, or etc. That point doesn't come across well in the text,
but I think I see a way clear to fix it and your feedback has
helped.

Fred

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, March 19, 2007 10:28 AM
> To: Templin, Fred L; [email-masked]; [email-masked]
> Subject: RE: [RAM] application endpoint identifiers in 
> map-and-encaps schemes
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Templin, Fred L [mailto:[email-masked]]
> Sent: Mon 19/03/2007 14:03
> To: rrg; [email-masked]
> Subject: [RAM] application endpoint identifiers in 
> map-and-encaps schemes
>  
> *application endpoint* within the end node sees. 
> 
> [alb]i see that node, network and interfaces all might have 
> identifiers and locators. it seems that some people also see 
> separate spaces depending on role as "edge" or "user". These 
> all could have global or local scope, be transient or 
> intransient. The trick is to decide the minimal set that you 
> can get away with. I think a lot of proposals on loc/id split 
> often have a node id that is used as an application 
> endpoint,and that is intransient (doesn't need to change to 
> keep the network running) and a locator that maps to the 
> physical presence on the net - the interface locator, or an 
> end network that can then recah the device. 
> 
> I interpret
> this as follows:
> 
> [alb] careful of terminology as you will ofetn find node id 
> used to mean application endpoint id in much of the literature
> 
> [alb] I think an IP address actually is assigned to the 
> interface to a node.An ethernet address can be considered the 
> ID of that interface. at a local level that ID can be used to 
> discover a path.
> 
> Fred
> _______________________________________________
> RAM mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ram
> 
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 19 Mar 2007 14:04:12 -0700

Iljitsch, 
  
> And is it just me or does it look like we're slowly but 
> surely trying  
> to reinvent CLNP? There your address (oh wait: NSAP) isn't tied to a  
> single interface but rather to the host in general.

Umm - no. I specifically want that addresses be assigned to
*interfaces* (not nodes, file systems, data bases, etc) as
I said in my message to Louise. The text will be fixed.

Fred

---

From: Tony Li <[email-masked]>
Date: Tue, 20 Mar 2007 10:05:55 +0100

On Mar 20, 2007, at 2:14 AM, Geoff Huston wrote:

> There is no single 'identity" - there are a plethora of such  
> identities today groupd within a large set of 'realms' of identity,  
> and I believe that they are an enduring aspect of this environment.  
> This does not lead me to a "we are heading to a CNLP-liker  
> destination" conclusion, as there is no single useful encompassing  
> identifier here, nor do I see any use of value in trying to  
> construct such a beast! As far as I can see there are, and will be,  
> many forms of identity and are, and will be, many ways to map  
> between various identity realms at various levels in the protocol  
> stack.

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.

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?

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.

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

Regards,
Tony

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 20 Mar 2007 02:18:38 -0700

Tony, 
 
> system identifiers and so are following the obvious path and  

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. 

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

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

> 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