Subject: RE: GSE

From: "Tony Li" <[email-masked]>
Date: Fri, 1 Nov 2002 11:00:02 -0800

Let me suggest some ways that 16+16 might work:

|   - GSE doesn't provide any failover mechanisms but depends 
|   on tunnels to
|     repair dead customer<->ISP links. This could be done just 
|   as easily
|     with regular PA space.

Each host needs to advertise its locator to correspondent hosts.  Whether
this happens via DNS or via a mobile IP type solution is more detailed
than we need to be right now, but basically, the correspondent can
get multiple locators for any MH host.  Failover in this case is simply
changing the locator in the packet and does not require tunneling.

|   - It is very unclear how GSE is supposed to work in a single host
|     environment. Do hosts that don't sit behind a GSE-capable border
|     router the GSE processing themselves or is this done by the ISP?

It seems to me that either is a viable solution at this point.  Both may
even be necessary.

|   - It needs changes to transport protocols and possibly to intra-site
|     routing and address discovery.

It certainly requires changes to the transport protocols.  I don't see
any changes to intra-site routing unless one wants to be MH within the
site between IGP areas.  

|   - The flat part of the identifier space makes locator 
|   discovery hard.

Identifiers need not be flat.  They could be hierarchically assigned
administrative entities.

Tony

---

From: Greg Maxwell <[email-masked]>
Date: Fri, 1 Nov 2002 14:49:35 -0500 (EST)

> any changes to intra-site routing unless one wants to be MH within the

Within an IGP area I would suggest that we flood routes like on today's
networks (classic multihoming).

It's global where the aggregation is a concern. If any single network
becomes large enough for it to be a problem, then you break it up and
confine the routes of each portion to that portion.

In any case, the cost and instability caused by having routes is carried
only by those creating the routes.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 1 Nov 2002 22:26:28 +0100 (CET)

> changing the locator in the packet and does not require tunneling.

Yes, switching to a different locator is what we want to do when a
failure occurs. However, the GSE draft doesn't.

Determining when to change locators isn't an altogether trivial
exercise. This is where we can use the help from TCP, since it knows
about timeouts and retransmissions, the IP layer has no idea about any
of this stuff.

> Identifiers need not be flat.  They could be hierarchically assigned

EUI-64 identifiers don't have a hierarchy that is of use to us. Using
anything else means autoconfiguration has to be changed.

None of this is impossible, but what exactly is it about the 6+2+8 thing
that makes it worth going through all this trouble? If you simply assign
people a PI /48 you can use this address block as identifiers and
replace the first six bytes to make locators. The only "problem" with
this is that you have to replace the first six bytes in the address with
the original ones at some point, but it's much easier to make that
happen than having transport protocols only look at the bottom 64 bits.
If only because some box at the edge can do this.

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 4 Nov 2002 14:21:52 -0500

> any changes to intra-site routing unless one wants to be MH within the

It probably also requires changes to the IPv6 sockets API, because one
most probably would NOT want an application to include the location 
information
in any part of the transport-layer state.  The *identifier* information
would seem to be reasonable as part of transport-layer state.

> Identifiers need not be flat.  They could be hierarchically assigned

Getting the area of naming/addressing discovery engineered properly
is non-trivial, but I think it is possible (always the optimist :-).

Ran
[email-masked]