On Fri, Nov 14, 2008 at 9:34 AM, Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote: > 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.
Hi Iljitsch, That's an interesting point. Dissociating the GUID and SID from the LOC would inherently suppress edge routing updates, even for basic multihoming. However, updates due to link changes in the core still have to propagate through the entire core, even if the change is so distant from the instant router and the topology downstream from the instant router is such that the change can't impact the downstream FIBs. I haven't heard a potentially successful solution strategy that addresses this point. I think geoaggregation was the only one that attempted it and we proved that geoaggregation has uncorrectable theft-of-service anomalies even in small configurations. The current solution strategies all imply the remaining impact from this factor is small enough to be a non-problem. I think that's probably right, but we should find a way to acknowledge the issue and state the assumption explicitly. >> 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. I mean with the current deployed protocols. I'm trying to explain why the routing table size problem is an emergent property of the current protocol design. > 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. Strategies A and B both depend on aggregated LOC reachability information being flooded. It appears to be needed to compute a network path. I guess this ties in with your point about suppressing distant routes. If you want to suppress distant routes then you can't flood LOC reachability info. Is that correct? Here's how I propose to include this knowledge in the document: Strategy A. Variants include: A1a. Each core ISP has one RLOC. The RLOC's existence and reachability is flood-propagated to the rest of the core. A1b. Each core ISP has a small number of RLOCs for traffic engineering (TE). The RLOCs' existance and reachability is flood-propagated to the rest of the core. A1c. Each core ISP has one aggregated set of RLOCs which it may hierarchically assign to customers downstream and/or disaggregate for TE. The aggregated RLOC's existance and reachability is flood-propagated to the rest of the core. Strategy B. Assign heirarchically aggregatable LOCs to every host. Assign multiple LOCs to each host such that in the network topography hosts appear as stubs in multiple locations instead of forming distant connections in the graph. Assign one aggregated set of LOCs to each core ISP where a core ISP is one which has numerous major transit or peering links. Flood-propagate the aggregated LOC's existance and reachability to the rest of the core. Having reduced the network topology to something relatively close to a hierarchy, perform plain old hierarchical aggregation on the LOCs. Add and remove LOCs to each host dynamically during operation as needed to reflect changes in the nearby network hierarchies. Strategy C. Suppress distant routes by aggregating them into sets expected to be available in a given direction. Because LOC reachability info is not flooded, the routing tables each router must deal with are relatively small. Appears intractable. Variants include: C1. Geographic aggregation. All nodes within some geographic boundary are assigned the same LOC. Routers move packets to any adjacent router deemed to be "closer" to the LOC in question. Geoag has been shown to have uncorrectable theft-of-service anomalies in networks as small as 8 autonomous systems and two geographic areas. Addendum: Item 1. Additional causative factors worth mentioning: Because even a distant route may present a better priority in one coreward direction than another, it's not possible to suppress distant routes. As a result, every default-free router in the core must carry all routes. Acceptable? Regards, Bill Herrin -- William D. Herrin ................ [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
