Which is unfortunate. Because if scaling of the global routing table is really as big of an issue as some people claim,
It's just an issue which crops up again and again, and costs money to solve each time. I've got a bunch of dual stacked sup720 pfc3b's. These no longer take a full v4 routing table in their default configuration, and shortly, I expect them not to be able to take a full v4 routing table using any soft configuration, except by filtering out routes.
Yes, I can upgrade them. But it's an issue. It means downtime and lots of ¤¤¤.
And, don't forget that you even can do multihoming without PI address space, by multihoming of PA assigment (if LIR permitted it).
Some traffic flows on default gateway, even if you have BGP full view on the router... :) Normally, longest prefix has highest priority. If your multihomed prefix doesn't exist in some part of Internet, you may have troubles with connectivity with this part of Internet, don't looking PA or PI addresses you uses.
Sorry to say, but you're running an ISP on 6500's and propose a problem with upgrading PFC-3B to PFC-3BXL at about 6.000 - 9.000 $ per engine ? Besides that, you bought a 256k prefixes engine about 2 years ago (i think it was released about sometime 2004) ? There's not only an issue of routing / routing table scalibity but also an issue of network scalability. The latter is in the sole responsibility of the ISP / LIR. Instead of table size/memory issues due to table growth we could also discuss about CPU utilization issues due to BGP updates. Did you check the CPU load of your sup720 loaded with a bunch of session ? The current number of constant updates triggers about 10-20% (at least) load on 3BXL engines when connected with decix peers and an upstream for example. Maybe we should propose serious actions to be taken against flapping systems, software- and standard-pc - based (zebra, quagga, etc.) networks, too ... /-( And in my opinion include bgp links across links of 2-4 mbit/s of bandwidth to the list above - usually those are encountered to satisfy the 2-upstreams-rule. As long as I see ASN >= 64512, prefixes down to /30, /16's with sub-advertisements of 200 /24's with the same as path, packets with source addresses out of RFC 1918 ranges even via large multinational ASN sessions, I believe there're more important general operating problems than a bunch of PI prefixes. IMHO the massive de-aggrations hurt much more (and yes, we're doing some of that ourselves). There're a lot of operational problems currently existing so why bother about a few more PI prefixes and introduce additional administrative and operational overhead ? Most time I spend with PI-related problems are advertisements < /24 sent by customers (and therefore dropped) filing a complaint later, LIR not responding to db object transfer request, inaccurate or outdated db information etc. But these won't solve by further constraining PI assignments. Remember, a PI request has to be filed with RIPE by a LIR. You can refuse the customers wishes - but that customer will find some LIR that will do just to take over the customer from you. Those arguments lead to the same discussion fought out in the IPv6 PI discussion: if the internet's end users (customers) are denied their requests by policies and their wishes are ignored, those areas will starve in the long run. regards, Marcus ------------------------------------------ Tropolys Rhein-Main GmbH Versatel Group Network Engineering and Administration ------------------------------------------ ASN 8881 / 15837 MG3031-RIPE ------------------------------------------