Re: [rrg] TARA and voluntary adoption

[[e-mail]]

In einer eMail vom 02.12.2009 00:55:43 Westeuropäische Normalzeit schreibt  
[e-mail]:

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


I think I presented a lot of details wrt the goal to be accomplished:  get 
a well reduced map of the internet's topology so that based on the  
destination's (known) geographical coordinates the proper next hop can be  
determined even if the node  with these coordinates wouldn't even show up  on this 
map.
Sure, there are more details, but knowing them won't help as long as people 
 are not willing to give up the old paradigms which is  aggregating 
addresses, aggregating nodes, aggregating ASes (right?), i.e.  forming the wrong 
hierarchies. Just have a look to some actual LISP  thread.  Or see 
draft-zhang-zhang-evolution-02.txt - it contains  suggestions about compressing the FIB 
which imho should rather be addressed  to the idr-WG where they should be 
welcome unless they are already common  practice. I pointed out that the 
postal mail does not do address prefix  aggregation and can easily cope with a 
100 000 bigger network of streets. Node  aggregation: PNNI did node 
aggregation resulting in hierarchical nodes which  then needed node-internal 
topologies ;-(  And isn't ILNP eager to deal with  AS aggregation ?  (I don't know 
for sure and I even don't want  to waste time looking at such ideas). I 
admit, PNNI has been my background,  but today I know that topology aggregation 
is the only right way of doing  aggregation. However, not even the new term 
"topology aggregation"   could   stimulate the curiosity of the researchers 
of this routing  research group. 
When I explained how to hereby enable shortest path forwarding, the  
reproach was I would be unaware of policy routing. Did I mention "hierarchy"  
(although only the process to collect the data is somehow hierarchical) then,  
the stretch argument was raised - though that would indeed be appropriate for 
 only all the other hierarchies (PNNI, ISLAY, ILNP,...). Did I use the 
words  "eliminating" or "abolishing" the scalability problem, I was told that 
only  "reduction" is at stake.
 
We discuss all kind of identifiers but not which identifiers would be best  
for JUST routing. Robin, you yourself boast with not needing an own 
namespace  for routing. I would rather see such a namespace which is JUST for  
routing.
At last I thought, in view of the mobility topic, that  no  one would 
stubbornly stick to mapping  routable GPS-info to  non-routable addresses. But 
the reaction is once more silence. Yes, absolute  silence, although we are 
going to see millions and billions of mobile  internet-accessible handsets.
 
All these aspects (and many more which I have come up with) have  been 
ignored over the last few years and are still being ignored as if the  task of 
the RRG is to block successfully any better and scalable  routing. 
 
 Heiner 
 
 
 
 

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