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

[Russ White <riw@cisco.com>]

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


> Different aspects matter in different contexts.  For IP routing, I
> believe the main question is whether you are DFZ or not.  

I *believe* the number of default only AS' is going to reduce in size
over time, for various reasons.... Hence, my basic thinking that all AS'
should be treated as transit, or rather, any solution should be designed
with a zero size "default only" zone, if you will.

>> 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.
> 
> First, what locator table?  

The "global routing table."

> In case you mean routing of globally routed addresses in the DFZ, in a
> map&encaps scheme the routing information will only grow based on the
> number of DFZ ASs and their policies on routing within the DFZ,
> because RLOCs are assigned by upstream providers, and will aggregate.

What is the business reason for aggregating locators into your peers,
rather than advertising more specifics? I believe this will be a strong
business case to deaggegrate, but I don't see any real reason to
aggregate. De-aggregation doesn't cost anything, and you can gain
through it, so the economics are the same as those in operation in the
global routing table.

> Addresses of ETRs are just addresses in their upstream providers.  In
> DFZ routing, policies can only be applied to the upstream providers,
> not to things outside the global DFZ.  Policies on non-routed sites
> will be applied in the mapping function (data plane and control
> plane).

Policy can only be applied to the longest prefix representation of the
locator space--in other words, you can only apply policy to the groups
of locators you actually advertise. As you aggregate the locator space,
you can apply policy, including traffic engineering policy, to larger
groups of exit points (seen from your network point of view). There's a
strong incentive to advertise finer grained locator information, to
control the flow of traffic through the transit AS. There is no
corresponding driver to aggregate this information.

> Then there's the cache of prefix maps in an ITR.  There would be a
> problem for an ITR that wanted to send traffic to every prefix,
> because it would have to cache many prefix mappings.  There are a
> number of deployment heuristics we can both think of to avoid that
> problem.

Caches, IMHO, will not work. Caching information is based on specific
traffic patterns that are going to probably change, dramatically, in the
near future--it's never good to presume existing traffic patterns are
permanent, and we can thus build an architecture based on those existing
traffic patterns. Second, any form of reactive routing, which is what
caches, in the end, represent, is going to have unacceptable side
effects in terms of traffic delays, technical difficulties, etc.

>> 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.
> 
> I don't understand this.  I thought the question is how much routing
> information there will be in the global routing DFZ.  Behavior there
> will be like BGP today.  

There are two tables, and the question is--how much state*churn will we
have in both of those tables? IMHO, the state*churn in the DFZ routing
table, the "locator" table, will be similar to what's there today, if
not possibly worse. The state in the "mapping" table will be unbounded,
probably many times larger than the current table size.

> In map&encap, traffic from ITR to ETR will
> follow paths that BGP hunts out, just like today.  Yes, destination
> sites will want to steer traffic to specific exit points (ETRs), and
> they will do so in the mapping function.  Every ingress point (ITR)
> might be asked to send traffic to a different exit point.  DFZ routing
> won't care.  It will just carry routes to the ISPs that provide those
> exit points.  

This assumes that the end destination traffic can always be treated as a
single class, or a single monolithic block of traffic--or rather, all
destinations within a given "leaf" AS can always be treated as a single
destination. IMHO, this is not a good assumption, as shown by current
trends.

In the same way, this also assumes that all the locators within a given
transit AS can always be treated as a single destination from outside
that AS. Again, IMHO, this is not a good assumption.

>   - Routing and addressing are more fundamental than mobility.
>     Mobility can adapt to R&A but not vice versa.

In other words, mobility is a secondary requirement for IP transport.
Either it is a small part of the traffic, and will not grow, so there is
no need to address it (?).... Or, it's not a problem that needs to be
addressed through routing, it should be handled elsewhere. IE, IP == POTS.

That "stuff" folks are running over our transport are fine, just solve
your own problems, and don't ask me to do it for you. IMHO, this is
shortsighted.

>   - In the real world mobile users are rather provider-aggregated, and
>     even if we use the currently conceived route optimization
>     mechanisms, the need for new map lookups will be less than one
>     would think.

Today. Again, I believe it's wrong to base an architecture on today's
traffic patterns. Part of the job of the IETF isn't to solve today's
problems, it's to solve tomorrow's problems in a way that doesn't impact
today's services.

:-)

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

iD8DBQFHVeEIER27sUhU9OQRAg+wAKC2aqcu00gPzQ8pOpgC7VIoCGMmmACfYCAU
bxAHfb48GOXuKfIyQqwW4yw=
=VGA5
-----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