[rrg] Summary of architectural solution space

Iljitsch van Beijnum iljitsch at muada.com
Fri Nov 14 06:34:20 PST 2008


On 11 nov 2008, at 21:39, William Herrin wrote:

> I'd appreciate your constructive criticism:

> http://bill.herrin.us/network/rrgarchitectures.html

Constructiveness is in the eye of the beholder.  :-)

> The root cause of the routing table growth problem is that we're  
> using the same element (IP address) to express both the  
> communications identity (ID) needed by the layer 4 and higher  
> protocols to keep track of communication sessions with other hosts,  
> and the node's present locations (LOC) within the network topography.


Well, that was the rough consensus at the routing&addressing workshop  
two years ago. I was the only one who didn't agree. With a loc/id  
split multihoming and renumbering aversity (assuming we can contain it  
to the IDs and still renumber locs) would no longer have to increase  
routing tables. But the current routing table is 8 x the number of  
ASes and BGP not only fails to contain updates to a limited part of  
the network, it actually amplifies them as they circle the globe.  
Those issues are separate from an id/loc overload.

Also, we have no proof that the problems caused by a loc/id split are  
less than those fixed by it.

> changing a server's identity requires changes in many other hosts'  
> references which are unwieldy or impractical to make.

Disagree: if you can run both the old and new side by side for some  
time, there's nothing to it.

What I'm missing in your summary is the difference between the ID->loc  
mapping and the loc->reachability mapping. If we want to support  
multihoming, which we do or we still have a use case that can  
overinflate the routing table, we need to be able to determine which  
locators are reachable and which aren't. This gives us the following  
options:

- ID->loc and loc->reach are both flooded: this is what BGP does,  
doesn't scale
- ID->loc is flooded, loc->reach on demand: IMO, this is what we need
- ID->loc and loc->reach on demand: caching and initial packet issues
- ID->loc on demand, loc->reach flooded: doesn't make sense




More information about the rrg mailing list