Subject: RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir]

From: "Tony Li" <[email-masked]>
Date: Thu, 8 May 2003 16:08:01 -0700

I would prefer that we avoided having a stateful mapping mechanism.
It's unnecessary and certainly more complication than we need.

I would also prefer that we not proclaim something to be GSE that
isn't, regardless of congruence or continuation of ideas.  GSE
is a specific idea and while it can certainly evolve, I think it's
a disservice to mo to re-use his name for something else 
without his permission.

Tony

|    -----Original Message-----
|    From: Iljitsch van Beijnum [mailto:[email-masked]] 
|    Sent: Thursday, May 08, 2003 3:33 AM
|    To: Brian E Carpenter
|    Cc: [email-masked]
|    Subject: Re: GSE IDs [Re: IETF multihoming powder: just 
|    add IPv6 and stir]
|    
|    
|    On donderdag, mei 8, 2003, at 11:50 Europe/Amsterdam, 
|    Brian E Carpenter 
|    wrote:
|    
|    >>> and it involves stateful distribution of mapping 
|    information. A very
|    >>> different beast from GSE, and it sets off my 
|    stateful=bad alarm.
|    
|    >> Actually this wouldn't be a problem at all since we 
|    have to keep this
|    >> exact same state anyway in order to map the other way around for
|    >> sending packets back.
|    
|    > Again, not in GSE as I understand it.
|    
|    I don't think it's a coincidence that there hasn't been 
|    any progress 
|    with GSE for five years or so. In theory, GSE can work without a 
|    mapping mechanism, but this opens the door to security 
|    problems. So in 
|    practice we need to keep state to know whether there is a 
|    valid locator 
|    <-> identifier mapping to avoid trivial identity theft. And if we 
|    accept that, we may as well remove the whole globally 
|    unique lower 64 
|    bit thing as it just breaks too much stuff without any 
|    real benefits at 
|    this point.
|    
|    Aside from that, not having a mapping mechanism makes 
|    failover very 
|    difficult: the only way that still works is if the border 
|    router at the 
|    source sees the problem. This works for last mile 
|    problems, but not for 
|    routing problems further upstream. I know others have different 
|    experiences, but for me routing problems are the number 
|    one cause of 
|    outages.
|    
|    Is there anyone who wants to stick with GSE without a 
|    mapping mechanism?
|    
|    
|

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 9 May 2003 10:49:05 +0200

> I would prefer that we avoided having a stateful mapping mechanism.

It all flows from having more than one address with different 
reachability properties. At some point, someone has to decide which 
address to use for a particular purpose, and it had better be the 
"right" address most of the time or we're worse off than being 
single-homed.

> It's unnecessary and certainly more complication than we need.

It doesn't have to be complicated: something as simple as publishing 
all the addresses in the DNS and/or in an option in the first packet 
along with a simple algorithm that figures out which address seems to 
be working best is all we need. (But it may not be all we want.)

What kind of stateless mechanism do you have in mind? Obviously a 
stateless solution would be preferable over a stateful one.

> isn't, regardless of congruence or continuation of ideas.

I did use the term "GSE" a bit loosely a week or so ago but rest 
assured that this won't happen in the final version of the draft.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 13 May 2003 10:04:31 +0200

On fredag, maj 9, 2003, at 10:49 Europe/Stockholm, Iljitsch van Beijnum 

> stateless solution would be preferable over a stateful one.

What worries me as ex-operator is that state in a network comes at a 
cost. Normally state is actually among the most costly components of 
network design. So, I agree that I would like to avoid any stateful 
mapping. Now, that said I agree that a stateless mechanism is going to 
harder to design and implement.

> assured that this won't happen in the final version of the draft.

I think we need to define a new term to denote a id/loc separation 
solution.

- kurtis -