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 protected]>
An: Stephen D. Strowes <[email protected]>
Cc: [email protected] <[email protected]>; [email protected]
<[email protected]>
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 protected]_ (mailto:[email protected])
wrote:
>> In einer eMail vom 30.05.2010 14:21:55 Westeuropäische Sommerzeit
>> schreibt [email protected]_ (mailto:[email protected]) :
>>
>> 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=
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
