RE: Provider Independent addressing usage

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

Pekka Savola wrote:

> Based on the quotes at the end of the I-D, it would appear that
> at least some of my concerns are shared by others, but
> nonetheless, let's hope this brings up something new.

Good, the reason I sent it out was to generate additional comments so the
document can cover as many concerns as possible.

> Problems with the PI approach:
>
>  1) people don't seem to want too specific routes in the DFZ.
> With current policies, I'd estimate 100-200 routes is the
> maximum. (though the technical constraints are a couple of
> orders of magnitude larger). Specifying these with prefix length
> may give the wrong impression, as the space would be rather
> densely populated (minus the oceans, sahara etc.)

I agree that removing specifics from the DFZ is the goal, but punching holes
in provider aggregates is the current reality and that mechanism is directly
contrary to the goal. I don't understand your point about prefix length.
What I was trying to say in the draft was that each of the regions outside
of the current scope would be represented by single prefix. The population
density of these remote regions has no impact on routing in the local
region.

>  2) because of non-specific advertisements, operators would be
> forced to carry a lot of traffic not their own, or throw it
> out.  Neither is acceptable, economically or from user's
> point-of-view.

Simply FUD. There may not be a customer relationship between an intermediate
operator and the destination, but the traffic was originated via a customer
relationship with the source, and there is some operator with a relationship
to the destination. Inter-provider agreements are what they are, and they
have little relationship to end customers. When a site is connected to
multiple operators each of them become identifiable entities to the
intermediate operator, so there is a potential for customer relationships
between providers. If end-sites are directly connecting to exchanges, the
exchange becomes the logical customer of the intermediate operators and
passes through the costs to the connecting customer.

> 3) the only ones that could really gain from advertisements
> are regional/area/etc. IX's that have a very high level of
> regional ISP penetration; e.g. if address belongs to the
> region, it'd be reachable through the members of an IX with
> over 99.9% probability.

The PI addresses that actually have an attached site will always be
reachable through some set of the ISP's in the region. It appears that you
are concerned that some of the ISP's in the region are not participants in
an exchange. This is not required as long as one of the providers that are
participating is willing to tie it all together. The only mechanism to
enforce this is for the inter-region providers to refuse more specifics, or
charge exorbitant fees.

> 4) ISP's operating at the IX would have to advertise, among
> themselves, full /48 routes.  In some regions, where there
> are dozens of millions of Internet users, this is probably
> not an acceptable solution either.  So the problem goes back
> to 2), but in smaller scale where there are often _no_ IX's
> to exchange the traffic.

Lack of an exchange in the current topology is not relevant to what might be
necessary to scale millions of multi-homed sites in a specific scope. Look
back a few years and you would find only a few exchanges globally.
Additional exchanges were built as the engineering trade-offs showed value
in establishing an exchange at a particular place. The design of this PI
mechanism allows exchanges to be created at the scopes that make sense for
local engineering reasons, without impact about on any other scopes.

> ==>
>
> So, it's often the case, e.g. in Europe, that a country has
> about one IX. The PI solution would work if the prefix(es)
> of the region belonging to that country were advertised to
> by that IX, and _everyone's_ (in that country) /48 PI prefix
> be advertised within that IX (whether it's directly associated,
> or a smaller client ISP of the peering bigger ISP).

Forget country boundaries, and see the previous note about when and where
exchanges get built. Certainly the scopes relevant to an existing IX should
have their prefixes exchanged by the participants in the IX, or a route
server at the IX coordinated the actual prefix/provider relationships.

> Additionally there would have to be some peering with
> neighbouring IX's, so the locations near the borders of a
> country could be sent to the right country.

Depending on the provider/scope/IX relationships there may need to be some
fine-tuning of scope sizes exchanged at specific IX's. As noted in the
document anytime there are overlapping scopes, some coordination is
required, but that does not necessarily mean peering.

> If this was not done, some regional ISP's would have to capture
> and carry some traffic they have no idea if they can deliver or > dumped.
Or, the traffic could be sent to some smaller-than-
> regional IX's which by definition didn't exist.

I don't understand. If there is a site at the defined prefix there will be
an explicit entry known to the providers for that scope. If there is no site
there may be connection attempts, but that is no different from unassigned
provider-based prefix addresses.

> Take the netcraft web server count by domain for example
> [http://www.netcraft.com/Survey/Reports/0106/bydomain/];
> I think it's fair to assume that each /48 site would have at
> least one if not more web servers.  United Kingdom appears to
> have about 2.8 million, so say 3 million /48's.  Even if there
> were 10 IX's in the UK (distributed nicely by geographical
> areas, no less), this would still be a whole lot of specific
> /48 routes between participating ISP's.

Yes; if all sites were multi-homed and the providers chose to implement it
that way. When they become concerned about scale, history shows they will
implement more IX's to break up the space.

> These appear to be rather unscalable restrictions.

They will appear to be unscalable if one insists on maintaining current
interconnect topology while at the same time watching the edge topology move
to massive multi-homing. I will not claim that the PI mechanism is
necessarily the best choice, but it is much better at global scaling than
punching holes in provider aggregates.

> ==>
>
> So some portions of this resemble the optimal 6to4 relay router
> finding issue (using anycast, for example); only, this is a
> about 2^28 times bigger problem....

The real problem is that the definition of 'optimal' depends on perspective.
The ISP perspective will be very different from the end customer
perspective. The goal of PI is to balance those perspectives with a slight
weighting toward the end customer site.

Tony