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

[Scott Brim <swb@employees.org>]

Excerpts from Russ White on Thu, Nov 29, 2007 04:22:00PM -0500:
> 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'm open to other ideas.  I just tend to like the map&encap approach
because it feels more architecturally deterministic.  Data plane
changes are constrained, hosts and routing protocols remain the same,
modularity constrains complexity, and we can focus on the mapping
function.  However, I'm still thinking outside of map&encap, and
welcome suggestions (even if I am behind on mail).

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

This and everything you say below is all true, but I don't understand
the import.  The issue here is IP addressing and routing over the
global Internet.  If a higher layer service is provided via servers
attached to a local enterprise or ISP, then the packets aren't being
routed inter-domain, and I'm not going to worry about them (in this
context).  From the point of view of IP routing and addressing, it
doesn't matter what *kind* of network it is -- packets is packets.  


Excerpts from Brian E Carpenter on Fri, Nov 30, 2007 02:07:00PM +1300:
> 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.

Sure, but you still need to clearly distinguish the scope of the
"locator" you are talking about.  I think our discussions have
demonstrated that the old uses of "identifier" and "locator" don't fit
current needs, and we never settled on new terms.  We all know what
the terms mean in the LISP drafts.  Lixia once suggested "globally
routed address" and "globally deliverable address".  I don't care
about terminology but if you say "locator" I'll say "what scope", and
if you say "identifier" I'll say "what context".  So for now I use
RLOC and EID.

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

If a locator already has global scope, there will be no need to do a
mapping lookup or use in doing so.  It will already be represented in
global routing, if present.  

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

NSPs might care very much where traffic enters, and might want to map
specific destination prefixes to specific entry points.  This can be
very fine-grained.  Some mapping mechanisms behave poorly with a  huge
number of mapping entries and may constrain this.  That should be an
evaluation criterion.  

swb

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