Subject: Re: [RRG] Consensus? IPv4 scaling problem must be solved directly, not by rel...

From: [email-masked]
Date: Mon, 26 May 2008 06:53:48 EDT

In einer eMail vom 26.05.2008 06:18:40 Westeuropäische Normalzeit schreibt  
[email-masked]:

To date,  no one has demonstrated a routing architecture that scales  without
aggregation, and aggregation is THE sore  point.

I have to disagree. My concept is  based on non-aggegation and I am  
continuing to improve it so that it is
non-aggregation based from the ingress to the egress, no matter whether a  
hop is intra- or inter-domain.

In einer eMail vom 26.05.2008 04:20:40 Westeuropäische Normalzeit schreibt  
[email-masked]:

John  Scudder (Juniper) had a presentation on BGP and FIB/RIB
scaling at NANOG in  Toronto a year or so back (shortly after
the IAB  Workshop):

_http://www.nanog.org/mtg-0702/presentations/fib-scudder.pdf_ 
(http://www.nanog.org/mtg-0702/presentations/fib-scudder.pdf) 

This presentation mentions the importance of fast forwarding.
 
With my concept (at its current status) any router, from the ingress router  
down to the egress router will be enabled to make exactly one single table  
lookup for retrieving the next hop. The index for this table is supposed to be  
forwarded, unchanged from the ingress router down to the egress router.
 
It is just like MPLS, but without the need for a label distribution  protocol 
and without the need for replacing the label/index at each transit  router. 
But yes, the ingress router must derive it from the destinations' egress  
router's geographical coordinates.
The format for forwarding this index is, IMO, secondary. The options are:  
outer header, optional paramter, part of the IPv6-address, MPLS-like shim. But  
because NIRA is  off mainstream, I have to wait and listen what format is  
acceptable because needed/ok-ed by any loc/id-split concept.
 
And it does scale: 600 nodes, approx. 3x600 strict/loose links incl.  precise 
length values indicating the number of hops. The table to be maintained  is 
about 72 K entries.
 
And: Everyone can imagine that the indexed entry may provide a) the best  
next hop, plus b): a list of alternative hops like ECMP-hops and even  more.
Multihoming: A user address needs to be combined with aset of  
geo.coordinates of different routers from different ISPs.
Mobility: I haven't thought about it yet and I don't know enough about  
Mobile. But I am convinced that it will be helpful here too.
 
Again: Address aggregation is not needed at all. At first, I thought about  
avoiding it, as long as the destination is located at some other  
longitude/latitude square degree, but were still needed otherwise and also still  needed 
within OSPF. But now I know: Address aggregation can be made completely  to a 
non-topic at all.
 
Heiner

 

Heiner