[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: An idea: GxSE
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).
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,
> 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.