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

[Russ White <riw@cisco.com>]

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


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

>>> The EID-to-RLOC mapping can be far more granular since it
>>> doesn't impact routing tables; you can give individual EIDs
>>> different mappings if desired. This is far superior for destination-
>>> based TE than what we have today, where you have to apply
>>> BGP-based TE to an entire /24 or even /20.
>>
>> 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.

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:

1. The cost of adding another locator to provide traffic engineering is
low (to the person injecting it into the table).

2. Splitting locator blocks into smaller pieces to control inbound
traffic flow into your network adds value.

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.

> For instance, if I (as a leaf AS) have five ISPs, there will be exactly
> five routes to my five locators -- the aggregates from those ISPs. 
> However, I could have potentially thousands of EIDs, each mapped
> individually to a random selection of those locators in a way that
> couldn't be aggregated.

There will a route per destination you want to steer traffic to, not 5.
You could assume 5 if you could assume the mapping system converged
instantly, and if you could assume the transit upstream did not want to
steer traffic to specific entry points based on the exit point from
their network. I don't think these two are true, myself--the mapping
system's convergence speed will not be instantaneous, and traffic
engineering, will, in the end, trump the clean mapping implied.

Further, I think mobility throws another wrench into the works that
hasn't been addressed.

> This is the problem the DFZ sees today, yes, and the goal is to get all
> of that junk out of the routing (locator) tables.  It's natural to
> assume all that junk will then inhabit the mapping tables -- and
> probably multiply like rabbits.  That means we've traded one problem for
> another, but we seem to be operating on the assumption that a mapping
> table is easier to scale than a routing table.

We're assuming:

1. A large mapping table is easier to deal with. Well, it is for the
routing system, because the tables are outside the routing system. :-)

2. There are no drivers pushing the locator table size larger, and there
is no conceivable driver for the locator table size growing to the point
of the current routing table, or larger.

3. Splitting "transits" from "leaves" is going to be clean enough--and
the number of transits will always be a small enough ratio of the entire
set of attached networks--to provide a huge gain in table sizes just by
splitting these two categories apart.

Anyway, I'm not certain we're being productive--the conversation is
wandering into specific solutions, which is what I really wanted to
avoid. I'm having a hard time accepting the underlying assumptions--I
was hoping to get some data or some reasoning that proves or validates
the two assumptions above.

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.

:-)

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

iD8DBQFHVJeaER27sUhU9OQRAqgaAKCnXrplPuJp338MFnmiP80FBUcavgCeNj3j
L3b6Gm1ugsdBks0J+k39fuU=
=YhyN
-----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