I too agree; this is about research on what are best solutions, not what is the most favorite. I got a different question: exactly what are the design goals that TATA aims to reach? Lixia= Design goals of TARA = Topology Aggregating RoutingArchitecture 1)Scalability: RIBsize: Zero. No single route to be collected - but a multitude of (also detouring)routes is enabled compared with today’s DV-based idr . FIB size: 64800 entries (1 per geopatch) +3600 meta-table entries + n times 60 entries (in the worst case) with nTARA-routers inside the own geopatch. 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 1 resp. 3 (indexed)table lookups. Will increase the speed of the next hopretrieval by factor 20 i.e. enable Moore's law applicability - even in caseswhere the best next hop is to be replaced by some other (e.g. detouring) nexthop: you can simply, temporarily, replace the indexed table entry with thealternate next 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: Routing is from "TARA-ITR" to "TARA-ETR". Short-term: these are DFZ-routers. Long-term: routers closer to the end users (i.e. intra- as well inter-domain routers) or even the hosts themselves. Heiner - -----Ursprüngliche Mitteilung----- Von: Lixia Zhang <[email protected]> An: Stephen D. Strowes <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]> Verschickt: Do., 3. Jun. 2010, 8:46 Thema: Re: [rrg] Routing through On Jun 1, 2010, at 10:37 AM, Stephen D. Strowes wrote: > On 30/05/10 15:06, [email protected] wrote: >> In einer eMail vom 30.05.2010 14:21:55 Westeuropäische Sommerzeit >> schreibt [email protected]: >> >> Well, what is the way to get acquainted with TARA? >> >> I would like to get basic understanding of it. >> >> 1) Experiment with Google -map: Look for some route across USA. Zoom in >> and out, not only at the start or at the destination, but also at any >> point in-between. > > I for one have seen suggestions on this list to look at Google Maps as an indication of how TARA works. I get how Google Maps works. I even understand, in an abstract sense, how my brain might layer similar information for best-relevance when driving between cities. What I cannot derive from this is how TARA works. > > I realise this has gone past before, but: If there is one, single, authoritative, detailed TARA spec then it would be really useful to be able to read it, regardless of what proposals other people may "favour". > > Cheers, > -S. I too agree; this is about research on what are best solutions, not what is the most favorite. I got a different question: exactly what are the design goals that TATA aims to reach? Lixia=
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
