[ppml] Definition of an (IPv6) End Site

[Thomas Narten]

> We've been 'round and 'round on this before; the definition of "end
> site" is obviously inadequate.

If there is confusion, by definition it's inadequate! :-)

> I'd propose that a single network with private connectivity between
> locations should count as a single "site".  This roughly correlates
> with who qualifies for an ASN.  If the number of locations/subnets
> within that AS justifies it, they would qualify for a larger prefix
> than /48.

I tend to agree. Speaking as a participant in the discussions that led
to the original policy (and the current wording), there was a clear
intention to split the world into two groups:

 - those that provide internet connectivity to customers (i.e., ISPs),
   where the customers are not the same organization/company as the
   provider, and where there are many _different_ customers, and in
   particular not just separate "offices" in a larger businesses.

 - End sites, those that use the internet, get internet service from
   ISPs and whose core business is not providing network services to
   others.

Obviously, there are boundary cases that are tricky. But the overall
context here was that in order to get good aggregation (and reasonably
bounded routing tables), you wanted ISPs to aggregate addresses for
_many_ end users, i.e., customers. Doing otherwise would run the risk
of (essentially) giving PI space to end users in an unscalable way.

Quoting from the official (current) text:

> 6.2.9. End site
>
> An end site is defined as an end user (subscriber) who has a
> business relationship with a service provider that involves: 
>
> 1. that service provider assigning address space to the end user
>
> 2. that service provider providing transit service for the end user
> to other sites
>
> 3. that service provider carrying the end user's traffic.
>
> 4. that service provider advertising an aggregate prefix route that
> contains the end user's assignment

In my mind, the above was intended to apply to separate
businesses/organizations, and not large companies that have separate
IT divisions. What we didn't want is to allow end sites to simply set
up shell orgnizations so that they would look like LIRs on paper.

If we really wanted large end sites to get PI space, a separate policy
should be developed (as is being discussed now).

And, one of the other goals above is that all of the customer address
ranges are covered (in the global routing tables) by a single
aggregate prefix.

For many large end sites, this is not what is really desired. I.e., if
someone has large offices in (say) US, Europe and Japan, it may well
be that each of those sites wants to be connected to the Internet via
local ISPs, rather than via (say) the US location (with everything
routed via the US connect point). But if this sort of local
connectivity is desired, having a single aggregate that gets
advertised (by giving the end site a PI assignment) doesn't happen in
practice, raising the question of whether a PI assignment makes sense
in the way people are claiming they are needed.

Thomas