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

In einer eMail vom 26.05.2008 06:18:40 Westeuropäische Normalzeit schreibt tony.li@tony.li:

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 rja@extremenetworks.com:

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

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