RE: requirements draft revision

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

Ben Black wrote:
> A transit network is one which carries traffic which is
> neither originated from nor destined to addresses within
> itself.  A transit provider is one which maintains peering
> agreements with other providers to give access from its
> customers to the customers of those providers.

There is absolutely no distinction between those statements! You are mixing
the concept of customer with the technical detail of address space. A pair
of providers with customers in PI space would fit both of those statements.
A pair of providers connecting only dial customers using their space would
fit the last one. How does the term transit apply in that case?

What you appear to be trying to distinguish between is the network selling
dial-access from one selling policy-enabled leased-line services. In the old
days when the latter used PI address space, the address based definition
made sense, but now that customers are simply punching holes in the
provider's block, the address-based distinction is gone.

> Note that some providers will use other providers for
> transit for a variety of reasons.

Absolutely. The question is if the entire chain of providers is using a
chain of sub-delegated address space from one end, are they transit
providers by this definition?  A-B-C-D-E   The fact that E maintains peering
arrangements so its customers can reach customers of B would make it a
transit provider by your second statement, but E's address space came from
D, which came from C, which came from B, so according to your first bullet
these are transit networks in one direction but not the other.


>From this and Joe's statements, I believe the intended distinction between
'transit network' and 'transit provider' is actually based on the actions of
the connecting enterprise. If that enterprise is further selling access
services to other enterprises (therefore it is assumed to be expressing
distinct routing policies), then the transit entity is termed a 'network';
when the enterprise simply terminates connections for internal purposes and
wants to express global routing policy through the transit entity, then the
transit entity is termed a 'provider'. This leaves an obvious missing case,
so I assume if the enterprise simply terminates connections for internal
purposes and doesn't express policy, then the transit entity is simply
called an 'access provider'. Note there is no distinction here about
customer relationship, or address space being used. If this is the case, the
definition in the document needs to be tightened up to define the actions of
the connecting enterprise.

Tony