Home page logo
/

nanog logo nanog mailing list archives

a not so radical proposal for PI in ip6 world: Hierarchial routing tables
From: Joe Maimon <jmaimon () ttec com>
Date: Thu, 16 Feb 2006 09:01:55 -0500


Since the list seems to be accepting topics relating to ipv6 and PI multihoming AGAIN, I thought I would chime in again with my pet idea.

Hierarchical routing. It worked for name resolution. It would work for todays routing table, which is the routing equivalent to the host file of old.

Let there be a single large prefix that will be used for all PI assignments. Let the single large prefix be further divided into "geographic regions" (nod to Michael D.)

Let policies for assignment from this prefix take geographic location into account, and be SMALL, so that another prefix will never be neccessary.

Filtering policies include the recommendation to filter out all prefixes longer than either the single large one and/or the local geographic ones.

All ISP's hosting customers with prefixes inside the PI prefix would need to advertise at a minimum both the global PI prefix and the appropriate geographic PI prefix.

Fast Forward 5 years.

Now there are 8 million PI prefixes advertised. Most ISP's routers cannot hold them and all the other 2 million non PI prefixes.

Instead ALL ISP's operate a 2 tiered hierarchy of routers. Those that have non-PI prefixes and those that do.

The routers with only non-PI prefixes may hold the ISP's local PI prefixes but will filter out any others learned.

The routers with only PI prefixes peer using multi-hop BGP to other providers routers who have PI prefixes.

The ISP must announc the global and applicable geographic PI prefixes so that PI destined traffic is attracted to their AS.

The ISP tries to keep a full table of PI prefixes so that they can MPLS TE/L2Tpv3/source route/ incoming traffic attracted by their non PI routers to their peer's handoff.

This is the key. Using a mechanism OTHER than a full table on all routers who handle the packet transiting through the AS.

If a full table is impossible, the ISP may choose to operate an array of the routers, each ibgp advertising one of the geo PI prefixes and holding only a full table for that prefix. Other filtering schemes are possible.

Some ISP's may opt to host NO PI customers. Then they do not need such an expensive router and they do not need to announce any PI prefixes.

Some ISP's may opt to NOT announce the PI prefixes. They will have to rely on their PI-Peers to attract the desired traffic and route it to their AS.

Some ISP's may opt to purchase routers capable of a 12 million prefix RIB and they will not operate such a hierarchy at all, except that their peers will undoubtedtly include ISP's who do and will need mutli-hop bgp, and those that dont and will filter all those PI prefixes out.

Perhaps one day multicast prefixes will need the same kind of hierarchy.

Or some other class of prefixes. But obviously a global table is going to need severe limits in expansion.

As for the problems of attracting unwanted traffic and handing packets back and forth between an AS's forwarding plane routers and routing plane routers, I am betting that if the problem of large table growth is so severe, the economics would favor using twice/thrice the bandwidth and fewer expensive routers than saving bandwidth and purchasing many large expensive routers.

In other words, this is a solution that can be tested and driven by the marketplace. It needs no new technology standards. All that is neccessary is some policies for PI assignment.

Customers who want it will spur its adoption. ISP's wishing to host those customers will spur its implementation. ISP's filtering their table to reduce size will ensure thatg hierarchy is needed.

Last time proposed, I had about two directly related comments.

Feel free to ignore me again this time.

Joe






  By Date           By Thread  

Current thread:
  • a not so radical proposal for PI in ip6 world: Hierarchial routing tables Joe Maimon (Feb 16)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault