Re: requirements draft revision

[Iljitsch van Beijnum <iljitsch@muada.com>]

On Tue, 26 Jun 2001, Joe Abley wrote:

> Anyway, flame on.

Since you ask...

>   http://www.automagic.org/~jabley/draft-ietf-multi6-multihoming-requirements-01.txt

"For purposes of redundancy and load sharing, the multihomed customer blocks,
which are almost always a longer prefix from the provider aggregate, are
announced, along with the larger aggregate by the provider."

This reads like customer blocks always fall within a provider aggregate,
which is not the case for PI address space.

I think the users of a multihoming solution will have a few requirements of
their own:

1. Multihoming should work even if the host on the other side of the
connection uses a current (June 2001) IPv6 implementation.

2. If the solution requires cooperation of the transit providers, it should
only require the cooperation between the customer and each of the transit
networks individually and not directly between the transit networks.

If these objectives aren't met it is likely that users will opt for
traditional IPv4-like multihoming.

>   http://www.automagic.org/~jabley/draft-ietf-multi6-v4-multihoming-00.txt

"A multi-homed enterprise may influence routing decisions beyond its
immediate transit providers by advertising a strategic mixture of
carefully-aimed long prefixes and covering shorter-prefix routes."

This is one of the ways to accomplish inbound load balancing. Another widely
used mechanism is path prepending. And some transit networks allow their
customers to set communities for their routes that influence many things in
the transit network which can also have broader effects (like prepending the
path at certain exchange points).

Iljitsch van Beijnum