Subject: Re: [rrg] Routing through

From: [email-masked]
Date: Thu, 3 Jun 2010 16:48:53 EDT

1 line added wrt  RIB replacement

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 Routing  Architecture
1)Scalability:
RIB size: Zero.  No single route to be collected   - but  a multitude of  
(also detouring) routes is enabled  compared with today’s DV-based idr .

Instead, the topologies for m (e.g. =5) zooming levels (their nodes and  
links) have to be identified, disseminated/collected.  

FIB 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 more distant  topology changes occur, 
the more they  are but the less become visible. Like in Google-map: Zoom 
closest and scroll  such that the current node is in the middle of the screen.The 
topologies that  you (the current node) will see while zooming out is all 
what you get to know  and get to deal with. This is a tiny fraction of the 
combined clostest zoom  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 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).
 
3) Mobility:
Enables  Mobility  solutions without any home agent or  rendez-vous server: 
DNS gives you the current though eventually not precise  
destination-TARA-locator. By new ANYWHERE-CAST i.e. well-scoped broadcast  mechanism (better 
than  flooding) the proper destination-TARA-router  could be searched.
(also: DNS be updated when a user roams to a 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 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. with TARA a rearview mirror is provided which  DV would never ever 
be able to). Congestion handling is a network-local-area  issue and not 
something to involve the sending TCP  entity!
 
Abolishes loops:
Disables endless (!) loops (but allows/enables crankback).  Makes the 
TTL-mechanism obsolet wrt  its current task but would utilize it for doing  safe 
detours.
 
Will enable stretch-1 routing and avoid the  Istanbul-effect.
 
5)Multihoming:
Enables Multihoming 
a)        just like all the other proposed solutions 
b)        long-term: Because of its fantastic achievements wrt scalability 
we  could even envision a network where even the users (hosts) became nodes 
of the  TARA-topology, which would have a certain impact on the multihoming  
issue.
 
6) Clean slate:
Will overcome the orthogonality between intra- and  inter-domain routing.
Will overcome the either-or thinking between network-based CES  versus 
user-based CEE
 
7) Enables Multi-addressing (IPv4, IPv6 just like LISP, eventually  more: 
HIT, names, E164 without enum ?! )  because the transit router uses the  
TARA-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 incremental  deployment

10) 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.
 
11) Provides a new realm for working on 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-masked]>
An: Stephen  D. Strowes <[email-masked]>
Cc: [email-masked]  <[email-masked]>; [email-masked] 
<[email-masked]>
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-masked] (mailto:[email-masked])  
wrote:
 >> In einer eMail vom 30.05.2010 14:21:55 Westeuropäische Sommerzeit
 >> schreibt [email-masked] (mailto:[email-masked]) :
 >> 
 >>    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 underst
and, 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=