RE: requirements draft revision

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

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.

> 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.

> 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?

> 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. 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.

> 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'. This is a far broader statement than the simple scenario you have
for the example, but there is nothing requiring the statement to be
restricted to that scenario.

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

If a host within E communicates with a host in T3 it will use the path
between E and T3, likewise for communication with a host within T6 it will
use the path between E and T6.

Tony