On 4/24/06, Pekka Savola <<a href="mailto:pekkas@netcore.fi">pekkas@netcore.fi</a>> wrote:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hi, On Fri, 21 Apr 2006, Ruchti, Marcus wrote: > I don't think flapping routes will increase due to the assignments > of PI space, as in the most cases ISP's are requesting those for > customers and offers managed multihoming solutions. So announcing > these routes into BGP is the responsibility of an ISP. First off: there has been some discussion whether 200K routes is a problem or not. If the numbers stayed at that level (how can we ensure that?), that wouldn't be a huge problem. Bigger one is dynamicity. Huston's study indicated that there are folks whose BGP announcements flap (due to TE) intentionally 1000's of times a day. Multiply that by the number of sites (and add sBGP or friends to the stew) and you may start thinking that your DFZ router might have better things to do than process that cruft.</blockquote><div> BGP flap dampening is already well understood for limiting the impact of flapping routes on your CPU, if that's a concern; it has no bearing on address allocation policy decisionmaking. And configuring dampening is up to each _recipient_ network, and is not something that should be codified into an address allocation policy, which is targetted at the _originating_ network. </div>Let's stick to the topic at hand, which is how to craft a useful address allocation policy which allows for provider indepent address allocations, while at the same time showing good stewardship of the overall address pool. The policy cannot allow itself to be shaped by the least-capable routers, or we'll be chaining ourselves to the past,unable to make adequate forward progress so long as there's any network out there that's still running old hardware that's unwilling to upgrade. I agree we need to be reasonable--but please, let's not "dumb down" the v6 internet just because some people aren't willing to step up to the plate and upgrade their routers when needed. Provider independence is here already, period. It's too late to try to put the horse back in the barn--what we *can* try to do is craft a well-thought-out policy 'bridle' for it, and then let it start running (to abuse a metaphor horribly). Trying to stop provider independent addressing in IPv6 is simply another way of saying 'IPv6 addressing is broken, let's just stick with IPv4 instead' -- because that's what the practical outcome is. Any addressing scheme that tries to deny the need for provider independent addressing is less capable for businesses than what they have today in the IPv4 world, and will therefore not be used. So. Given that PI allocations are going to happen in IPv6 just as they have in IPv4, let's put all the rest of the grumbling about it aside, acknowledge the reality of the situation, and simply agree that as a starting point, issuing a /48 out of a reserved /44 to each multi-homed, non-transit-service-providing network which applies and demonstrates it has met the requirements for being multi-homed and obtaining its own AS, is reasonable--if adjustments to the policy are needed, they can be applied in the future as needed, just as we've done in the IPv4 world. I *do* agree that stipulating that only the largest possible aggregate assigned to a given AS *should be* announced by the AS is a reasonable addition to the policy to help encourage aggregation, and prevent stupid routing mistakes like this: * <a href="http://198.144.160.0/20">198.144.160.0/20</a> <a href="http://195.66.224.82">195.66.224.82</a> 0 4513 174 6983 8051 i * <a href="http://198.144.172.0">198.144.172.0</a> <a href="http://195.66.224.82">195.66.224.82</a> 0 4513 701 8051 i (real-world example pulled from route-views; the /24 is announced by the same originating AS, but is not connected to or directly reachable from the network that announces the /20 aggregate, as was pointed out by the end-site when their /24 more specific was filtered out at one point.) That is, if you have discontiguous networks, they should each obtain their own AS, and should pay the registration fees for that AS and the associated IP aggregate which it will announce. I don't see why the discussion is dragging out for so long. This isn't rocket science. Let's just nail the policy down, and move on with more productive work. Matt </div>