Subject: RE: Fwd: Minutes / Notes

From: "Grovesteen, Harold" <[email-masked]>
Date: Thu, 17 Jul 2003 14:01:16 -0500

YES!

-----Original Message-----
From: Tony Li [mailto:[email-masked]]
Sent: Thursday, July 17, 2003 12:38 PM
To: J. Noel Chiappa; [email-masked]
Subject: RE: Fwd: Minutes / Notes

Noel,

|    This is only important if you want TCP connections to be 
|    able to survive
|    having an incoming link fail (i.e. the address on the 
|    local end becomes
|    unreachable to the rest of the network). This may not be 
|    an important goal
|    (e.g. the typical web site wouldn't care).

I believe that the WG has come to rough consensus that this is,
in fact, an important goal for us to solve.  There are 
numerous practical applications that drive this.  More generally,
we (IETF, vendors) are being asked to make the Internet safe
for "mission critical" applications and having broken TCP
connections is simply unacceptable.  Many applications today
are being outsourced: backups, storage, business applications,
interactions within an 'extra-net', etc.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Jul 2003 09:57:53 +0200

Well, this is one of the many "shoulds" in our agreed list
of goals. Whether we can achieve this "should" simultaneously
with enough of the others is very much an open question
in my mind, and it's one of the reasons why we may end up
with more than one solution. In some scenarios, this may
be a dominant goal; in other scenarios, it may be unimportant.

  Brian

---

From: Pekka Savola <[email-masked]>
Date: Fri, 18 Jul 2003 11:12:46 +0300 (EEST)

> be a dominant goal; in other scenarios, it may be unimportant.

I agree that handling broken connections is useful.

However, I also think that one must apply some reason here.  For example, 
if you have have tunnels from two access routers to two ISP's ("site exit 
routers approach"), I don't think you have to care about connection 
survivability that much.

ISPs' networks don't crash every other day (if they do, change the ISPs;  
we just can't design protocols to work around broken operational
practices: that's going to fail, no matter what).  Might happen a couple
of times during the year, at most, but I'm not convinced that's
necessarily a huge problem.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Joe Abley <[email-masked]>
Date: Fri, 18 Jul 2003 11:05:17 -0400

> necessarily a huge problem.

This isn't about ISPs' networks "crashing" -- it's about transient 
changes in routing topology, which *do* happen with monotonous 
regularity (circuits fail, or take errors and have to be shut down; 
upstream providers fat-finger routing policy and stopping routes from  
propagating, etc). Also remember that the effects of a re-homing event 
can be felt several levels down; if your path to the DFZ is through 
three intermediate ASes, then you're three-times as likely to feel the 
impact of a re-homing event if the multihoming architecture presents an 
impact to be felt. In some countries, *all* the ISPs are two or three 
ASes away from the core.

The fact that the perception today is that "ISP networks don't crash 
every other day" says more about the functionality of current 
multi-homing practices than it does about the stability of the 
underlying infrastructure.

Joe

---

From: "marcelo bagnulo" <[email-masked]>
Date: Sun, 20 Jul 2003 17:41:52 +0200

Hi Pekka,

[...]

> necessarily a huge problem.

Do you think that this is an acceptable solution fo very small sites?
I mean, suppose an scenario where very small site multihoming becomes very
frequent, so the number of those sites is very high.
site Exit router approach requires manual configuration of the tunnels by
both ISPs, so do you think that isps will be willing to do this for very
small sites?

An complementary approach would be to use some sort of tunnel broker so that
the site itself could configure its own tunnels, so the isps operators do
not have to deal with this, what do you think?

Regards, marcelo

---

From: Pekka Savola <[email-masked]>
Date: Mon, 21 Jul 2003 09:43:13 +0300 (EEST)

On Fri, 18 Jul 2003, Joe Abley wrote:
> propagating, etc). 

Fat-fingering in critical places is a real problem -- more so than many 
other problems like circuit failures, but most of these are not visible to 
the edge network.

> Also remember that the effects of a re-homing event 

Nope, it's not as simple as that.

Please remember the context here: we're talking about the connection
surviability of the end-user.  What happens several AS's upstream doesn't
typically matter *at all*.  Sure, some circuit goes down, and traffic gets
re-routed.  These almost always cause a quick re-routing, not e.g. falling
back to BGP hello timeouts. These are not things that are (typically)  
visible to the end-users, and do not trigger rehoming events.

The most important things, as it seems to me, are:
 - your own resiliency
 - the connection between you and your ISP(s)
 - your first-hop ISP's network characteristics, configuration, etc.

So, in this context, I'm not sure that in practice the connection 
survivability is a strict requirement.  IMHO, the quality of your 
first-hop ISP is the thing that matters the most.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 21 Jul 2003 09:53:30 +0300 (EEST)

> both ISPs, so do you think that isps will be willing to do this for very

I don't really think the "site-exit routers approach" scales for very 
small sites ("home networks").

But then again, my perception is that very small sites can easily live 
without connection surviability.  These aren't really mission-critical 
systems, systems where network downtime could cost e.g. 1000$ a minute.

The ability to start new connections using the other connectivity is 
probably good enough for most folks.

When one says "very small sites", you could count inside that a guy who
has a mobile terminal and has e.g. GPRS and WLAN interfaces (or something
else), a laptop, and wants to keep his connections open while he moves or
switches between the two.  Sounds like the Mobile IPv6 problem space to
me.

> not have to deal with this, what do you think?

If something like this would be required, I would certainly guess that
there would be some mechanism for automation, be it using some DHCP prefix
delegation extension, or whatever.  However, I haven't really thought
about it, and I would really rather see that those very small sites don't
require any mechanisms which require anything other that very light-weight
infrastructure.

---

From: Joe Abley <[email-masked]>
Date: Mon, 21 Jul 2003 06:39:52 -0400

> visible to the end-users, and do not trigger rehoming events.

Right, that's the case right now.

However, if a re-homing event between the user and the DFZ forces a 
renumbering event (for example), and there's no transport-layer support 
for session stability over that renumbering event, then the user will 
see their sessions die.

>  - your first-hop ISP's network characteristics, configuration, etc.

That is the case with today's IPv4 multi-homing, since the multi-homing 
model provides endpoint address stability. In the case of an alternate 
multi-homing model which doesn't provide address stability, users will 
feel pain.

Joe

---

From: Pekka Savola <[email-masked]>
Date: Mon, 21 Jul 2003 13:59:49 +0300 (EEST)

On Mon, 21 Jul 2003, Joe Abley wrote:
> > surviability of the end-user.  What happens several AS's upstream
> > doesn't typically matter *at all*.  Sure, some circuit goes down, and
> > traffic gets re-routed.  These almost always cause a quick re-routing,
> > not e.g.  falling back to BGP hello timeouts. These are not things
> > that are (typically) visible to the end-users, and do not trigger
> > rehoming events.
> 

Indeed.

I don't think this is all that common case, though.  I'd really wish to
know of events like these in the DFZ that caused a re-routing delay long
enough (e.g. over 30 secs) to be an annoyance.

> multi-homing model which doesn't provide address stability, users will 

Yes.  Which is why multiple PA + a tunnel through a second ISP is actually 
a rather good solution (IMHO).  Not enough for everybody, certainly, but 
good nonetheless.

---

From: Joe Abley <[email-masked]>
Date: Mon, 21 Jul 2003 07:22:46 -0400

> enough (e.g. over 30 secs) to be an annoyance.

It's not at all a common case right now, because right now re-homing 
events are handled in the v4 network today without anybody having to 
renumber.

The issue of whether path instability causes session resets is 
different. I don't think it happens very often (unless accompanied by 
rapid route flapping which causes prefixes to be damped out for 
noticable periods), but I don't know of any formal study.

Joe

---

From: S Woodside <[email-masked]>
Date: Wed, 23 Jul 2003 19:53:49 -0400

> probably good enough for most folks.
Pekka, That seems reasonable, another dimension to add to the taxonomy 
of multihoming users? I would agree that the smallest sites would think 
connection survivability less important.

simon

--
www.simonwoodside.com -- 99% Devil, 1% Angel