[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Thoughts on the RRG/Routing Space Problem
Thus spake "Russ White" <riw@cisco.com>
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.
I disagree; transit and leaf are fundamentally mutually exclusive. Either
your AS provides transit to the DFZ for another AS or it doesn't.
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.
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.
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:
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.
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.
Most ISPs will be transit ASes, though I can think of a few examples of ones
that probably wouldn't be.
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.
If they're providing transit connectivity to other ASes, they're a transit
AS. What their business model is above the IP layer is irrelevant.
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.
Terminating a lot of traffic has nothing to do with it.
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.
They're not providing transit to the outsourcer because they do not show up
in the AS Path for the outsourcer as viewed from the DFZ. For that matter,
neither their address space nor that of the outsourcer should be in the DFZ
at all; they'd have different EID blocks that were mapped to their
respective ISP(s)' RLOCs. They might have a private connection so that each
others' EIDs were routed internally, or they might talk via their ITRs and
ETRs across the public network.
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.
They cannot be both. There are arguments both ways on which they should be,
depending on how things are set up, but it'll be one or the other.
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.
That depends. If the state gov't is the sole transit for all those
departments, one could make the case that they -- and all the departments --
should be a single leaf AS. If, as is often the case, the departments also
get independent connections from private parties, then the state network
would be a transit AS and the departments would be leaf ASes.
Ditto for your amusement park example.
That the amusement park or state govt has its own servers and clients
terminating traffic does not change things; hosts can live in a transit AS.
The defining characteristic is whether the AS's address space appears in the
DFZ individually: if so, it's a transit AS; if not, and it needs to use an
EID-to-RLOC mapping, where the RLOCs are from some other AS's address space,
then it's a leaf AS.
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