Subject: RE: WG next steps

From: "Christian Huitema" <[email-masked]>
Date: Thu, 14 Nov 2002 11:21:37 -0800

> |   I agree with Shane. Although I would prefer a routing solution (it
> |   appears to me that host solutions are a way to get around a
network
> |   structure that does not preserve end-to-end) I think that
> |   part of the
> |   puzzle might be non-routing host solutions.
> 
> 
> I have no problems with transport changes being part of the solution.
> In fact, I expect that that's a requirement.  However, dealing with
> DFZ explosion IS a big part of the problem and it MUST be addressed
> by routing and addressing changes.  Today's IPv4 architecture doesn't
> scale and MUST NOT be propagated into IPv6.

There are really two classes of solutions. I would categorize them as
"host multi-homing and network multi-homing".

The network multi-homing solution assumes that a network gets several
providers, and that the routing fabric somehow manages to make all these
providers behave as one. In the current architecture, the network gets a
single prefix, and the impact on the DFZ could be immense. 

The host multi-homing solution assumes that the host has several network
providers, and that these providers are not in any way aware of each
other. For example, a host may have a GPRS connection to ATT wireless
and a DSL connection to Earthlink. In the current architecture, the host
gets different addresses from the different providers. There is no DFZ
explosion, since each of these addresses gets aggregated in the
provider's prefix. The main impact is on the host software. Today we
have at least a partial solution, with the address selection rules; we
could combine that solution with a variation of Mobile IPv6 for better
resiliency.

I believe that the host multi-homing solution can be extended to provide
site multi-homing. I wrote a draft explaining how; basically, it
requires some cooperation between the exit routers of the site. Michel
Py suggested that it could be made to work even better if the providers
somehow cooperated, e.g. were ready to install some back-up tunnels to
redirect packets bound to a failing interface; this kind of back-up
tunnel only impacts the provider's IGP, without affecting the DFZ. In
short, making host multi-homing work for a site appears to be an
engineering effort, not a research effort.

I suggest we charter two follow-on efforts, one to explore a network
based solution and one to explore a host based solution.

-- Christian Huitema

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 14 Nov 2002 22:13:47 +0100 (CET)

> other.

[...]

> based solution and one to explore a host based solution.

Do we think it is worthwhile to continue down the network/routing based
solutions? The lack of feedback on my draft suggests people aren't very
interested in working on this. If we want to do this at the routing
level, we have start exploring less obvious stuff. For instance, using
the flow label or diffserv code points to swim across the default zone
towards a network that knows more specific routing information.

But there seems enough interest in multi-address/host based solutions.

---

From: "Craig A. Huegen" <[email-masked]>
Date: Fri, 15 Nov 2002 09:04:46 -0600 (Central Standard Time)

> based solution and one to explore a host based solution.

I support this.  As a general rule, I feel that larger organizations are
going to want network-based solutions for multihoming; smaller
organizations are most likely to accept either.

/cah

---
Craig A. Huegen, Chief Network Architect      C i s c o  S y s t e m s
IT Transport, Network Technology & Design           ||        ||
Cisco Systems, Inc., 400 East Tasman Drive          ||        ||
San Jose, CA  95134, (408) 526-8104                ||||      ||||
email: [email-masked]       CCIE #2100      ..:||||||:..:||||||:..

---

From: "Craig A. Huegen" <[email-masked]>
Date: Fri, 15 Nov 2002 09:11:33 -0600 (Central Standard Time)

> But there seems enough interest in multi-address/host based solutions.

There is absolutely an interest in the network/routing based solutions.
It's just that the operator folks who will be using them significantly as
they're deployed probably aren't in this forum (or are trying to keep up
with billions of other things at the moment).

It is undesirable for a large enterprise to use a multi-address/host based
solution without a mechanism to interact with the network topology to
perform path selection.  Network operators know more about the viability
of paths (whether by technology or manual policy) than the hosts do.
Left-side longest-match is hardly a sufficient routing protocol and/or
policy control for a multi-provider topology like the Internet.  The
network *MUST* be a part of the solution -- enterprises want policy
control, and policy control should be centralized.

/cah

---

---

From: "Michael H. Lambert" <[email-masked]>
Date: Fri, 15 Nov 2002 11:15:25 -0500

> control, and policy control should be centralized.

Succinctly put.  However I don't think size matters as much as does the 
existence of policy.  Only the hardware/software/wetware at the edge of the 
enterprise is likely have the necessary information to enable rational path 
(and, therefore, source and destination address) selection.

Michael

+-----------------------------------------------------------------------+
| Michael H. Lambert, Network Engineer           Phone: +1 412 268-4960 |
| Pittsburgh Supercomputing Center               FAX:   +1 412 268-8200 |
| 4400 Fifth Avenue, Pittsburgh, PA  15213       [email-masked]        |
+-----------------------------------------------------------------------+

---

From: "marcelo bagnulo" <[email-masked]>
Date: Fri, 15 Nov 2002 18:29:50 +0100

Hello Christian,

> "host multi-homing and network multi-homing".

I think there is at least another type of solution, which we can call hybrid
solutions, that involve both the routing system and the hosts. This type of
solutions require the cooperation of both elements.

The rationale for this type of solutions would be something like this:

At least, a multi-homing solution must provide a way to store multiple
alternative routes to a destination and it also must provide a way to use
this information when the route used stops working properly.

Network based solutions store the information about alternative routes in
the routing system. This presents scalability problems, as you mention.
However this type of solution is attractive, IMO, because the elements that
are forwarding packets have the alternative route information, so they could
rapidly react when an outage occurs. I mean, on-route packets can be
re-routed through the alternative route, since the info resides in the
routing system. This, however is currently not always possible, since
re-convergence time of the routing system is too long, but i guess this
could be possible.

OTOH, host based solutions have much better scalability properties, since
alternative route information is stored in hosts, so the routing system is
not overloaded. However, this solutions imply that host must recover from
path outages, imposing new mechanisms to detect path availability, and
furthermore, en-route packets do not survive an outage, since the elements
that forward packets do not know about alternative routes to the given
destination.

So, here is where an hybrid solution could make sense, since it could store
alternative route information in the hosts, providing good scalability
features, and it could use that information in the routing systems, so that
when a router has no destination for a given address, it can use an
alternative route.
The problem here is that the information about multiple alternative routes
is stored in hosts and used in routers. A possible solution for this can be
to include alternative route information in packets. In this case, multiple
alternative route information is stored is hosts, carried in packets and
used by routers when is needed.

> based solution and one to explore a host based solution.

I suggest also to  explore hybrid solutions.

Thanks, marcelo

---

From: "Aldrin Isaac" <[email-masked]>
Date: Fri, 15 Nov 2002 19:23:48 -0500

% From: [email-masked] [mailto:[email-masked]]On
% Behalf Of Craig A. Huegen
%
% There is absolutely an interest in the network/routing
% based solutions.  It's just that the operator folks who
% will be using them significantly as they're deployed
% probably aren't in this forum (or are trying to keep
% up with billions of other things at the moment).
%
% It is undesirable for a large enterprise to use a
% multi-address/host based solution without a mechanism
% to interact with the network topology to perform path
% selection.  Network operators know more about the
% viability of paths (whether by technology or manual
% policy) than the hosts do.  Left-side longest-match
% is hardly a sufficient routing  protocol and/or policy
% control for a multi-provider topology like the Internet.
% The network *MUST* be a part of the solution --
% enterprises want policy control, and policy control
% should be centralized.
%

I strongly agree.

The network is a policy enforcement tools used by the enterprise
network manager to control cost and liabilities related to e-business.
This involves firewalls, ALGs, AND controls implemented using routing.
The enterprise network will continue to play this role whether anyone
likes it or not.  If you don't believe me, have a talk with the
network manager of any firm that takes any and all risk seriously
(even those *we* may qualify as non-risks).

BGP and TE protocols are critical routing control tools for the
implemention of an ISPs business agreements and policies.  The
enterprise needs the same, if not more, control at the routing level.
Especially to mitigate the burden of having to support multi-homed
hosts!  Ignoring this will result in certain "cool" features of IPv6
to become a major thorn in their side and may result in unwanted
"fixes" (ex: NAT).  The assumption that fine-grain route control by
the enterprise is unneccessary is very bad judgement.

I know of multiple cases for which IPv6 is a non-starter simply
because of the reduced role played by the [enterprise] network in the
source address selection process and the lack of source-based
site-exit routing.  These are IMHO critical basic componants to any
network-based or host-based IPv6 multihoming solution for the
enterprise.

The enterprise people are caught between the ISP oriented people on
one end exerting their influence on address delegation and the
application/host oriented people on the other end exerting their
influence on address selection.  One or the other (or both) has to
give a little to make some room for the guy in the middle.

-- aldrin

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 16 Nov 2002 09:39:28 +0859 ()

Craig A. Huegen;

> organizations are most likely to accept either.

I'm afraid you miss the point of IPv6 that NLA ISPs need multihomed
to TLA ISPs.

Large organizations such as TLA or NLA ISPs won't accept anything
requiring cooperation with other competitive ISPs.

							Masataka Ohta

---

From: Pekka Savola <[email-masked]>
Date: Sat, 16 Nov 2002 07:25:00 +0200 (EET)

> requiring cooperation with other competitive ISPs.

Depending on the level of cooperation.

If the ISP's customer sets a requirement for some kind of co-operation
(like accepting a more specific route from the competetitive ISP) or else
chooses another ISP, the ISP would have every reason to co-operate (within 
reasonable limits, as said) with its competitors.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Shane Kerr <[email-masked]>
Date: Sun, 17 Nov 2002 14:46:02 +0100

On 2002-11-16 09:39:28 +0859, Masataka Ohta wrote:
> Craig A. Huegen;
> 
> > > There are really two classes of solutions. I would categorize
> > > them as "host multi-homing and network multi-homing".
> > >
> > > [...]
> > >
> > > I suggest we charter two follow-on efforts, one to explore a
> > > network based solution and one to explore a host based solution.
> > 
> > I support this.  As a general rule, I feel that larger
> > organizations are going to want network-based solutions for
> > multihoming; smaller organizations are most likely to accept
> > either.
> 

I totally concur, and in fact this is a large part of the reason I
prefer host-based multihoming.  :)

-- 
Shane Kerr
RIPE NCC

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sun, 17 Nov 2002 20:02:33 +0100

> towards a network that knows more specific routing information.
In the long run that will be the only thing that scales - so that is 
where we will need to find a "permanent(tm)" solution.

Best regards,

- kurtis -

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 18 Nov 2002 16:09:58 +0100

> > towards a network that knows more specific routing information.

The DSCP is definitely not available for that; please read RFC 2474.

I would be amazed if the flow label became available for that. We do have
clear consensus in IPv6 that it's an immutable e2e field.

> In the long run that will be the only thing that scales 

I don't think that follows at all.

    Brian

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 18 Nov 2002 16:16:19 +0100

> I don't think that follows at all.

Sorry - just to be clear. I was referring to going down the 
network/routing path.

Best regards,

- kurtis -

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 18 Nov 2002 16:42:57 +0100 (CET)

> The DSCP is definitely not available for that; please read RFC 2474.

Can you be more specific?

> clear consensus in IPv6 that it's an immutable e2e field.

What we'd need for something like this is a field in the header (well,
it could be in an option but that increases overhead) that routers could
look at when making routing decisions, but can be changed without
breaking higher layers. Being able to change the field en route would be
useful but may not be absolutely necessary.

Iljitsch

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 18 Nov 2002 17:18:17 +0100

> Sorry - just to be clear. I was referring to going down the

Yes. And I don't see how you can assert that this is the only
scaleable solution.

  Brian

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 19 Nov 2002 01:13:53 +0859 ()

Kurtis;

> Sorry - just to be clear. I was referring to going down the 

Anything relying on network intelligence does not scale.

						Masataka Ohta

---

From: "Michael H. Lambert" <[email-masked]>
Date: Mon, 18 Nov 2002 12:18:00 -0500

--On Monday, 18 November 2002 16:42 +0100 Iljitsch van Beijnum 
<[email-masked]> wrote:

[...]

> useful but may not be absolutely necessary.

This sounds a bit like loose per-hop behavior.  If it is decided that this 
is a mechanism for the WG to consider, can anything be borrowed from RSVP 
(and what about scaling)?

Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 18 Nov 2002 22:40:33 +0100

> Can you be more specific?

Not really. If you don't want to read the diffserv Proposed Standard,
you'll have to believe me: the DSCP isn't available to solve the
multihoming requirement.

> useful but may not be absolutely necessary.

You can always propose an extension header for this. However, I doubt
if it would have any substantial advantage over an encapsulation
mechanism.

     Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 19 Nov 2002 01:40:48 +0100 (CET)

> you'll have to believe me: the DSCP isn't available to solve the

I want to and I did, but propably not thorough enough because I didn't
find what specifically you were referring to. I'll read the whole thing
more closely when I have more time and less distractions.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Nov 2002 02:37:28 +0100

> more closely when I have more time and less distractions.

I am puzzled. Diffserv defines the DSCP bits to select per-hop behaviors, 
i.e. output queue scheduling algorithms and such. That means they aren't 
available for other purposes. 

   Brian