[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
1. There seems to be a concensus that splitting the "transit" address
space from the "end user" address space is "the solution." I'm a little
worried about this assumption, for various reasons. I'm hoping
someone can tell me I'm crazy, and that my disquiet is just based on
a figment of my imagination.
I don't think it's so much a separation of address spaces, but a separation
of AS types. I don't see how we'd get incremental deployability with truly
split address spaces.
Looking back to this quote from one of the slide decks:
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.
I believe some people are using "provider" as shorthand for "transit AS" and
"subcriber" for "leaf AS".
I'm under the impression that the "gray area" that's "not important"
is actually growing in size, rather than reducing in size--that the
split between transit and host/service isn't along provider/customer
lines, but rather within all of these networks, and that this is
becoming more common, rather than less.
We've heard, in RIR meetings, over and over again that operators in the DFZ
are scared of widespread multihoming and PI because each leaf AS requires a
slot in the DFZ, and there aren't (and won't be) enough slots available to
handle the demand. This has resulted in high artificial bars to entry,
denying a huge fraction of the Internet reliable service.
If we are able to constrain BGP tables to only transit ASes, the DFZ becomes
a lot smaller and we can afford to let everyone, even home users, multihome
with PI space. (Of course, there's a hidden assumption there that the
number of transit ASes will remain under control, but I haven't seen anyone
dispute that.)
Under this model, hosts in a leaf AS would have EID != RLOC while hosts in a
transit AS might have EID == RLOC. Written that way, it becomes irrelevant
whether the host is a client or a server (or both), or who owns what, or
whether it's a "service" provided by a "transport" company.
2. There seems to be some idea that traffic engineering is primarily
done along the "provider/customer" edge, which I don't think to be
true. In fact, I think there are two sorts of "traffic engineer" in view,
the first of which is within a given AS, and the other of which
attempts to influence the point at which traffic enters an AS. These
two sorts of traffic engineering are, generally, opposed to one
another, or rather, in many situations probably attempt to influence
traffic to take different paths.
The first case is not our problem, since it's entirely within a single AS
and not visible to the world; that can be handled by a variety of existing
tools, e.g. MPLS, or proprietary vendor solutions.
The latter is an explicit goal. Today, one really can't control which
sources use which entrance, just a rough knob for the ratios of how much
enters in each or which destinations can use which entrances. LISP doesn't
seem to make the situation any worse, and depending on how complex the
mapping gets, might make it better. For instance, it might be possible (at
some point) to make the mapping dependent on the source address, though I
haven't seen anyone propose that yet. We're still trying to figure out how
to get destination-only mapping working :)
I think we've oversimplified the concept of "traffic engineering" in
our thinking, and therefore we've not considered the full impact of it.
Is it really true that providers don't care where traffic enter their
networks?
They definitely do, as do many leaf ASes. Heck, even in the context of a
residential user I care whether the traffic to my PC uses my DSL line, the
open WiFi AP across the street, or my cell phone.
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.
What new mechanism will be deployed to allow granularity of this
same fineness, and yet not cause the table size to increase?
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.
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