[rrg] TARA and voluntary adoption

[Robin Whittle <[e-mail]>]

Short version:    Heiner has not given any explanation of TARA.



Hello Heiner,

Thanks for your response in the "Constraints due to the need for
widespread voluntary adoption" thread.  Since it concerns your
proposal, rather than the constraints, I am responding in a new thread.

You wrote:

> I am accrediting to you your emphazising that:
>
>  a) incremental deployment cabability is a MUST

"Incremental deployment" means different things to different people.
 We debated this in the past and I found that for many people, it
just means that a new system can be introduced without disrupting the
existing system.

What is needed for voluntary adoption of a scalable routing solution
goes far beyond this.

  http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/

Constraints 1 to 5 involve end-users of the new system being fully
able to communicate with users who have not adopted the new system -
in both directions, including with the non-upgraded user's host
initiating the communication.  This is a far greater constraint than
what many people understand by the term "incremental deployment".
Here is one message from that discussion thread:

  http://www.ops.ietf.org/lists/rrg/2008/msg00957.html


>  b) that any higher level architectural objective must be backed by
>     the respective detailed solution.

Indeed!


> ad a) I completey agree. I do claim this for TARA. By the same token any
> other competing solution can be deployed incrementally - CONCURRENTLY (
> so I hesitate to promote the competing solutions :-).

OK, but you need to describe TARA in a manner which enables people to
understand how it would work, and how users with non-TARA hosts (if
it involves any host changes) in non-TARA networks (if TARA involves
changes to end-user or ISP networks) can communicate with hosts using
TARA.

Your website:

  http://www.hummel-research.de/

is of no use to me, or I suspect to anyone with a detailed interest
in scalable routing.  The total text content would fit on an A4 page,
but is divided into multiple Flash pages.  You have never given a
detailed account of TARA on this list as far as I know.

Please present your work in text, or HTML - and ideally as an
Internet Draft - if you want me to consider it.

The remainder of your message contains no explanation of TARA
whatsoever.  If I ask you to give details of how you are going to
design, build and ride a motorbike over some mountain tracks, it is
not good enough to respond with a short story about how mountain
goats navigate their territory.

  - Robin


> This group think that it holds all the marbles in the own hand. Wrong. A
> e.g. (most and forever) scalable solution can be deployed even
> unnoticed. BGP provides everything that is hereby needed.
> 
> Therefore I don't feel urged to participate in the race of soliciting
> the own solution within the next few days.
> 
> (and you shouldn't either )
> 
> ad b)
> 
> I think the same way. So, be assured whenever I take my mouth full,
> either by boasting what TARA can accomplish or by harsh critizising
> other  more-liked solutions or by emphasizing important requirements,
> 
> It is always backed by the knowledge about the detailed solution.
> 
> In einer eMail vom 01.12.2009 13:05:22 Westeuropäische Normalzeit
> schreibt [e-mail]:
> 
>     I have never been able to understand what you keep mentioning about
>     geographic mapping, or "location-namespace" etc.  Can you give a
>     practical explanation of how it would work, with a different thread
>     subject than this one?
> 
> I did give a practical analogy: The tourist who wants to go from Munich,
> Karlsplatz (Germany) to Sausolito, Mainstreet California equipped with
> maps of the current city, county, state, country, continent and the
> world map. He will be able to determine the next hop although his
> destination doesn't show up on any of these maps.With what I have in
> mind he will be able to compute a flat map which combines all of these
> maps, and how you would get them, e.g. such that any direct link let's
> say from Munich airport to S.F.airport is included while thousand
> others, e.g. like Vancouver to Seattle, aren't.
> 
> But so far I have to be patient ( after all, it is only my personal
> solution, meanwhile without any partners - a situation which I think you
> share with me:-). No one is interested in better routing technology
> although, for instance, a similarly reduced map wrt the sum of all
> areas of an OSPF network might as well be of interest ( I think, though
> I don't care very much about this side effect in view of the importance
> of a future routing architecture ).
> 
>     How would your system enable non-upgraded hosts or upgraded hosts in
>     non-upgraded networks communicate with the devices using your system?
>     This is my question 3:
> 
>       http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/
> 
> Well, see ad a) and also let's see what the leaders of this group will
> recommend.
> 
>     How would traffic using your system traverse the DFZ?  This is my
>     question 6.
> 
> Definitely most capable, i.e. capable to take the shortest route, or any
> detour (see the picture on my website; unfortunately it doesn't show the
> entire set of detouring possibilities - but I could compute you some).
> 
> No one can do magic tricks. There is a wide area of work waiting for
> all. Example: The shortest route to the destination at almost the other
> side of the globe be westward bound. I decide to go eastward. For the
> next few routers the westbound route is still shortest. how do I
> indicate that they should comply with my initial decision? Though I
> haven't even looked closer to this scenario, I am optimistic to find a
> solution.But I cannot see at all how the current routing
> technology would even scratch at this issue).
> 
> Heiner