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

[Russ White <riw@cisco.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>> 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.

In other words, although you might want to traffic engineer to a finer
granularity, it doesn't matter, because you will be filtered. Since you
state this isn't acceptable in IPv4, I don't think it will be in IPv6,
in the long run.

>> 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.  

Which implies the current set of proposals are possibly not a complete
solution (?). Perhaps the "right" answer is that no single solution is
going to address three different economic drives, especially with the
people holding the money card are, somewhat, at odds with one another.
Maybe the entire problem needs to be split into smaller pieces.

> 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_).  

Right now. IMHO, these proposals on the table will bring a lot of
"transit AS'" which currently aren't out onto the table.

:-)

Russ

- --
riw@cisco.com CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHV1xoER27sUhU9OQRAgNmAJ44kaSu5MHmpPNRO48XNgR9dud+mACdES8H
X/igog/v1hpeO+S1D5Atp5c=
=g57B
-----END PGP SIGNATURE-----

--
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