Re: An idea: GxSE

["Jon (Taz) Mischo" <taz@tazlore.com>]

On Thu, 21 Jun 2001, Daniel Senie wrote:

> Date: Thu, 21 Jun 2001 15:17:37 -0400
> From: Daniel Senie <dts@senie.com>
> To: Joe Abley <jabley-ietf@automagic.org>
> Cc: Paul Francis <paul@francis.com>, multi6@ops.ietf.org
> Subject: Re: An idea: GxSE
> 
> At 02:57 PM 6/21/01, Joe Abley wrote:
> >On Thu, Jun 21, 2001 at 02:35:26PM -0400, Daniel Senie wrote:
> > > At 02:19 PM 6/21/01, Paul Francis wrote:
> > > > >
> > > > > 1) Site is multihomed and one of the links to the ISP is broken and
> > > > >    how we get around this without breaking any connections.
> > > > >
> > > > > 2) Site is multihomed and there is a long running e.g. TCP connection
> > > > >    which needs to survive in the case of renumbering.
> > > > >
> > > > > So, we are addressing (1) in this WG. Hence, the use of word 
> > renumbering
> > > > > is confusing to me. Could somebody clarify this ?
> > > > >
> > > >
> > > >I think, broadly stated, the goal of the wg is to have the same 
> > multihoming
> > > >functionality with IPv6 as we have with IPv4, but done in a scalable way.
> > > >But multi6 is producing a requirements document that will clarify things.
> > > >
> > > >With IPv4 multihoming today (ignoring the NAT case), case 1 works, so
> > > >presumably we want this functionality with IPv6.  Even so, I think in most
> > > >cases losing a connection because an ISP went down would be acceptable, as
> > > >long as new connections indeed chose the other ISP.
> > >
> > > In the present Internet, the sessions already break when a link dies. The
> > > backbone convergence is taking too long for applications in many cases,
> > > from my observations. So, application writers either have to build in
> > > auto-reconnect logic, or their apps are going to have problems.
> >
> >This is not my experience. TCP session stability around a re-homing
> >event (i.e. the session recovers, and does not fail) is common, even
> >when end-points are relatively remote (my experience is between New
> >Zealand and Europe).
> 
> It is my experience with a variety of access services around New England.

If this is such a big deal, use SCTP.  That's what it's there for.  If you
really care how a session survives network topogoly changes and BGP flap,
use SCTP, as it's designed to handle this.

> >Remember that full convergence across the internet is not necessary
> >for packets to continue to reach their proscribed destinations; ASes
> >route with default, withdrawn prefixes are covered by aggregates,
> >etc.
> 
> We see the traffic die at the first default-free router. Sessions usually 
> time out while the BGP withdrawals are still flapping around.
> 
> 
> > > So, I don't know that there's much problem with the new sessions starting
> > > with different addresses, provided end systems are told in some way 
> > that an
> > > upstream link died (i.e. they have to know to use the other link).
> >
> >The problem is that the current multi-homing strategies in use with v4
> >provide for session stability, and we are trying (as far as is possible)
> >to encapsulate the capabilities of the current architecture in the
> >requirements for the new one.
> 
> I understand that, but I disagree that the present mechanism works in the 
> real world, so the question is whether it's a worthwhile requirement going 
> forward. You've seen good results in the face of rerouting, I've seen very 
> bad results. Two data points don't tell us a lot. The question should be 
> asked, though, as to whether the present mechanism is working and thus 
> worth keeping, before engraving it in stone for IPv6.

As a whole, I've seen a lot of bad convergence.  Sometime convergence is
fast, but that's pretty rare with BGP.  Your individual mileage WILL vary,
depending on where the network is broken, and how aggregation is done
behind it.  Sometimes it's good, sometimes it's bad.

-Taz

-- 
        "Be liberal in what you accept,
      and conservative in what you send."
--Jon Postel (1943-1998) RFC 1122, October 1989