[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Thoughts on the RRG/Routing Space Problem
Thus spake "Scott Brim" <email@example.com>
Excerpts from Stephen Sprunk on Fri, Nov 30, 2007 09:48:54AM
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.
Sure, but to clarify, "AS" is used in a generic sense, including some
sites which would not have an AS Number today.
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 :)
Map-Replies can be source-dependent in at least some of the
mapping proposals. In ALT (and EMACS), the Map-Reply comes
from the ETR, so the owner of the ETR gets to apply policy.
That makes sense. I didn't catch that possibility when reading those
drafts; thanks for the correction.
In NERD and CONS, you can still apply policy, but since
mappings are disseminated and cached the policy itself has to
be disseminated to be effective, and some sites might be
reluctant to do so.
Not to mention that the policy can't be very dynamic in those cases, due to
the assumed slow propagation (and/or caching) and desire for low churn.
Ivip's goal of fast propagation is interesting, but the thought of millions
of sites updating their EID mappings every few seconds based on server loads
(and you know someone would try it...) scares me.
Excerpts from Stephen Sprunk on Fri, Nov 30, 2007 01:00:57PM
I suppose that's a "split"; I thought Russ was worried that there
would be two (potentially overlapping) address spaces, one for
providers and one for customers, as opposed to a single
address space which was divided into RLOCs and EIDs. For
instance, there's been mention of using IPv6 for EIDs and IPv4
for RLOCs, which has some interesting properties.
I am concerned about totally decoupling the addressing domains, and
allowing reuse of addresses, for two reasons. First, operations: I
think it would be confusing to operators to always have to provide
context when talking about "240.1.2.3". Second, it might be useful to
allow end nodes to send packets directly to globally routed addresses
in the DFZ domain. On both of these, we don't know yet if it's going
to be a problem, so let's put off reusing addresses for a while.
I don't understand how a solution could be incrementally deployable unless
both the EID space and the RLOC space were distinct parts of our existing
address space. They can't overlap as long as there's a single legacy site
left, which means forever in practice.
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 firstname.lastname@example.org 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