Subject: RE: GSE

From: "Tony Li" <[email-masked]>
Date: Mon, 4 Nov 2002 15:37:37 -0800

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
|

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 4 Nov 2002 15:54:03 -0800

Tony Li wrote:
> ...
> as an architectural principle.  [I'm not married to this, but 
> I am exploring this.]
> 

Taking the next step, the system that the border router would need to
look that identifier up in would need to churn as the identifier moves
from home, to Starbucks, to the airport, to the hotel... If it is to
scale comparable to DNS, there needs to be distributed caching, which in
turn leads to TTLs, and a minimum period between usable movements. 

In the abstract, isn't this approach just a global learning bridge where
the table is external to the forwarding engines?

Tony

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 5 Nov 2002 01:29:27 +0100 (CET)

On Mon, 4 Nov 2002, Tony Hain wrote:

> If it is to

You need an identifier to locator mapping service to find at least one
working locator. Extra non-working locators may slow session
establishment down a bit, but aren't really a problem otherwise. More
locators can be negotiated at session establishment or later.