Subject: Re: [rrg] IPv4 & IPv6 routing scaling problems

From: [email-masked]
Date: Fri, 12 Feb 2010 14:54:00 EST

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

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.

---

From: Danny McPherson <[email-masked]>
Date: Fri, 12 Feb 2010 16:35:54 -0700

On Feb 12, 2010, at 12:54 PM, [email-masked] wrote:

> 
> 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 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:-(

That's because they're constrained by the rules of the routing 
protocol employed, in this case rules inherent to BGP (path vectors)
for loop avoidance.  If you've some magical way to work around 
this in production networks we're all ears ;-)

-danny