[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Thoughts on the RRG/Routing Space Problem
Thus spake "Russ White" <email@example.com>
[ I said: ]
I disagree; transit and leaf are fundamentally mutually exclusive.
Either your AS provides transit to the DFZ for another AS or it doesn't.
So, your definition is that as long as you transit anything, you are a
transit AS. If you do not, you are a leaf. It doesn't matter if you
originate traffic, or you sink traffic, the only thing that matters is
that you transit traffic.
In this case, I posit this is a distinction without a difference. All
AS' should be assumed to be transit in all cases.
That assumption is clearly incorrect. As of last week, 87% of all ASes
visible in the DFZ are origin-only. There are tens of thousands of medium
and large leaf ASes _not_ visible in the DFZ because they don't need ASNs,
either because they have a upstream (transit) AS(es) announce for them or
they're stuck on PA space. There are hundreds of millions of small leaf
ASes, like my house, that can't get BGP from their upstreams, period, but
might want EIDs so they can multihome over their DSL/cable/wireless lines.
Doesn't this increase the size of the Locator table, over time,
to be precisely the size of the EID table?
No. The mapping table may get disturbingly large, but the locator
table (i.e. DFZ) shouldn't grow in proportion.
As long as you assume that the transit AS never has any reason to
engineer traffic towards the various actual destinations reachable
through a given locator, or that the peering AS never wants to split
their locator space into multiple pieces to accomplish TE.
Things are looking slightly rosier in v6 because the vast majority of
transit ASes will have a /32, and current expectations are that all ISPs
will filter at that boundary. Even if some do not, perhaps because they are
okay with deaggregates, everyone should also announce the covering aggregate
as well because _someone_ will be filtering. That allows ISPs to tune their
filters based on how comfortable they are with the resulting table size.
Of course, such filtering has been tried with v4, but due to the large
differences in allocation size and certain "important" sites not announcing
covering aggregates, it's been discarded. As the table passes 250k, it may
be making a comeback, but it'll be ugly.
IMHO, the end result will be that the locator space will be split to the
same degree the current routing table is, over time, and hence, the
locator table will be the same size, in the end, as the current routing
So, the value proposition is the same as with the current routing
table--you incur little cost, and you do gain something, by making the
locator table larger. If the value proposition is the same, the result
will be the same, IMHO.
Indeed, that's probably what will happen; there doesn't seem to be any
applicability of our present proposals to solving that, though. At most,
we'll be removing the leaf routes from the table, but there are analyses
that show they could be fully half of the current routes (mostly legacy
/24s). Worst case, that just makes room for more locator deaggregation...
IMHO, there are drivers which will push the locator table size larger,
at least to the same size as the current table. IMHO, we are also going
to wind up, as the meshiness increases, with a much larger set of the
attached networks acting as transits.
While the total number of visible ASes is going up, the number of
origin-only ASes is growing faster than the number of transit ASes (i.e. the
percentage of the former is _growing_). This is due to the increasing
number of leaf ASes (e.g. large corporations) that are starting to visibly
multihome, which is happening significantly faster than new transit ASes
(e.g. ISPs) are being created.
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
to unsubscribe send a message to firstname.lastname@example.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg