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 _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
