RE: GSE

["Tony Li" <Tony.Li@procket.com>]

Thomas,

Thanks.

I've seen the light and see another case that makes it necessary to
have an identifier to locator mapping.  

Suppose that we wish to insure that hosts do not play with locators 
as an architectural principle.  [I'm not married to this, but I am
exploring this.]

Now, when a host receives an incoming connection, it needs to reply 
to that particular identifier, but it has no idea what host name is 
associated with the identifier.  The border router then needs to do 
an identifier lookup to determine the locator for the originator of 
the connection.  

Tony


|   > In any case, I'm not convinced that there's a LOT of need to
|   > have an identifier to locator mapping.  You need a hostname to 
|   > identifier and locator mapping, but when would you go from 
|   > identifier to locator without the hostname?
|   
|   The standard argument has been that if you can't perform a mapping
|   from identifier to locator, it limits the ability to recover from
|   failures where the existing binding stops working. I.e., how do you
|   recover a TCP connection when this happens?
|   
|   I.e, either recovery is not possible (in some scenarios), or it's
|   pushed back to higher layers (e.g., application and DNS lookup). But
|   if the application is responsible for recovery, its not clear how
|   attractive a solution this would be in practice (or how much more
|   benefit one gets compared to using full-blown addresses with no
|   separation of identifier and locator, as apps could do the same sort
|   of failure recovery today).
|   
|   Of course, how often such failures will occur and thus how important
|   it is to deal with them depends on a lot of 
|   details/assumptions about
|   how frequently and underwhat conditions the bindings become invalid.
|   
|   Thomas
|