[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