Re: [RRG] Thoughts on the RRG/Routing Space Problem

["Stephen Sprunk" <stephen@sprunk.org>]

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