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

[Russ White <riw@cisco.com>]

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


I started off a thread I can't keep up with. :-) I'm going to try and
summarize a bunch of things here, in one email.

>> Clark: "There are clearly two classes of network entities, subscribers
>> and providers; there may be a gray area but that is not important."
> 
> I think this is a slight misstatement.  There _are_ clearly two classes
> of ASes: transit and leaf.  It's easy to tell which are which, and the
> vast majority of growth is in the latter.

This is precisely what I question. I've provided some examples below, so
as not to make the main text here too long, but, IMHO, the main area of
growth in the 'net today is in AS' which have the characteristics of
both a transit and a leaf.

>> If they do, then with what granularity do they care?  Traditionally,
>> traffic engineering is done to the granularity of the reachable
>> destination.
> 
> Nit: it's traditionally done to the granularity that one can get peers
> to accept prefixes for groups of destinations.

Right--the smallest block of reachable destinations, today, is the
longest prefix your peer will accept.

> 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? There appear to be several drivers
in place to push more discrete routing into the fore--again, see below
the sig for instances.

The net result is granularity ends up at the host level, or perhaps
below, at the flow level. I'm not certain mapping helps this--because
mapping assumes that once you hit the leaf/transit divide, the
granularity levels automatically decrease. I'm concerned this no longer
true--the 80/20 rule is in it's last gasps, I think, and we have to
figure out how to work in a world with 20/80, maybe, or 100/100, in some
sense.

It's easy to say: "We'll map at the edge, and then aggregate the space
we're mapping in to." Then along comes a situation where we need more
granular traffic engineering than the mapping we're using, so we break
the mapping space up into smaller chunks, and give each piece a more
granular piece. This is of little cost to the provider who does it--it
only increases the mapping table size by one--and gives them much more
control over traffic flow to destinations for which traffic transits
their network. There must be exceptions, and exceptions turn out to be
the rule.

Anyone see any similarity to the way the IPv4 address space is handled
today? Everyone still gains by pushing more granular information into
the table, at little cost to themselves. We could say: "Ah, but we'll
just limit the length to something quite a bit longer than what is
allowed today!" Given the drivers for more granularity, what you most
likely end up with here is either:

1. People need the service, so they will find a way. If IP won't do it,
then IP==POTS. Let's retire now, and be done with it.

2. An exponentially growing table of short prefixes, facilitated by the
huge IPv6 address space (as Tony has pointed out, routing /32's in IPv6
is the same thing as routing hosts in IPv4, so you've gained nothing in
table size if you go in that direction).

:-)

Russ

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

==
1. The Transit/Content Provider

I, like most folks on this list, get my 'net access through a cable
provider. They pick up the traffic from the edge of my network (I have
four routers in my house, all live, none just for lab or test--and I
assume, at some point, that every house is going to have an entire
network of devices, not a single device), transport it through their
network, and send it to their upstream. They do the same for entire
business networks, with their "business class" services. Hence, they
should be treated as a transit AS.

OTOH, they provide services, such as pay for play, where they provide
the content locally, and allow their subscribers to use those services.
Those services consist of information carried across a transit network,
the 'net, from some content creator to their network. They have
"terminal" servers in place to handle receiving and processing this
content. They also create content locally, and sell it to other content
providers throughout the world. Hence, they should be treated as a leaf AS.

2. The Content/Transit Provider

Suppose you have some entertainment company that creates a lot of
content. They have a lot of servers, and sell content to a lot of
different providers, and direct to consumers, as their primary forms of
business. Since they terminate a lot of traffic, they should be treated
as a leaf AS.

They also have a lot of subcontractors working for them, and have, in
fact, contracted out an entire facility (outsourced) from some other
creative house. These people must not only have access to the
entertainment company's network, they must also have access to their
"home" network, for tools, material, and management. The entertainment
company simply creates a path for them to reach their home company
through their 'net connection (it's cheaper to converge the traffic
rather than paying for separate access), and transit it. They should
then be treated like a transit AS.

In fact, this situation plays out in more ways.... A large theme park
operator also provides content locally, and then transits traffic for
contractors who run entire venues, such as stores and eateries, within
the confines of the theme park, for instance. They are also both a
transit AS and a leaf node AS.

3. The Government/Transit Provider

Any given US state government offers a number of, well, "services" to
the people who live there. For instance, the ability to pay their taxes
online comes to mind (I'm hesitant to use the word "service" and "pay
taxes" in the same sentence. :-) ). They also might provide information
about state colleges, tourist information, and others. Hence, they
should be treated as a leaf AS.

At the same time, every US state government also has a lot of
departments that want access to the 'net, and also to have transport
between the various offices of that department. Think your local DMV.
Okay, sorry for injecting such a horrible thing into your head. It's
like the tune that you can't stop playing in your head over and over
once you year it, isn't is? :-)

The state gov't provides all of these various departments transport and
access to the 'net across their network. Hence, they are a transit AS.

I'm certain there are a thousand more "grey area" networks--in fact, I'm
certain "grey area" networks are growing in percentages, and "pure"
networks are going away. Every coffee house is a "grey area" network,
although they handle it today by having two separate networks, or using
some other form of semi-physical separation. Every hotel is in the same
position. At some point, people are going to tire of using two
connections to do this stuff--we're telling them to converge, and they
want to. :-)

==
Drivers for more granularity

For instance:

1. Traffic engineering is quickly becoming a service by service affair,
rather than a network affair, particularly on the server side of things.
How many folks eat an entire subnet (/24) today, for a single service,
so they can engineer traffic to that service specifically?

2. Quality of service threatens to add more granularity--you can no
longer treat a host as a single traffic endpoint, from the network's
point of view. Instead, a single host actually needs multiple virtual
(or logical, if you will) connections, each with different
characteristics. You can provide those connections through different
queuing mechanisms in the network, or through layer 3 virtualization, or
through some other means, but you still have to deal with multiple
distinct streams with the same source/destination pair in some
way--which means it becomes harder and harder, over time, to treat a
subnet as a single "unit," I think.

3. Mobility adds more granularity, as well. While mobility on a per host
basis isn't a "killer app," it's quickly becoming something that's just
expected. People see they have partial mobility with their cell phones,
and they want more (or rather content providers want them to have more).
If IP doesn't step up the plate on this, then IP == POTS, and we can all
just retire into our easy chairs, and talk about the "good old days," IMHO.

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

iD8DBQFHUWCAER27sUhU9OQRApUnAJ9/PoqZxqLF77/dQBivn7oZW+0IxQCfUJsA
asLIptTxJXGG1exuOayMJWY=
=7QNg
-----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