Subject: Re: [rrg] Routing through

From: "Stephen D. Strowes" <[email-masked]>
Date: Tue, 01 Jun 2010 18:37:45 +0100

On 30/05/10 15:06, [email-masked] wrote:
> In einer eMail vom 30.05.2010 14:21:55 Westeuropäische Sommerzeit
> schreibt [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 
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.

---

From: Toni Stoev <[email-masked]>
Date: Wed, 2 Jun 2010 01:15:45 +0300

> able to read it, regardless of what proposals other people may "favour".

Thanks for saying this all, Stephen.

I can see this list is not keen on adopting something quite different than the current mainstream. Especially some theory that a single person has developed.
A theory does get derived out of basics. If basics are acceptable, then the theory is likely to be comprehended. I'm trying to get the basics of Heiner's theory.

I may take to something and put into my theory.

Bottoms up.
Toni

---

From: Toni Stoev <[email-masked]>
Date: Wed, 2 Jun 2010 11:31:22 +0300

> I may take to something and put into my theory.

I may also have something to add to Heiner's theory.

---

From: Lixia Zhang <[email-masked]>
Date: Wed, 2 Jun 2010 23:46:36 -0700

On Jun 1, 2010, at 10:37 AM, Stephen D. Strowes wrote:

> 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

---

From: [email-masked]
Date: Thu, 03 Jun 2010 06:43:28 -0400

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

> 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".
> -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=