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

[Tony Li <tli@cisco.com>]

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

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