Re: requirements draft revision

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

On Wed, Jun 27, 2001 at 07:55:38PM -0700, Tony Hain wrote:
> Joe Abley wrote:
> > A "transit provider", T,  of enterprise E is an enterprise
> > which provides connectivity to the Internet for E which
> > extends beyond the part of the Internet operated by T. T
> > and E are directly connected.
> 
> That solves the problem by restricting the definition to match that specific
> example,

Actually, no -- that's what I always intended the definition to be.
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.
They might be a transit provider of your transit provider, however,
or a peer of your transit provider. Global transit works through
cascades of relationships.

> but I thought one of the points of multi6 was to address the
> general problem for all *transit* providers caused by multihomed sites. With
> this approach there is no definition for the transit providers not connected
> to E, so when we move on to the next example of things that need to work the
> definition will no longer fit.

Transit providers not connected to E are not transit providers of E.

> > We are not presupposing a routing solution. We are simply
> > stating a requirement.
> 
> Oh but you are presupposing a routing solution in that you are expecting one
> of the transit providers connected to E to provide routing for the site
> prefix from the other one.

That is the mechanism by which this requirement is met in the current
multihoming practice with v4.

> While this is an IPv4 requirement, it is optional
> for IPv6 when the goal is simply keeping the routes straight between the
> attached providers.

There may be other mechanisms that meet that requirement in a new
v6 architecture.


Joe