Re: updating GSE for the new millennium

[David Conrad <david.conrad@nominum.com>]

Iljitsch,

On Wednesday, April 30, 2003, at 07:19  AM, Iljitsch van Beijnum wrote:
> We've been talking about GSE earlier this month before we got 
> side-tracked. I think it's time to see what a descendent of the GSE 
> family would look like in the third millennium, so I want to write a 
> draft. Hopefully this will give us something useful to talk about in 
> Vienna.
Hmm.  I am doing the same thing (although I'm not planning on being in 
Vienna).

> What I'd like to do is take input from everyone and incorporate this 
> as much as possible in this draft. That probably means more options 
> and more complexity that we'd like to see in an actual protocol, but 
> for now that's fine: we can always prune later.
I would suggest starting the other direction -- the IETF already has 
way too many drafts that try to be all things to all people.  Start 
with a simple, easily understood base and see how far that gets you.

> The first order of business is the address rewriting. It seems to me 
> that the different options here (GSE-like one-way rewriting upper bits 
> with globally unique lower bits, MHAP double rewriting) can be 
> accommodated by doing the following:
>
> When transmitting, for both the source and destination address: take a 
> globally unique N bit label and map to one of several possible IPv6 
> address suitable for routing associated with this label. When 
> receiving, map the addresses back to labels.
Depending on your approach, it may not be necessary to rewrite the 
source address.

> For the source when transmitting or the destination when receiving, 
> the rewriter can presumably easily find the additional information 
> needed to compelete the mapping in its configuration, but for the 
> destination when transmitting or the source when receiving it must 
> first discover the mapping.
Yes.  I believe it'll turn out that this discovery is where the 
complexity (political if not technical) will lie.  I do not believe it 
to be a difficult technical problem, however I'm sure any solution 
proposed will be controversial.

> Is this workable?
I think so.

> Two additional questions:
> - Is adding options or tunnel headers an option,
I don't think so.  Options increase complexity as they result in making 
it impossible to do "in-place" rewrites.  You generally have to 
synthesize a full header then append the data of the original packet 
after the options.  Tunnel headers get you into trouble with MTUs and 
fragmentation.  Avoiding these if possible would be a good idea I 
believe.

> - Can packets only be rewritten once, or can this happen several times?
Address rewriting (at least as described above) would appear to me to 
be end-to-end transparent.  As such, I'd say yes, although I'm not sure 
I see the point.

Rgds,
-drc