Re: An idea: GxSE

["Paul Francis" <yoid2000@home.com>]

>
> Unless I'm really misunderstanding something here, I was under the
> impression we're talking about fixed-site multihoming and address space
> change renumbering - the bane of every large site's existence.  As such, I
> think we're not talking about mobility.  We're talking about the v4

Right, this is not about mobility.

> new address, the GR prefix only changes.  In plain terms, you're binding a
> socket between the SK addresses only, the rest is smoke and mirrors.

GxSE doesn't bind just the SK address to the socket, it binds the complete
set of addresses (SK and GR) to the socket.

> routers are essentially rewriting the headers.  Think of it as NAT with a
> 1:1 translation combined with the equivalent of a set of BGP announcements


> via several different AS's.  If one route goes down, the GR prefix would
> change on one end of a connection, but the SK address would stay the same,
> and you're connected between SK's.  BGP for hosts :)

You are reading too much into the SK.  The purpose of the SK (I should have
said this in my original note) is so that one end knows what the other end
originally sent.  Waving my hands a bit, this means that, if the host put
the SK address in the application, the application at the other end would be
able to interpret that SK as "the whole list of addresses bound to this
connection".

The NAT comparison is (sadly) appropriate.  In particular, the site border
router would have to go in and change application headers, for instance the
SIP SDP, in order to change an SK address on the inside to a GR address on
the outside.  (Or I suppose I can imagine a sockets call in the host like
getcurrentaddresslist() that sent a ping to the site border router or the
partner host and got the list of addresses back, so that those applications
that cared could learn it...though it begs the question what is the
difference between this and renumbering...)


Your BPG/landmark routing comparisons went over my head.

PF