Re: requirements draft revision

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

On Wed, Jun 27, 2001 at 06:08:45PM -0700, Tony Hain wrote:
> Joe Abley wrote:
> > The only transit providers in that diagram are T3 and T6.
> 
> According to the definition in the document, all the Tx organizations are
> transit providers. The fact they don't happen to be attached to E makes no
> difference to their status as transit providers.

How about this:

  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.

> > T5 is not a transit provider of E.
> 
> While E is not a direct customer of T5, that does not mean T5 is not
> providing transit services for traffic to E, particularly for clients of
> itself or T4. Revenue and customer/supplier relationship have no connection
> with the service of connectivity and transiting bits beyond the provider's
> network.

See above.

> > I have already described how E can expect to have exit policy
> > for E's prefixes handled by T3 and T6.
> 
> Yes, and I have described that all the exit policies mean nothing unless the
> next party honors them. Since E is not a customer why should they?

See above.

> > 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.
> 
> Ah, the core of the problem ... applying an IPv4 mindset and constraints to
> an IPv6 problem space.

No -- illustrating how the requirement is not met by a particular
multihoming strategy.

> There is absolutely no reason for E to expect T3 or
> T6 to accept and route a prefix from the other. They may be willing to do
> so, but it is not a strict requirement for IPv6 multihoming to solve the
> simple scenario you described. If a host within E is communicating with a
> host in T3, longest-match source address selection rules will cause it to
> use E's T3 prefix. If E chooses not to provide both prefixes to it's hosts,
> that is not T3's problem.
> 
> Now if you are talking about a scenario where T3 & T6 are providing backup
> for each other's prefix of E for the transit providers beyond, then we are
> at the point of a substantive requirement and discussion.

We are not presupposing a routing solution. We are simply stating
a requirement.

> > 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.
> 
> I have no problem with this. All I am looking for is a precise description
> of current practice so we don't end up with an expectation that an IPv6
> solution is required to do far more. Basically the current document reduces
> to 'if E connects to more than one provider the multihoming architecture
> will *ensure* that E is able to direct traffic the way it wants at a global
> scale'.

Well, I don't think it does but it is clear you do :) Does the changed
definition above make things better?


Joe