Subject: Re: An idea: GxSE

From: Mohan Parthasarathy <[email-masked]>
Date: Thu, 21 Jun 2001 10:05:38 -0700 (PDT)

> > 
> > When you are moving around, you are getting new prefixes and the old
> > prefixes will not be valid after sometime. (The difference between
> > this and mobility is that the old prefix is considered to be valid
> > in mobility)
> 
> You're not moving around a lot.  Again, this isn't mobility.  This is
> often the result of a circuit or router going down in the case of
> multihoming.  In thse situations, the prefix is never invalidated, it's
> just useless for a while.
> 
Interestingly i could not find the work "renumbering" anywhere
in the charter. I am assuming it should be understood implicitly.
 So, there are two cases

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 ?

thanks
-mohan

---

From: "Paul Francis" <[email-masked]>
Date: Thu, 21 Jun 2001 11:19:25 -0700

> 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.

Case 2 is less clear, because we really don't have renumbering with IPv4.
I'd argue myself that we should not go out of our way to design for case 2,
for the reasons I said before (it is relatively rare, and you should in most
cases be able to overlap the old and new prefixes so that most long-term
connections will have naturally terminated on their own).

PF

---

From: Daniel Senie <[email-masked]>
Date: Thu, 21 Jun 2001 14:35:26 -0400

>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.

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).

-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

---

From: Joe Abley <[email-masked]>
Date: Thu, 21 Jun 2001 14:57:32 -0400

> 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,
etc.

> 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.

Joe

---

From: "Jon (Taz) Mischo" <[email-masked]>
Date: Thu, 21 Jun 2001 14:42:23 -0500 (CDT)

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 <[email-masked]>
> To: Daniel Senie <[email-masked]>
> Cc: Paul Francis <[email-masked]>, [email-masked]
> 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:
> > It is my experience with a variety of access services around New England.
> > 
> > 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

---

From: Joe Abley <[email-masked]>
Date: Thu, 21 Jun 2001 15:28:36 -0400

Joe

---

From: "Paul Francis" <[email-masked]>
Date: Thu, 21 Jun 2001 12:24:09 -0700

> worth keeping, before engraving it in stone for IPv6.

Are you talking about route flapping and BGP?  If so, this is orthogonal to
the multi-homing problem (though not unaffected by it, if we can reduce
routing table size).

Are you multihomed?  Maybe if you were, then you could avoid this problem by
re-routing your traffic  :-)

PF

---

From: Daniel Senie <[email-masked]>
Date: Thu, 21 Jun 2001 15:17:37 -0400

---

From: "Jon (Taz) Mischo" <[email-masked]>
Date: Thu, 21 Jun 2001 14:40:42 -0500 (CDT)

On Thu, 21 Jun 2001, Daniel Senie wrote:

> Date: Thu, 21 Jun 2001 15:17:37 -0400
> From: Daniel Senie <[email-masked]>
> To: Joe Abley <[email-masked]>

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.

> 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