(sent from wrong userid) ----- Forwarded message from Scott Brim <[EMAIL PROTECTED]> -----
Date: Mon, 3 Dec 2007 06:35:03 -0800 From: Scott Brim <[EMAIL PROTECTED]> Subject: Re: [RRG] Thoughts on the RRG/Routing Space Problem To: Stephen Sprunk <[EMAIL PROTECTED]> Cc: Russ White <[EMAIL PROTECTED]>, [email protected] 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 PROTECTED]> > >> 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 PROTECTED] 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
