[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Russ,

On 2007-11-30 10:22, Russ White wrote:

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

I was reading through all the various threads here over the last couple
of weeks, and also going through some of the proposals, and through some
of the slide decks that have been sent out, and I have a couple of
questions, actually.... These might seem fundamental, and maybe they're
answered someplace, but I thought they were worth asking, anyway. Maybe
someone can just say: "These are dumb questions!," I don't know. :-)

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.


<snip>


Does anyone else have any sort of sense on this? What's the impact if we
push an artificial split into this area, and find we're wrong--that the
gray area is, in a sense, the *only* interesting area with good revenues
for everyone?


I've been worried about the notion of a "split" as too absolute for some
time, but I think the key point is not actually the notional split.
It's the addition of a (relatively static) locator-to-locator mapping
to the (relatively dynamic) use of locators for route computation.
As I've complained from time to time, LISP EIDs aren't really EIDs;
they are just locators that don't happen to be used for global route
computation.

I think that leaves scope for the gray area (e.g. map a locator to
itself to indicate that it keeps its own entry in the tables).



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.

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? If they do, then with what granularity do they care?
Traditionally, traffic engineering is done to the granularity of the
reachable destination. What new mechanism will be deployed to allow
granularity of this same fineness, and yet not cause the table size to
increase?


My guess is that it will be done to the granularity of a *mapped*
destination (RLOC), and that will be coarser grained than today. But again,
the gray area can remain to allow fine granularity in a few exceptional
cases.

    Brian

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