Subject: RE: The state of IPv6 multihoming development

From: "J. Noel Chiappa" <[email-masked]>
Date: Tue, 22 Oct 2002 17:14:51 -0400

> From: Iljitsch van Beijnum <[email-masked]>

    >> The benefit of multi-homing has a price - the only question is, who's
    >> going to pay the price? Simple fairness demands that it *ought* to be
    >> the entity which directly benefits.

    > So who benefits if Google is multihomed? The user or the server? Or
    > both?

If we only had to support multi-homing for Google, CNN and the N other top
sites (for a reasonably small N, say 1K or so) we'd be done.

The problem comes when you want to multi-home many, many small sites, all of
whom (by definition) will be conversing with only a limited subset of the
network. Forcing the rest of the network to help pay for the benefit they
receive from multi-homing is patently unfair.

I do agree completely with the basic idea behind one observation in Tony's
draft: "the overriding assumption that the Internet will have to be built
using one or the other rather than leveraging the strengths of each in
context." There's probably no single mechanism which is "the" answer to
multi-homing; you probably need several, each with its own optimal
applicability domain.

    > In a multiple address solution this is much, much worse: in that case,
    > all IPv6 hosts may have to implement extra functionality to be able to
    > talk to multihomed destinations.

How much extra code is it, really? It can't be as much code as IPv6 Mobility,
or Authrntication, each of which is already mandated.

In any event, if you think it's too much extra complexity, use IPv6 Mobility
instead. That way you'll also get connection failover if you have to switch
addresses dynamically because one of your incoming links went down.

    > But we're not debating straight PI, but geographically aggregatable PI
    > (GAPI).

All forms of PI have the same basic problem, laid out in the previous
messages, which is that they are ""topological-location-independent
topological-location-names". So which particular flavor of PI it is really
isn't of any interest.

    > Only when the routing tables grow beyond that, networks in the affected
    > region need to install more memory in existing routers or more routers.

You have a static view of a dynamic reality. There are a lot more factors
than just memory size.

    > the real question is whether multihoming in IPv6 will be good enough to
    > get people who multihome "for free" to move to v6.

Hmm. If the current multi-homing "solution" (where the load of supporting
multi-homing is borne entirely by the routing) "works" (and I don't think it
does, but let me play advocatus diaboli here for a second), why not adopt it
"as is" for IPv6?

Contrariwise, if it doesn't work, why are you trying to adopt a variant of it,
a variant which is so little different in its underlying technical
implications that it amounts to the classic "re-arranging the deck-chairs on
the Titanic"?

	Noel

---

From: "Craig A. Huegen" <[email-masked]>
Date: Tue, 22 Oct 2002 16:40:44 -0500 (Central Daylight Time)

> multi-homing; you probably need several, each with its own optimal

So why not support PI for a limited subset of multihomers that have vast
networks while supporting multi-PA for the small networks that have a
minimal number of segments?

> or Authrntication, each of which is already mandated.

The issue isn't code, IMO -- it's adoption.  How long will it take to get
global implementation of a new multihoming capability into IPv6?  I think
it's time to take advantage of the surge in popularity of IPv6 and get it
into enterprise networks, before the steam is lost.

> addresses dynamically because one of your incoming links went down.

End-user operators want SIMPLICITY, just like the provider operators like
simplicity.  Mobile IP / IPv6 mobility is certainly not simplicity.

> does, but let me play advocatus diaboli here for a second), why not adopt it

You're looking at it in black-and-white (works vs. not works) when the
real issue is gray -- a matter of scale, both near-term and long-term.

It's pretty obvious to me that we need a simple way to multi-home such
that enterprises can treat an IPv6 Internet as business-critical, that
gives the routing infrastructure the ability to select alternate paths
based on policy (whether manual, infrastructure characteristics, etc.)

It's pretty obvious to me that multi-PA does not work for an end-user that
has more than several hundred segments throughout its infrastructure, due
to the configuration and maintenance load, the inability to failover or
automatically deprecate addressing when delivery of traffic to a
particular multi-PA prefix dies, and the inability of the enterprise
network operator to implement network-based policy for path preference.

It's pretty obvious to me that, for the time being, PI addressing could be
leveraged to support those organizations for which multi-PA is a
significant trouble, and therefore encourage those organizations to adopt
IPv6 instead of ignore it.  These organizations can migrate to the
Ultimate Multihoming Solution (UMS) as soon as feasible.

It's pretty obvious to me that aggregation is a Good Thing, and therefore,
anything that would be helpful for PI aggregation in the future may be a
good idea.

I'm offering that existing PI be adopted "as is" for the time being for
adoption purposes, coupled with a promise/demand that it be retired as
soon as the better mousetrap comes along.

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