RE: requirements draft revision

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

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.

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'. 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. 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. By requiring the multihoming
architecture to allow E to 'ensure' an outcome you are moving it well beyond
current practice.


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.

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

Tony