These were the TARA = Topology Aggregating RoutingArchitecture - Objectives. The first two objectives are updated. Heiner
1)Scalability: RIB: No single route is to becollected (although millions of additional (detouring) routes–which DV would never yield – will be enabled. Instead of the RIB: approx. 500 TARA-links per zooming level might becollected (which is just a guess). 6 (formerly 5) zooming levels should be envisioned. FIB: No single prefix is to be built.Instead of the FIB three tables are required: Table t1 with 64800 entries;table t2 with 3600 entries and table t3 with 3600 entries. Update churn: tending to zero. The moredistant topology changes occur, themore they are but the less become visible. Like in Google-map: Zoom closest andscroll such that the current node is in the middle of the screen.The topologiesthat you (the current node) will see while zooming out is all what you get toknow and get to deal with. This is a tiny fraction of the combined clostestzoom map of the entire globe. 2) Moore's Law: Next hop retrieval by one single table lookup Will increase the speed of the next hop retrievalby factor 20 i.e. enable Moore's law applicability - even in cases where thebest next hop is to be replaced by some other (e.g. detouring) next hop: youcan simply, temporarily, replace the indexed table entry with the alternatenext hop info. No caching needed (of course). 3) Mobility: Enables Mobility solutionswithout any home agent or rendez-vous server: DNS gives you the current thougheventually not precise destination-TARA-locator. By new ANYWHERE-CAST i.e.well-scoped broadcast mechanism (better than flooding) the properdestination-TARA-router could be searched. (also: DNS be updated when a user roams toa different geopatch) 4)Traffic engineering: Traffic balancing: Enables all kind of detouring Multipath(not just ECMP, yes, even crankbacks included). Enables time-of-day routing. Congestion handling: For all kind ofstreams, in particular voice and live-TV streams whose transmissionrates cannot be slowed down, based on a communication between thecongested and the respective upstream neighbor network.(i.e. with TARA arearview mirror is provided which DV would never ever be able to). Congestionhandling is a network-local-area issue and not something to involve the sendingTCP entity! Abolishes loops: Disables endless (!) loops (butallows/enables crankback). Makes theTTL-mechanism obsolet wrt its current task but would utilize it for doing safe detours. Will enable stretch-1 routing and avoidthe Istanbul-effect. 5)Multihoming: Enables Multihoming a) just like all the other proposed solutions b) long-term: Because of its fantastic achievements wrt scalability wecould even envision a network where even the users (hosts) became nodes of theTARA-topology, which would have a certain impact on the multihoming issue. 6) Clean slate: Will overcome the orthogonalitybetween intra- and inter-domain routing. Will overcome the either-or thinkingbetween network-based CES versus user-based CEE 7) Enables Multi-addressing (IPv4, IPv6just like LISP, eventually more: HIT, names, E164 without enum ?! ) because the transit router uses theTARA-locator, i.e. doesn't look at the other address; 8) Eliminates the IPv4 depletion issue,because of 7): IPv4 must be locally unique only. PI or PA? All are PI effectively. 9) Provides a strategy for incrementaldeployment 10) Multicast to millions of receivers(imagine TVoIP of the opening olympique celebration to hundredmillions of receivers - admitted, TARA would be the basis, a better thantoday's MC is needed (and could be developed), too. 11) Provides a new realm for workingon IP technology in the future. -----Ursprüngliche Mitteilung----- Von: George, Wes E IV [NTK] <[email protected]> An: [email protected] <[email protected]>; [email protected] <[email protected]> Verschickt: Mi., 6. Okt. 2010, 14:11 Thema: RE: [rrg] Fwd: RRG Recommendation From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Wednesday, October 06, 2010 3:31 AM To: [email protected] Subject: Re: [rrg] Fwd: RRG Recommendation The current debate on this thread shows how many people are frustrated by the way their opinions had been ignored - including myself: Once I accomplished that Lixia became interested in my TARA-objectives. I wrote up a list of 11 objectives and thereafter I have never heard any response again:-( Among these objectives: ---------------------------- 2) Moore's Law: Next hop retrieval by 1 resp. 3 (indexed) table lookups. Will increase the speed of the next hop retrieval by factor 20 i.e. enable Moore's law applicability - even in cases where the best next hop is to be replaced by some other (e.g. detouring) next hop: you can simply, temporarily, replace the indexed table entry with the alternate next hop info. No caching needed (of course). ----------------------------- [[WEG]] I had not seen your previous message with your objectives, so I will beg pardon for ignorance in asking this question - could your objectives be abstracted from TARA's implementation and suggested as possible text for the design goals draft that is currently in review? It may not be a good fit, but it at least bears review if it can be made more general. In other words, it's not helpful if it leads only to TARA as a solution (not making a comment about TARA, simply pointing out that would conflict with the recommendation), but if any of your objectives have general applicability, it may bolster the design goals well. Obviously, this would be more about making the existing goals clearer and more articulate than it would be adding additional goals, so look at it with that in mind. Thanks Wes George This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
