[sbrim@cisco.com: Re: [RRG] Thoughts on the RRG/Routing Space Problem]

[Scott Brim <swb@employees.org>]

(sent from wrong userid)

----- Forwarded message from Scott Brim <sbrim@cisco.com> -----

Date: Mon, 3 Dec 2007 06:35:03 -0800
From: Scott Brim <sbrim@cisco.com>
Subject: Re: [RRG] Thoughts on the RRG/Routing Space Problem
To: Stephen Sprunk <stephen@sprunk.org>
Cc: Russ White <riw@cisco.com>, rrg@psg.com
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" <riw@cisco.com>
> >> 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 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