Subject: Re: [rrg] and while we're at it, here's a view from the ground...

From: [email-masked]
Date: Fri, 31 Oct 2008 14:33:04 EDT

In einer eMail vom 31.10.2008 17:13:09 Westeuropäische Normalzeit schreibt  
[email-masked]:

> As  a matter of fact this RRG group has never understood what 
> is the REAL  cause of the problem nor how to exploit location REALLY.
>  
> Heiner
>  

I guess its equally apparent you  never understood that geo addressing 
requires fundamental changes to the  economic make up of the commercial  Internet.

-Darrel

Oh no. The way I would use geographical coordinates is completely  
transparent to any geographical meaning (like continent, country, state,  city,...) It 
is only a means to select the right "proxy  destination  node" in the case that 
your true destination node is not yet "on your radar  screen". Based on it 
you determine the next hop. There is no change of the  economic make up. It is 
only that the next hop is determined in a different and  scaling way and can, 
in the data plane, be retrieved much faster than  by searching thru a 300 000 
entries sized table.
 
In a preceding email I once stated that the next hop determination (in the  
data plane) takes only one single table offset lookup. Admitted, I have to  
backup a little bit: If the destination is within a different spherical  
rectangle (limited by two consecutive longitudes and two consecutive latitudes)  yes 
then it takes only 1 table offset lookup. However, otherwise it will take 3.  
This wouldn't by any different even if the internet would be a million times  
bigger.
 
And this would only be the beginning for better routing: 
With respect to a particular destination any router can subdivide its  
adjacent links into 3 classes A, B, C.
Class A: the remote node is one hop closer to the destination
Class B: the remote node is equidistant away from the destination
Class C: the remote node is one hop further away from the destination
Multipath: With DV-based routing you can only use the links of class A.  With 
TARA you can also use the links of classes B and C - which includes  
detecting whether or not the link leads into a dead end area, and/or whether or  not 
there is a chance to wind up in a loop and how to avoid it if  applicable.
 
Without TARA:  In spite of 250 000 stored routes only one third  of the 
possibilities (i.e. only class A links) can be used. Note,  the  second best hop 
may already be part of a detouring path, i.e. from  class B or C !
BTW: The IETF's intra-domain routing isn't any better, see  ipfrr :-(
 
Heiner
 
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: "Christopher Morrow" <[email-masked]>
Date: Fri, 31 Oct 2008 21:29:08 -0400

On Fri, Oct 31, 2008 at 2:33 PM,  <[email-masked]> wrote:

> transparent to any geographical meaning (like continent, country, state,

and I read your example of driving or paper-mailing things pretty much
as examples, akin to: "Route your traffic to AS1239, let them find the
right internal place to deliver to..."

which seemed sane enough, and in fact quite a bit like LISP or some of
the other loc/id split techniques.

> city,...) It is only a means to select the right "proxy  destination node"
> in the case that your true destination node is not yet "on your radar
> screen". Based on it you determine the next hop. There is no change of the
> economic make up. It is only that the next hop is determined in a different

so yea, that again sounds like LISP... ETRs/ITRs...

> and scaling way and can, in the data plane, be retrieved much faster than by
> searching thru a 300 000 entries sized table.
>

300k isn't so much a problem for most core devices today, 3m though... could be.

> rectangle (limited by two consecutive longitudes and two consecutive
> latitudes) yes then it takes only 1 table offset lookup. However, otherwise

how do longtitude and latitude matter for networks exactly? Save a few
minor examples no one builds a network on lat/long boundaries... and
often costs associated with paths in a network are more related to
underlying fiber costs or peering costs than distances.

> it will take 3. This wouldn't by any different even if the internet would be
> a million times bigger.
>
> detecting whether or not the link leads into a dead end area, and/or whether
> or not there is a chance to wind up in a loop and how to avoid it if
> applicable.
>

how is route stretch measured? latency? jitter? how are services that
depend upon lower latency and consistent (low jitter) latency supposed
to survive in this climate? One of the reasons for the existing state
in the global table (some of it at least) is for traffic-engineering
concerns, I don't see the above scenario addressing those, but maybe
you've just oversimplified.

-chris