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

[Scott Brim <swb@employees.org>]

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


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.  

> Along your lines of a split, I like the idea of using 4000::/3 for 
> LISP-mapped EIDs and deprecating PI space in 2000::/3.  It's a bit tougher 
> to apply the same split to v4 since there won't be any /8s left by the time 
> a solution is standardized...

The more LISP gets deployed, the more inconsequential the PI/PA
differentiation problem becomes, so I'm hoping this kind of stringent
rule will "quickly" be relaxed (I'm not going to define "quickly").


Excerpts from Tony Li on Fri, Nov 30, 2007 11:21:27AM -0800:
>>>> With LISP, I envision a world where PI space and EID blocks are
>>>> the same thing, and neither shows up in the DFZ -- other than a
>>>> single EID aggregate that leads to anycast ITRs (to handle legacy
>>>> senders).
>
> That's certainly an interesting vision.  The EID allocation problem
> seems like it could be quite daunting politically and only
> applicable to v6.

I'm not sure what this means.  

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