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

HeinerHummel@aol.com Tue, 01 December 2009 21:07 UTC

Return-Path: <HeinerHummel@aol.com>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BF353A68AC for <rrg@core3.amsl.com>; Tue, 1 Dec 2009 13:07:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.23
X-Spam-Level:
X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZ1thk8StS9M for <rrg@core3.amsl.com>; Tue, 1 Dec 2009 13:07:54 -0800 (PST)
Received: from imr-mb02.mx.aol.com (imr-mb02.mx.aol.com [64.12.207.163]) by core3.amsl.com (Postfix) with ESMTP id 95FAA3A679C for <rrg@irtf.org>; Tue, 1 Dec 2009 13:07:28 -0800 (PST)
Received: from imo-da03.mx.aol.com (imo-da03.mx.aol.com [205.188.169.201]) by imr-mb02.mx.aol.com (8.14.1/8.14.1) with ESMTP id nB1L70Xw014412; Tue, 1 Dec 2009 16:07:00 -0500
Received: from HeinerHummel@aol.com by imo-da03.mx.aol.com (mail_out_v42.5.) id n.c6c.5e2984d2 (65100); Tue, 1 Dec 2009 16:06:56 -0500 (EST)
From: HeinerHummel@aol.com
Message-ID: <c6c.5e2984d2.3846df70@aol.com>
Date: Tue, 01 Dec 2009 16:06:56 -0500
To: rw@firstpr.com.au, rrg@irtf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-----------------------------1259701616"
X-Mailer: 9.0 SE for Windows sub 5021
X-AOL-SENDER: HeinerHummel@aol.com
Subject: Re: [rrg] Constraints due to the need for widespread voluntary adoption
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Dec 2009 21:07:56 -0000

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  
rw@firstpr.com.au:


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