In einer eMail vom 12.02.2010 16:27:41 Westeuropäische Normalzeit schreibt [email protected]:
Well, in their defense, I can understand people wanting more features from the routing. Unfortuntely, IMO that basic architecture is not well-suited to adding lots of advanced features (all the easy, low-hanging, ones have probably already been picked), but changing to a different one is going to be a horrendous undertaking. ..which is not true. In a previous email I pointed out how little BGP-enhancement it takes to advertise TARA-links. With respect to the new issue "growing number of paths": TARA would even provide millions of additional routes without any costs: i.e. detouring routes via nodes that are even more remote from the destination,i.e. via nodes towards which the current router would forward the (received) BGP-UPDATE message. The extended multitude of paths is not a menace, instead it is something that can be provisioned for free. Can anyone explain why knowing a huge number of paths should be superior than knowing the network topology? Don't say that the network topology would be too big. I have shown many times that a set of different zooms will do. A corner stone of TARA is the computation of consistent topologies for the various zooms (just by knowing the standardized scale ratio). _http://www.ietf.org/proceedings/74/slides/grow-6.pdf_ (http://www.ietf.org/proceedings/74/slides/grow-6.pdf) refers to Route Reflectors (and what they cause). I do observe: IETF- routing experts only know to deal with either full mesh overlay networks or with star-overlay networks (e.g.RR). But not how to provide properly skimmed representative overlay networks of any scale ratio in-between:-( Heiner ------------------------------from a previous email on 25th January 2010----------------------------- TARA-goals: 1)Scalability: Table size: 64800 entries (1 per geopatch) + 3600 meta-table entries + n times 60 entries (in the worst case) with n TARA-routers inside the own geopatch Update churn: tending to zero. The scalability issue will be eliminated once and forever 2) Multicast to millions of receivers (imagine TVoIP of the opening olympique celebration to hundred millions of receivers - admitted, TARA would be the basis, a better than today's MC is needed (and could be developed), too 3)Traffic engineering: Enables all kind of detouring Multipath (not just ECMP) while recongizing,any dead-end path. Enables congestion handling for all kind of streams, in particular voice and live-TV streams whose transmission rates cannot be slowed down, based on a communication between the congested and the respective upstream neighbor network.(i.e. provides a rearview mirror) Enables time-of-day routing. Abolishes loops.Would overcome the TTL-mechanism which appears to be a relict from the stone age. 4) Mobility: Enables Mobility solutions without a home agent or rendez-vous server. Well scoped ANYWHERE-cast using well-scoped broadcast mechanism (better than flooding) Hence will certainly enable services which are still unknown today 5) Moore's Law: 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 be replaced by some other (e.g. detouring) next hop. 6) Will enable stretch-1 and disable the Istanbul-effect 7) Clean slate: Will overcome the orthogonality between intra- and inter-domain routing. Will overcome the either-or thinking between network-based versus user-based 8)Multihoming: Enables Multihoming (just like all the other proposed solutions) 9) Enables Multi-addressing (IPv4, IPv6 just like LISP, eventually more: HIT, names, E164 without enum ?! ) because the transit router uses the TARA-locator, doesn't look at the other address; 10) Eliminates the IPv4 depletion issue, because of 7): IPv4 must be locally unique only. PI or PA? All are PI effectively. 11) Provides a strategy for incremental deployment 12) Provides a new realm for working on IP technology in the future.
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
