Re: requirements draft revision

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

On Wed, Jun 27, 2001 at 10:36:22AM -0700, Tony Hain wrote:
> You effectively proved my point. It is not possible to reliably affect the
> routing policy of an external organization (else the need to purchase access
> to the opposite side of the congestion point would not be necessary).

My point was that it is trivial to affect the routing policy of an
external organisation by buying transit from them.

> Also
> you appear to be targeting a relatively simple topology of managing the
> immediate providers, but the wording implies that any solution is required
> to work over an arbitrarily complex one.

The wording is:

3.1.3 Performance

   By multihoming, an enterprise should be able to protect itself from
   performance difficulties between transit providers.

   For example, suppose enterprise E obtains transit from transit
   providers T1 and T2, and there is long-term congestion between T1 and
   T2.  The multihoming architecture should allow E to ensure that in
   normal operation none of its traffic is carried over the congested
   interconnection T1-T2.

   A multi-homed enterprise must also be able to distribute inbound
   traffic particular multiple transit providers according to the
   particular network within their enterprise which is sourcing or
   sinking the traffic.

If I made the first paragraph "between its transit providers" rather
than "between transit providers" would thae make it clearer?

> [snip]
> 
>             /--ISP 1--><--ISP 2--><--ISP 3--\
> Remote Site<                                 >Popular site
>             \--ISP 4--> Congestion<--ISP 5--/

The requirement here is that "popular site" should be able to multi-home
between ISP4 and ISP5 in order to avoid congestion between ISP4 and
ISP5.

> The policy of 'remote site' is to always prefer its low-cost path to ISP 4.
> The wording requires that the multi-homing solution allow 'Popular site' to
> override the routing to ensure a bypass of the congestion. That can't happen
> because it violates the policy of the other end. Acquiring service from ISP
> 4 or coercing 4 to connect to 2 or 3 are about the only options here.

See above.

> There are current topologies where existing tools have an effect, but they
> have a limited scope. Tat needs to be recognized and they need to be added
> as examples, or the requirement is unobtainable and needs to be removed.

I still don't see what is unobtainable about the requirement, given that
it describes motivations for multi-homing that are achievable today
with v4/CIDR-abuse.


Joe