[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" <riw@cisco.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.

Correct.

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.

Granted.

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
table--because:
...
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.

S

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 rrg-request@psg.com 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