RE: requirements draft revision

["Tony Hain" <alh-ietf@tndh.net>]

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). 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. If your intent was simply to say
that 'an enterprise must be able to acquire service from any provider', that
is very different. The open question in both cases is how many entities need
to know the topological details and preference, and how much can one
override the operational biases of the interconnection mesh. The implied
assertion is that it is sufficient for a site to inform the global set of
service providers what it wants and magic will happen. But if the routing
policy of said 'popular on-line auction house' was contradictory to the
outbound routing policy of an arbitrarily distant site where one of the
customers happened to be located, it is not possible for 'popular on-line
auction house' to do anything to directly affect the path of those packets.

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

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.

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.

Tony


-----Original Message-----
From: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]On Behalf
Of Joe Abley
Sent: Wednesday, June 27, 2001 8:36 AM
To: Tony Hain
Cc: multi6@ops.ietf.org
Subject: Re: requirements draft revision

On Tue, Jun 26, 2001 at 09:04:15PM -0700, Tony Hain wrote:
> In multi6-multihoming-requirements requirement - 3.1.3 Performance -  is
> simply bogus. The example given is managing traffic flows to avoid a
> specific remote congestion point. As it is not possible for any
organization
> to reliably affect the routing policies of another organization (even the
> first hop), this is basically an unrealistic expectation.

In the current v4 architecture, it is overwhelmingly usual for an
operator to assign a higher local preference to prefixes received
from a customer than from a peer.

If I am a customer of T1, I can be very confident that the path from
T1 to me will follow the prefixes I advertise rather than a route
through a peer, for advertisements of the same mask length.

This absolutely happens today, and people absolutely multi-home today
in order to accomplish this.

> Taken to the
> limit, the requirement presented means every site has ultimate real-time
> control of routing policy for every service provider as well as all the
> remote sites they have active flows with. Even if each service provider
> wanted to cede control, the mismatch of policy constrains between the
> collections of end sites will assure this requirement can't be met because
> it has to be true for each of them.
>
> Since I assume you have some specific implementation in mind it might help
> if there were an example provided. Without that this requirement simply
> needs to be removed.

This requirement comes from the observed fact that this happens today,
and works very reliably.

Suppose for a second a large, popular on-line auction company obtained
transit through one particular provider, and that provider had a problem
of peering congestion to some other large promising regional ISP that
was taking months to sort out. An immediate solution for the auction
company was to purchase transit from the promising regional ISP, which
eliminates the congestion point that had been causing them such pain.

[note that the congestion condition hypothetically alluded to above
would surely no longer be an issue, if we consider the fabricated
example to be real in some way]


Joe