Russ, We could go on for another 6 years and try to find out whether AS numbers are better suited for aggregation rather than IP numbers (or NOT). For routing purposes the locators MUST have an intrinsic metric (which is what TARA and its TARA-locator provides). TARA is the only approach which everyone can study just by using Google-map, e.g. by trying to find a route from NY, Time Square to Sun Francisco Golden Gate Bridge. There you can see the (blue) route in each zooming level - at the start, in the middle, at the end. Google demonstrates that topology aggregation works. But we have at least a 15 years' expertise that nodal hierarchy does not work- starting with PNNI, ending with ILNP.
Google does it while dealing with a million times larger network. We could do it too - even without worrying about the network size in case that end users should become nodes too - virtually linked to some multi-homing nodes. Heiner I understand you can "map" the id to the locator you'd prefer to bring the traffic in through, but does that truly solve the traffic engineering problem unless you also have one locator per possible exit point (customer/edge pair) for every (transit) network in the world, and does this actually scale better than what we have today? IE, what's the incentive to aggregate locators, vs the incentive for de-aggregating locators, or even assigning tons of locators because, "well, it's free to advertise a locator, and the table is really small, so..." It seems to me the locator table will end up just where the routing table is today--there's no cost to advertise the things, so, hey, why not? You could, I suppose, constrain the locator space so its very small, but that doesn't seem like a very good solution, either. -----Ursprüngliche Mitteilung----- Von: Russ White <[email protected]> An: Tony Li <[email protected]> Cc: [email protected]; Noel Chiappa <[email protected]> Verschickt: So., 25. Apr. 2010, 2:24 Thema: Re: [rrg] Next pass > This is correct. Once we have loc/id and renumbering, then we can do things > like ask folks to stop using PI because we have made PA almost as good. > Again, avoiding the multi-homing usage for PI route injection is the goal. What about traffic engineering? Will a loc/id split "solve" traffic engineering (which is normally done by leaking longer prefixes today), and if so, how? I understand you can "map" the id to the locator you'd prefer to bring the traffic in through, but does that truly solve the traffic engineering problem unless you also have one locator per possible exit point (customer/edge pair) for every (transit) network in the world, and does this actually scale better than what we have today? IE, what's the incentive to aggregate locators, vs the incentive for de-aggregating locators, or even assigning tons of locators because, "well, it's free to advertise a locator, and the table is really small, so..." It seems to me the locator table will end up just where the routing table is today--there's no cost to advertise the things, so, hey, why not? You could, I suppose, constrain the locator space so its very small, but that doesn't seem like a very good solution, either. So, IMHO, this is all neat and everything, but until the economic problem is addressed, there's not much hope of doing anything other than kicking the can down the road a couple of years or so. :-) Russ _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
