Subject: [[email-masked]: Re: [RRG] Thoughts on the RRG/Routing Space Problem]

From: Scott Brim <[email-masked]>
Date: Mon, 3 Dec 2007 09:09:57 -0800

(sent from wrong userid)

----- Forwarded message from Scott Brim <[email-masked]> -----

Date: Mon, 3 Dec 2007 06:35:03 -0800
From: Scott Brim <[email-masked]>
Subject: Re: [RRG] Thoughts on the RRG/Routing Space Problem
To: Stephen Sprunk <[email-masked]>
Cc: Russ White <[email-masked]>, [email-masked]
X-Mailer: VM 8.0.5-504 under Emacs 22.1.1 (i386-apple-darwin8.10.1)

Excerpts from Stephen Sprunk at 02:55:29 -0600 on Sun  2 Dec 2007:
> Thus spake "Russ White" <[email-masked]>
> >> The EID-to-RLOC mapping can be far more granular since it
> >> doesn't impact routing tables; you can give individual EIDs
> >> different mappings if desired. This is far superior for destination-
> >> based TE than what we have today, where you have to apply
> >> BGP-based TE to an entire /24 or even /20.
> >
> > Doesn't this increase the size of the Locator table, over time, to be
> > precisely the size of the EID table?
> 
> No.  The mapping table may get disturbingly large, but the locator table 
> (i.e. DFZ) shouldn't grow in proportion.
> 
> For instance, if I (as a leaf AS) have five ISPs, there will be exactly five 
> routes to my five locators -- the aggregates from those ISPs.  However, I 
> could have potentially thousands of EIDs, each mapped individually to a 
> random selection of those locators in a way that couldn't be aggregated.

Right.  Forwarding in DFZ routers is untouched by the level of
granularity in prefix allocation, without any requirement for address
allocation based on physical hierarchy.  Among mapping functions,
those that are pure push will be more affected by granularity than
those that pull.  ALT will see the difference near the edge but not at
its center, since it aggressively aggregates mapping reachability
information.  Any differences in granularity are quickly absorbed.

> > It's easy to say: "We'll map at the edge, and then aggregate the
> > space we're mapping in to." Then along comes a situation where we
> > need more granular traffic engineering than the mapping we're
> > using, so we break the mapping space up into smaller chunks, and
> > give each piece a more granular piece. This is of little cost to
> > the provider who does it--it only increases the mapping table size
> > by one--and gives them much more control over traffic flow to
> > destinations for which traffic transits their network. There must
> > be exceptions, and exceptions turn out to be the rule.

While core routing/forwarding is untouched by granularity, there will
be more prefix mappings in ITRs.  There are several things that
mitigate that.  First, if there is any "pull" at all in the mapping
system, an ITR only has mappings it uses, so small sites that only
connect to a few places can have small ITRs.  Second, an ITR need not
cache everything if there is a mapping node nearby that will do the
caching for it.  Third ... well, I just woke up with melatonin in my
brain, so it isn't quite working 100% yet, but there are mitigation
techniques in all the various schemes.

See some of you soon.

Scott

----- End forwarded message -----

--
to unsubscribe send a message to [email-masked] 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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Dec 2007 08:26:52 +1300

On 2007-12-04 06:09, Scott Brim wrote:
> (another from wrong userid)
> 
> Date: Mon, 3 Dec 2007 06:41:49 -0800
> To: Brian E Carpenter <[email-masked]>
> Excerpts from Brian E Carpenter at 15:03:37 +1300 on Mon  3 Dec 2007:
>> On 2007-12-02 02:24, Russ White wrote:
>> <snip>
>>
>>> 2. An exponentially growing table of short prefixes, facilitated by the
>>> huge IPv6 address space (as Tony has pointed out, routing /32's in IPv6
>>> is the same thing as routing hosts in IPv4, so you've gained nothing in
>>> table size if you go in that direction).
>> Er, yes, there's a reason that the IPv6 design assumes
>> provider-based aggregation of prefixes, and multiple prefixes if you
>> have multiple providers. The PI heresy is an import from IPv4
>> thinking. But if that heresy sweeps the world, we're going to need
>> LISP style mapping to exorcise it from the core. I think that's how
>> we got here.
> 
> So it's let's-have-fun-with-rhetoric day, eh?  We got here because of
> the rate*state problems, of which PI allocations are a small part.
> Once we got here, we discovered that we potentially had the freedom to
> abandon the dogma that you are clinging to.  (At this point I believe
> you're supposed to say "I find your lack of faith disturbing").

Oh, I do, certainly ;-)

However, my point was not intended as rhetoric. The reason we designed
IPv6 for multiple prefixes per site was precisely to avoid the problem
that IPv4 faced pre-CIDR. The emergence of PI allocations and BGP4-based
multihoming for a large number of IPv6 sites would recreate that problem.
It hasn't happened yet because we don't *have* a large number of IPv6
sites yet. But if we can't get people used to the idea of multiple
prefixes per site, we *will* have the problem, and I thought that
was the main reason we're here - to keep the number of prefixes that
the core has to route down to a manageable number, even if sites
stick to the old notion of one prefix per site.

    Brian

---

From: Scott Brim <[email-masked]>
Date: Mon, 3 Dec 2007 17:06:58 -0800

> stick to the old notion of one prefix per site.

Yes but we don't need to push provider-allocation to do so if we have
a map&encap mechanism in place.  I don't know what the future
allocation mechanism will be -- it could be provider-based, and for
many sites that will work best  -- but it need not be.  My concern was
that you seemed to be saying that we had to stay with PA.  

swb

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Dec 2007 10:31:59 +1300

Scott,

> that you seemed to be saying that we had to stay with PA.  

I think that if we *don't* solve the problem we're discussing
here, the facts of physics will force us to impose the PA model.
I've thought that ever since RFC 3177, in fact.

     Brian

---

From: Scott Brim <[email-masked]>
Date: Wed, 5 Dec 2007 13:37:51 -0800

> I've thought that ever since RFC 3177, in fact.

Sure.