Subject: Re: [RRG] Taxonomy: 25 questions - Heiner Hummel's proposal

From: Robin Whittle <[email-masked]>
Date: Wed, 02 Apr 2008 21:14:57 +1100

Hi Heiner,

I have never been able to understand your proposal in any concrete
sense.  I understand you have some radical new way of using the
existing IPv4 address space.  If you are using some other addressing
system, then this means host changes and usage changes for the vast
majority of hosts, so the answer is Yes.

If by "ingress node" or "egress node" you mean "host":

> Robin, the Yes can be replaced by a No, if the ingress node added and
> the egress node removed the geographical coordinates. Of course, the
> ingress node must be enabled to add them. It must cache them, e.g. upon
> a preceding DNS lookup according to the experimental RFC 1712.
> I know RFC1712 was hardly been read: There where it nails down the
> encoding, longitudes and latitudes are terribly mixed up :-( 

then the answer to Q01 is Yes.

If by these you mean routers, then the answer to Q02 would be No,
because for your system to provide benefits, you are using a form of
addressing which can't be understood by routers or hosts in
non-upgraded networks.  So you can't maintain communications between
upgraded hosts (or non-upgraded hosts in upgraded networks) and
ordinary hosts - unless perhaps your hosts in upgraded networks can
also use an ordinary IPv4 address, in which case your proposal
couldn't provide benefits by getting hosts off conventionally
managed IPv4 addresses.

I am thinking about the transition time - not some time when
everyone runs your system, because that will never happen unless the
transition involves no loss of connectivity to non-upgraded hosts.

I suggest you write up a clear, diagrammatic, explanation of your
proposal.  If you can convince me it doesn't involve host upgrades,
and therefore only involves router upgrades, and if you can show it
provides significant benefits to early adoptors while also making a
significant improvement on the routing scaling problem, while
maintaining full compatibility with all non-upgraded hosts, I will
revise what I wrote.  Also, your proposal can't involve any option
headers etc. for packets transiting the DFZ, because the routers
there will not handle such packets at full speed - or perhaps at all.

  - Robin

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: [email-masked]
Date: Wed, 2 Apr 2008 07:43:53 EDT

Hi Robin,
 
By ingress node and egress node I mean ingress router and egress  router.
Let's assume the ingress router has added the geographical coordinates as  
optional parameter.
Those routers which do not understand my architecture proceed just like now  
(quasi watch for the direction signs aside of the road), while those routers  
which know my concept  do the forwarding based on the geographical  
coordinates if provided, or just like today if not provided (quasi   either watch for 
the direction signs, or listen to the navigating  voice).
 
There is one point left open:How can my concept evolve while there  are a lot 
of routers in-between which do not contribute so that  the routers can aquire 
their specific hierarchichally sparsed network view ? But  for this 
sub-problem there are patterns, e.g. MPLS/VPN RFC2547, how  knowlegeable routers may 
learn about each other, although they are not immediate  neighbors. Yes, needs 
further study, but precisely here, all who know  better than me the currently 
deployed protocols, can help for sure.
 
BTW (incentive): You may look at the graph on my web-site and see the shown  
multipath capability (which can even be extended) for a strict-links based  
intra-domain network. The same capability could be provided for the combined  
intra/inter-domain internet with strict intra-domain links, and with loose  
inter-domain links, which are the looser and concurrently the stablier the more  
remote they are.

Heiner

---

From: Robin Whittle <[email-masked]>
Date: Thu, 03 Apr 2008 00:27:29 +1100

Hi Heiner,

Looking at your proposal:

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

I find:

  IPv4 addresses may stay fairly forever, because they have to be
  unique only within the same 1x1-square-degree geo-patch.

which is impossible for me to reconcile with compatibility with
today's Internet, in which there is a single IPv4 space.

Also, I see a lot of complex stuff but no network diagrams or
details of how you add geographic information to IPv4 packets
travelling in the DFZ.

As in the past, I am unable to understand your proposal in any
concrete fashion.  I won't discuss it on the list until you or
someone else who understands it can explain it to me in a way I
clearly understand.

  - Robin

---

From: [email-masked]
Date: Wed, 2 Apr 2008 10:20:39 EDT

Hi Robin,
 
Yes , let's discuss it off-list.  BTW, I removed the pdf-file a while  ago 
when I realized that the current loc/id-split is all what counts.
 
There are several options to deal with the address depletion, uniqueness  per 
1x1-square-degree geo-patch is one of them.
 
Heiner

In einer eMail vom 02.04.2008 15:20:48 Westeuropäische Normalzeit schreibt  
[email-masked]:

Hi  Heiner,

I find:

- Robin