[ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use))

[Scott Leibrand]

Paul Vixie wrote:

> i'm not getting through here.  scott, there is no "we" in the "routing table
> full" scenario.  last time around "we" dodged the bullet because the network
> was small, and CIDR was an easy way to accomodate future growth, and moore's
> law was an easy way to cope with current growth.  if pool depletion leads to
> mass deaggregation and steps in the global table size, it'll be every network
> for itself -- the ultimate assymetric cost:benefit equation -- a meltdown.
>   

Perhaps we are understanding each other, but simply disagree about the 
dynamics of such a system.

Perhaps it would be illustrative to look at mass deaggregation from the 
perspectives of some of the major types of players in the routing system:

 - From the perspective of a multihomed end-site network buying transit 
from two or more DFZ providers, "the Internet" is this big messy place 
"out there" that they'd like to be able to talk to.  For inbound 
traffic, such a network will want to announce their route to all of 
their transit providers.  If they have PI space, they'll expect those 
announcements to be propagated globally.  If they are using PA space, 
they'll need their announcements to be accepted by both of their transit 
providers, both directly and indirectly, so that if their session to 
provider A goes down (or is de-preferred for TE), provider A will hear 
the announcement from provider B and route the traffic over the 
alternate path.  For outbound traffic, routing can be pretty simple.  If 
they have gear that supports it, they can get a full routing table from 
all of their transit providers, and do all sorts of cool things with 
that to manage outbound traffic.  If their gear isn't quite that beefy, 
or deaggregation gets bad, they can take default routes from their 
transit providers, and possibly accept a number of BGP routes as well, 
but filter most of the rest of the mess and leave it up to their transit 
providers to know all the details.  For this class of network, it's 
pretty easy to filter as much of the routing table as needed.

 - From the perspective of a multihomed ISP buying transit from one or 
more DFZ providers and selling full-BGP-feed transit to customers, many 
of their concerns will be the same as the multihomed end-site.  In 
addition, however, the ISP has an incentive to carry a full, unfiltered 
BGP table, so that they don't lose any traffic from multihomed 
downstreams to a competitor announcing longer prefixes.  For this class 
of network, the degree of filtering (of routes received from their 
transit providers) becomes a cost / revenue tradeoff.

 - For large, usually international, networks that do not buy transit 
(commonly referred to as "tier 1's"), the decision to filter is more 
costly still, and there is less ability to filter.  Since they don't buy 
transit, such networks can only filter from peers, and since they don't 
have any default routes, they can only (safely) filter out subnets 
covered by a larger aggregate.  If they do filter, and other tier 1's do 
not, then those other networks will likely end up carrying traffic to 
the filtered netblocks from networks that don't filter themselves.

So, if we see mass deaggregation, I would expect filtering to progress 
something like this:

 - Multihomed end-sites would be the first to filter, either to the 
extreme (accepting only a default route) or more selectively.
 - As more multihomed end-sites begin filtering, the amount of traffic 
lost (by a filtering ISP to a non-filtering ISP with longer prefixes) 
would decrease.  As deaggregation gets more severe, it would reduce the 
cost of filtering and increase the cost of not filtering, so more 
multihomed ISPs with transit would begin filtering, most likely on 
prefix-length, and may employ a default route to catch traffic to any 
long prefixes without a properly announced covering aggregate.
 - If this continues, then at some point tier 1 networks' incentives 
would also shift, just as the smaller ISPs' did, and they would begin to 
consider filtering longer prefixes heard from their peers.  They would 
need to be careful that all filtered prefixes have a covering aggregate, 
as no default route would be available to route traffic to filtered 
prefixes.  To preserve failover and TE, they would also need to ensure 
that, when they accept a route from a multihomed customer, they also 
accept that route (or a covering aggregate) from their peers.

So, in conclusion, I see a set of incentives that, in case of massive 
deaggregation, would prompt most networks on the Internet to filter 
deaggregates (prefixes longer than the minimum assignment length) from 
their transit providers and peers, and accept them, directly and 
indirectly, from their paying customers.  This would, in turn, ensure 
that DFZ operators would be able to charge their own customers for 
accepting most of the deaggregates in their own table.


-Scott