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

[marcelo bagnulo <marcelo@it.uc3m.es>]

I guess that what Brian means is that this (what you are describing) is
not GSE anymore, since it is not stateless (which is a fundamental
feature of GSE, as i see it)

It is just a matter of name.

what you are describing sounds more like MHAP...

So as someone suggested earlier, i think i would be better to find a new
name (or just avoid mentioning GSE) in order to avoid misunderstandings.

Regards, marcelo  

n Thu, 2003-05-08 at 12:33, Iljitsch van Beijnum wrote:
> 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?
-- 
marcelo bagnulo <marcelo@it.uc3m.es>
uc3m