Re: requirements draft revision

[Joe Abley <jabley-ietf@automagic.org>]

On Tue, Jun 26, 2001 at 07:13:34PM +0200, Iljitsch van Beijnum wrote:
> On Tue, 26 Jun 2001, Joe Abley wrote:
> 
> > Anyway, flame on.
> 
> Since you ask...

Hooray! :)

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

That's very true. I think these bits need to be removed from the
requirements documented, and described more accurately in the v4
draft, as itojun suggested.

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

Is this required in addition to 2.2.2 and 2.2.3?

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

How about this:

  A multihoming strategy may require coopreration between an enterprise
  and its transit providers, but must not require cooperation directly
  between the transit providers.


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

I agree.

> >   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).

Very true, and worth mentioning. I will add words.

Thanks!


Joe