[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: An idea: GxSE
- To: Paul Francis <email@example.com>
- Subject: Re: An idea: GxSE
- From: "Jon (Taz) Mischo" <firstname.lastname@example.org>
- Date: Wed, 20 Jun 2001 15:57:59 -0500 (CDT)
- cc: email@example.com
- Delivery-date: Wed, 20 Jun 2001 13:57:50 -0700
- Envelope-to: firstname.lastname@example.org
On Wed, 20 Jun 2001, Paul Francis wrote:
> GxSE doesn't bind just the SK address to the socket, it binds the complete
> set of addresses (SK and GR) to the socket.
Why not bind the SK if it's globally unique? There is 1 SK, and multiple
GR's. Why not bind only the SK's and keep a table of valid GR's, so you
know that it is truly valid? You already know that the GR you're bound to
is wrong, why not assume the same for both sides, simplify the host
software, and use the GR similar to an MPLS label (I hate to say it, but
it reminds me a bit of exactly that...you just can't nest them).
Basically, this would be taking a lesson from both BGP and MPLS, applying
the simplest part to the host, letting the router do what it already does,
changing far less overall, and still getting the same results.
> 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
This is the description of an SCTP association. This is almost exactly
SCTP through NAT. My suggestion above takes a similar idea, but lets the
network do most of the multihoming instead of the protocol. Otherwise
you're basically talking about using NAT and SCTP together and calling it
something else, with a few small tweaks and dropping the heartbeat, etc.
This same effect can be generated using SCTP through NAT with ECN and a
small change to allow ECN to trigger instant address switch instead of
backing off first.
> 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.
Hrmmm...a shame, because I think that's what would really make this very
"Be liberal in what you accept,
and conservative in what you send."
--Jon Postel (1943-1998) RFC 1122, October 1989