a not so radical proposal for PI in ip6 world: Hierarchial routing tables
jmaimon at ttec.com
Thu Feb 16 14:01:55 UTC 2006
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
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
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
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.
More information about the NANOG