RE: ISP failures and site multihoming [Re: Enforcing unreachabilityof site local addresses]

[Iljitsch van Beijnum <iljitsch@muada.com>]

On Fri, 21 Feb 2003, Bound, Jim wrote:

> SCTP
> is a clear winner for us here over TCP and it's a new API so we could go
> there.  But more importantly the transition to this requires code on the
> end systems from suppliers, and then either apps change or shims are
> built on the end systems. Doing it with TCP is possible till SCTP is
> more dominant.  This is solving the problem at layer 7 and 4. And that
> means we need new platform code releases and development to make it
> happen.  Which is fine but will take time.

> Layer 1 and 3 may be able to do something too but that will take time
> and require new code and platform releases.

Well, the "let's do it fast" ship has sailed a long time ago (it is
presumed to have hit an iceberg). So we only have the choice to do it
right or not.

It's time we start to rethink what we're trying to do here. Sure, SCTP
will provide some functionality. HIP also. Add a header here, a tunnel
there, maybe a little aggregation... It will all help with the problem
at hand to a certain degree, but it will break nearly as much as it will
fix and in 10 years we'll be doing it all again for IPv7 or OSIv3.

The problem with the IPv4->IPv6 transition is that all applications have
to change. That sucks. So what is it we do? We replace the socket API
that sucks with an API that sucks with bigger addresses. If we're going
to do SCTP, we'll be replacing the API with one that sucks with multiple
addresses. (I'm not about to apologize for saying the socket API sucks,
I've programmed with it.)

If we're going to change applications, we need to do it in such a way
that we won't have to do it again. So regular applications such as
remote login, email or webbrowsing only get to see the information about
a connection that they must, by their nature, always be able to parse.
That would be a hostname. Or an email address. Or maybe even an X.509
certificate. But NOT the plumbing, because we'll want to change that
later as new technology becomes available, WITHOUT having to change our
apps again.

If we can agree on this and recognize the fact that changing the IPv6
packet format and routing paradigm at this stage is counterproductive,
the rest should be easy.

> P.S. Mutli6 should not MUST SCTP as Diameter tried (well was forced)
> that and all the Diameter products shipping are doing it with TCP and
> same for some other things like RDMA. But Multi6 could do the community
> a big favor by stressing that SCTP really helps this problem within its
> inherent failover capabilities via the network association for the
> connections.

No idea what you're referring to here.