Re: An idea: GxSE

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

BTW, folks...I think some of this might be of interest to irtf-rr, since
we're really talking about the important issues related to multihomed
routing.  There are folks on irtf-rr that would have some great stats for
us, and others with other input.

On Thu, 21 Jun 2001, Joe Abley wrote:

> Date: Thu, 21 Jun 2001 15:28:36 -0400
> From: Joe Abley <jabley-ietf@automagic.org>
> To: Daniel Senie <dts@senie.com>
> Cc: Paul Francis <paul@francis.com>, multi6@ops.ietf.org
> Subject: Re: An idea: GxSE
> 
> On Thu, Jun 21, 2001 at 03:17:37PM -0400, Daniel Senie wrote:
> > At 02:57 PM 6/21/01, Joe Abley wrote:
> > >On Thu, Jun 21, 2001 at 02:35:26PM -0400, Daniel Senie wrote:
> > > > 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.
> > 
> > >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.
> 
> I'd be interested to know exactly what you were advertising, and
> what failure scenarios cause TCP sessions reliably to die; sounds
> like it might be worth comparing it to what we did in 4768, since
> our experience is interestingly different. If you would like to
> follow this up, please feel free to mail me privately (we can
> summarise if there are relevant conclusions).
> 
> One question you might ask yourself, however, is whether there might
> have been re-homing events elsewhere between your network and the
> destination that TCP sessions might have survived without you knowing.
> Can you definitely conclude that TCP sessions invariably collapsed?
> Or is there a chance that there were other re-homing scenarios during
> which TCP sessions survived without you noticing?
> 
> > 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.
> 
> 
> Joe
> 

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