Re: requirements draft revision

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

On Thu, Jun 28, 2001 at 09:38:50AM -0700, Tony Hain wrote:
> Joe Abley wrote:
> > Someone two hops away with whom you don't have a direct
> > relationship is not a transit provider, even though they
> > might carry your traffic.
> 
> Somehow I don't think this is a globally recognized definition of the term
> 'transit provider'.

Well, it's the only definition I have ever heard of in the past six years
of working for transit providers. If my definition is not widely used, I'd
be happy to hear an alternative.

> It also unnecessarily focuses the discussion on one tiny
> segment of the problem space. As I recall, the group's charter is to
> minimize the impact to the entire routing system (read that all transit
> providers), not just the ones directly attached to multihomed sites.

By imposing an architecture on just an enterprise and its transit providers,
a solution *is* proposed for the entire routing system, in a similar way
that an architecture for hop-by-hop routing semantics can facilitate
connectivity between hosts that are more than one hop apart.

> > > > We are not presupposing a routing solution. We are simply
> > > > stating a requirement.
> > > ... <snip>
> > That is the mechanism by which this requirement is met in the
> > current multihoming practice with v4.
> 
> And it is obvious you don't see the inconsistency between your statements.

Good.

> > There may be other mechanisms that meet that requirement in
> > a new v6 architecture.
> 
> How can there be? You keep insisting the requirement as 'the need for every
> provider to accept and provide internal routing for the prefix of another
> provider'.

No. I keep insisting the requirement is as stated in the draft.

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.

> That is not the requirement, it is the current mechanism.

Agreed.

> If you
> insist that carrying foreign prefixes is the requirement,

I don't.

> there can't be any
> other mechanism by definition.
> 
> The real requirement is that 'any enterprise is able to acquire services
> from an arbitrary set of providers, and have a mechanism to keep the routing
> straight between those providers such that traffic between the enterprise
> and customers of any one provider will not transit another provider'.

I don't see how we can require that any enterprise be able to acquire
services from any other enterprise. I also don't think we should be
presupposing a routing solution.


Joe