Re: [rrg] IPv4 & IPv6 routing scaling problems

[[e-mail]]

 
In einer eMail vom 12.02.2010 16:27:41 Westeuropäische Normalzeit schreibt  
[e-mail]:

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.