Re: requirements draft revision

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

On Wed, Jun 27, 2001 at 02:09:24PM -0700, Tony Hain wrote:
> Joe Abley wrote:
> > If you would like to point out the particular phrases that
> > are causing you to draw some of the conclusions above, that
> > might be useful.
> 
> By multihoming, an enterprise should be able to protect itself from
> performance difficulties between transit providers.

... "between _its_ transit providers", I think we agreed.

> The multihoming architecture should allow E to ensure ...
> 
> 
>   T1 ---- T2 ---- T3 --
>   | \_     |    _/     \
>   |   \_   |  _/        E
>   |     \  | /         /
>   T4 ---- T5 ---- T6 --
> 
> E met the requirement 'By multihoming', but there is nothing they can do to
> protect themselves from an arbitrary set of 'performance difficulties
> between transit providers'.

The only transit providers in that diagram are T3 and T6.

> Yes they can negotiate with T3 & T6 about what
> gets announced and where, but that is not sufficient to 'ensure' that some
> other organization like T5 doesn't override their intended policy.

T5 is not a transit provider of E.

> All E can
> do is express a preference. If others choose to abide that preference so be
> it, but there is nothing E can do to 'ensure' that outcome unless they have
> real-time control of everyone else's policy.

I have already described how E can expect to have exit policy for E's
prefixes handled by T3 and T6.

> By requiring the multihoming
> architecture to allow E to 'ensure' an outcome you are moving it well beyond
> current practice.

No.

> Basically take the words you are using and apply them to an arbitrary
> topology that is outside the scope you are intending to address. If the
> words are germane but don't return the expected result, they are not precise
> enough and need to be replaced or removed.

I am still not seeing why you think T[1245] are transit providers of E.

> Again, I believe the actual requirement you are targeting is 'any site
> should be able to acquire services from an arbitrary set of providers'.

No. The requirement is what is written in the draft, and I do not agree
that it reduces to that sentence. If a host within E communicates with
a host in T3 using a source address delegated from T6, and the multi-homing
scheme prohibits E advertising its T6-delegated prefix to T3, then this
requirement is not met, for example, since T3 will route to E via T6.

> The
> reasons may be to avoid congestion, or simply lowering latency to a pocket
> of customers. The precise reason doesn't matter and is really out of scope
> because that is a policy issue.

There is a particular capability here that is common in the network today
that we want to preserve. If people are unable to overcome peering
congestion between operators in this way, they will find another way,
and it will quite probably resemble what what is done today with v4.

> What matters is that the architecture needs
> to enable traffic between any site and the customers of a directly attached
> service provider to be directed over the attachment to that service
> provider.

I think you're going to need to rephrase that paragraph, because I can't
parse it.


Joe