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