Excerpts from Stephen Sprunk on Fri, Nov 30, 2007 09:48:54AM
-0600:
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.
Excerpts from Stephen Sprunk on Fri, Nov 30, 2007 01:00:57PM
-0600:
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.