Subject: Re: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 22 Oct 2004 14:28:26 +0200

On 22-sep-04, at 15:23, Cedric de Launois wrote:

> CONCLUSIONS:

> These observations show that, from a performance point of view, IPv6
> multihomed stubs get benefits from the use of multiple PA prefixes and
> should use them instead of a single PI prefix as in IPv4 today.
> This study thus strongly encourages the IETF to pursue the development
> of IPv6 multihoming solutions relying on the use of multiple PA
> prefixes.
> The use of such prefixes reduces the size of the BGP routing tables, 
> but
> also provides lower delays, more diverse Internet paths, which in turn
> yields to better possiblities to balance the traffic load and to 
> support
> quality of service.

"When considering dual-homed IPv6stubs, we see in fig. 13 or in fig. 14 
that the path diversity observed is already as good as the path 
diversity of a 25-homed IPv4 stub."

:-)

But the question is: will this help us or hurt us? Basically, BGP 
doesn't really know what the best path is, but it can usually detect 
and avoid the bad ones. So you pretty much always get something 
reasonable. With multi-address multihoming you get many more paths, 
some of which are better than what BGP would have given you, but a lot 
are worse. So the trick is to select the best one, or at least avoid 
the bad ones. How do we do this?

Iljitsch

---

From: Cedric de Launois <[email-masked]>
Date: Fri, 22 Oct 2004 16:31:12 +0200

> the bad ones. How do we do this?

Good question ! I'm currently working exactly at this point.
And I have a pretty fair solution (I believe)... I can't say
more just now, but expect some news from me about that in two
or three weeks ;)

Cedric

---

From: "Michael H. Lambert" <[email-masked]>
Date: Fri, 22 Oct 2004 11:01:14 -0400

> the bad ones. How do we do this?

[Not directed at Iljitsch; just quoting his text]

Given that the "best path" probably just has meaning for a given 
application between given hosts at a given point in time, how often do 
we *really* need the *best* path?
Best effort usually works well enough for forwarding--why shouldn't it 
do the same for path selection? (I think Noel implied this in his 
response--to use his highway analogy: in driving from Boston to San 
Francisco saving six hours is good, saving ten minutes is (usually) 
irrelevant?)

Since the One True Best Path is likely unknowable anyway, why 
complicate path selection by building SVCs (or MPLS tunnels) into it?

Michael

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 22 Oct 2004 17:13:30 +0200

El 22/10/2004, a las 14:28, Iljitsch van Beijnum escribió:

> "When considering dual-homed IPv6stubs, we see in fig. 13 or in fig. 
> 14 that the path diversity observed is already as good as the path 

Just a nit, note that in multihoming we are only selection addresses, 
not full paths.
This means that we are selecting the ingress and egress ISP of the 
source and destination sites, but that the interdomain path will be 
selected with other means i.e. BGP.

So we don't really need to know information about all the possible 
complete paths, just the ingress and egress parts of the path. I guess 
that this problem is more reduced and less ambitious than the general 
one.

Regards, marcelo

> Iljitsch
------------------------------------------
Please note that my former email address
[email-masked] is no longer in use
Please send mail to:
marcelo at it dot uc3m dot es
------------------------------------------

---

From: Cedric de Launois <[email-masked]>
Date: Fri, 22 Oct 2004 17:36:39 +0200

> we *really* need the *best* path?

The goal is not much to have the *best* path, but to avoid really bad
paths.

> complicate path selection by building SVCs (or MPLS tunnels) into it?

In the multi-address multi6 case, path selection is simply done by
selecting the right source and destination prefixes. If a host can
figure out which are the couples (src,dst) prefixes to avoid, then the
benefit can be huge. This doesn't require tunnels in any ways.

Cedric

---

From: Jari Arkko <[email-masked]>
Date: Fri, 22 Oct 2004 19:07:09 +0300

marcelo bagnulo braun wrote:

> that this problem is more reduced and less ambitious than the general one.

Right.

The other reduction is that I'm not sure we need to solve
the "best path" problem but solving even the "a working
path" problem might be sufficient. That's at least my
preference.

--Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 23 Oct 2004 15:06:39 +0200

> benefit can be huge. This doesn't require tunnels in any ways.

Well, there remains the exit router selection issue - I think one
of the proposed solutions to that did in fact require a (short)
tunnel.

    Brian

---

From: Olivier Bonaventure <[email-masked]>
Date: 23 Oct 2004 15:35:30 +0200

> selected with other means i.e. BGP.

Agreed, but given that most AS-level paths on the Internet today are
between 3 to 5 AS hops, selecting the ingress ISP and the egress ISP
means that in practice you select most of the end-to-end path at the AS
level. This will remain true unless the diameter of the Internet
increases due to IPv6 multihoming...

Olivier

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 24 Oct 2004 04:00:18 +0200

El 23/10/2004, a las 15:35, Olivier Bonaventure escribió:

> between 3 to 5 AS hops,

even if this is true....

>  selecting the ingress ISP and the egress ISP
> level.

this is not trivially true, since the e2e path is determined by all the 
routers in the path, not only the ASes

I mean, there is still a long way between selecting the ingress and 
egress IPS (through the address selection) and selecting the complete 
path at the source i.e. the source node specifying all the routers

but anyway, i think we are diverging...

regards, marcelo

> This will remain true unless the diameter of the Internet