Subject: Re: [rrg] Constraints due to the need for widespread voluntary adoption

From: [email-masked]
Date: Tue, 1 Dec 2009 16:06:56 EST

Robin,
I am accrediting to you your  emphazising
that a) incremental deployment cabability is a MUST
      b) that any higher level architectural  objective must be backed by 
the respective detailed solution.
 
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 :-).
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  
[email-masked]:

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/_ 
(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

---

From: Robin Whittle <[email-masked]>
Date: Wed, 02 Dec 2009 10:55:31 +1100

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

>     the respective detailed solution.

Indeed!

> 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

> 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.
> 
> 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,
> 
> In einer eMail vom 01.12.2009 13:05:22 Westeuropäische Normalzeit
> schreibt [email-masked]:
> 
> 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.
> 
> 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 ).
> 
>       http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/
> 
> 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