<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 9, 2010, at 2:38 PM, William Herrin wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Mon, Aug 9, 2010 at 4:21 PM, Leo Vegoda <<a href="mailto:leo.vegoda@icann.org">leo.vegoda@icann.org</a>> wrote:<br><blockquote type="cite">On 9 Aug 2010, at 2:34, Owen DeLong wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">This is an attempt to head off prefix-growth by allowing ISPs to do planning<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">if they wish.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Why are ISPs not able to plan ahead at the moment?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Regards,<br></blockquote><blockquote type="cite">Leo<br></blockquote><br>Leo,<br><br>You're kidding, right?<br><br>The current v6 dogma is that we're going to provide ISPs with exactly<br>one allocation to the maximum extent possible, so we want to get that<br>one right and/or include reserve slack surrounding the allocation so<br>that the netmask expands. That's why we haven't organized things as a<br>slow start.<br><br></div></blockquote>Correct. I find it very interesting that out of one side of your mouth, you talk</div><div>about concern for routing table growth, yet, out of the other side, you say</div><div>we should return IPv6 back to slow-start so as to maximize the need to</div><div>make additional allocations to ISPs as they grow.</div><div><br><blockquote type="cite"><div>One problem, of course, is that ISPs are used to planning address<br>consumption on 6 and 12 month scales, not decades. They have no<br>practical experience to guide them with longer range planning.<br><br></div></blockquote>While this is true, it's a relatively minor problem of education.</div><div>Further, decades isn't a fair characterization of my proposal which</div><div>stated a 5 year time horizon as a straw-man and asked for input</div><div>on what people felt would be the best value. So far, the only other</div><div>suggestion I've received was 3 years.</div><div><br><blockquote type="cite"><div>Making matters worse, v6 allocation and v4 allocation have a<br>fundamentally different basis. V4 allocation is host-centric: you<br>assign a /32 to a host. V6 allocation is LAN-centric: you assign /64's<br>to a LAN. ISPs have experience counting hosts. Counting lans is a<br>little different; it confuses the numbers.<br><br></div></blockquote>Again, not a particularly hard problem to solve with a small amount of</div><div>education.</div><div><br></div><div>If anything, counting "network segments" (It isn't really counting</div><div>LANs, this is another mischaracterization) is, if anything, a whole</div><div>lot easier than counting hosts. You don't need to worry about how</div><div>many things are in a given segment, just how many segments you</div><div>need. It's not like you didn't have to count those before, you just</div><div>had to take the additional step of sizing them to barely fit the number</div><div>of hosts.</div><div><br><blockquote type="cite"><div>More abstractly speaking, the history of long-range planning in<br>general is littered with more failure than success. And the successes<br>tend to focus more on positioning the entity to right-size rather than<br>pre-determining what the right size is.<br><br></div></blockquote>Largely because attempts to right-size were pinned against a need to</div><div>conserve addresses. As things stand, moving that perception forward</div><div>into IPv6 is, in my opinion, the greatest danger to good aggregation.</div><div><br><blockquote type="cite"><div>And lest we forget: IPv6 is not currently a moneymaker nor anticipated<br>to soon be a moneymaker, so the funding to support any sort of long<br>range planning simply isn't there.<br><br></div></blockquote>Again, this is an area where we disagree. I know several organizations</div><div>with large networks that are most definitely engaged in long-range</div><div>planning for IPv6. If we make that long-range planning simpler (such</div><div>as what I have attempted to propose):</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>1.<span class="Apple-tab-span" style="white-space:pre"> </span>Determine number of end sites served by largest POP</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>2.<span class="Apple-tab-span" style="white-space:pre"> </span>Round that number up to a nibble boundary.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>3.<span class="Apple-tab-span" style="white-space:pre"> </span>Determine the number of POPs.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>4.<span class="Apple-tab-span" style="white-space:pre"> </span>Again, round that number up to a nibble boundary.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>6.<span class="Apple-tab-span" style="white-space:pre"> </span>Get a prefix large enough to contain the required number of POPs</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>each of which has enough /48s for the number of end-sites</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>determined in step 2.</div><div><br></div><div>Perhaps this simplicity got lost in the math detail that I included</div><div>in the original proposal. Here's an example exercise I hope will</div><div>help:</div><div><br></div><div>You have 200 end sites served by your largest pop. Rounding</div><div>up to a nibble boundary, we get to 8-bits (256 end sites per POP).</div><div><br></div><div>You have 100 POPs now and expect that to triple over the next</div><div>5 years. 500 rounded up to a nibble boundary is 4096 (12 bits).</div><div><br></div><div>We need a total of 20 bits of prefix to number all of our POPs, giving</div><div>256 segments to each POP. Our own infrastructure fits well within</div><div>the round-up at both levels. To provide /48s to each end-site, we</div><div>will need give a /40 to each POP. To have 12 bits worth of /40s,</div><div>we will need to get a /28 from the RIR.</div><div><br></div><div>Here's a convenient table of nibble boundaries to make rounding</div><div>up easier:</div><div><br></div><div><br></div><div><font class="Apple-style-span" face="Monaco">Min</font><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Monaco"> </font></span><font class="Apple-style-span" face="Monaco">Max</font><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Monaco"> <span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-style-span" style="white-space: normal;">Bits</span></font></span><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Monaco"> <span class="Apple-style-span" style="white-space: normal;">Units represented</span></font></span></div><div><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Monaco"><span class="Apple-style-span" style="white-space: normal;"> 1<span class="Apple-tab-span" style="white-space:pre"> </span> 12<span class="Apple-tab-span" style="white-space:pre"> </span> 4<span class="Apple-tab-span" style="white-space:pre"> </span> 16</span></font></span></div><div><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Monaco"><span class="Apple-style-span" style="white-space: normal;"> 13<span class="Apple-tab-span" style="white-space:pre"> </span> 240<span class="Apple-tab-span" style="white-space:pre"> </span> 8<span class="Apple-tab-span" style="white-space:pre"> </span> 256</span></font></span></div><div><font class="Apple-style-span" face="Monaco"> 241<span class="Apple-tab-span" style="white-space:pre"> </span> 3840<span class="Apple-tab-span" style="white-space:pre"> </span>12<span class="Apple-tab-span" style="white-space:pre"> </span> 4,096</font></div><div><font class="Apple-style-span" face="Monaco"> 3,841<span class="Apple-tab-span" style="white-space:pre"> </span> 61,440<span class="Apple-tab-span" style="white-space:pre"> </span>16<span class="Apple-tab-span" style="white-space:pre"> </span> 65,536</font></div><div><font class="Apple-style-span" face="Monaco"> 61,441<span class="Apple-tab-span" style="white-space:pre"> </span> 983,040<span class="Apple-tab-span" style="white-space:pre"> </span>20<span class="Apple-tab-span" style="white-space:pre"> </span> 1,048,576</font></div><div><font class="Apple-style-span" face="Monaco">983,041<span class="Apple-tab-span" style="white-space:pre"> </span> 15,728,640<span class="Apple-tab-span" style="white-space:pre"> </span>24<span class="Apple-tab-span" style="white-space:pre"> </span>16,777,216</font></div><div><font class="Apple-style-span" face="Monaco"><br></font></div><div>I doubt that any real deployment is likely to get beyond the 16 bit</div><div>row on this table. (Remember, you do two look ups on the table</div><div>and the add the number of bits required together, no real</div><div>multiplication required).</div><div><br></div><div>As you can see from the table, this really doesn't have to be hard and</div><div>will create a relatively small number of prefix sizes while still allowing</div><div>allocations to be liberal without being needlessly excessive.</div><div><br></div><div>So, for example, a pretty large provider with, say, 10,000 end sites</div><div>served by their largest POPs and, say, 1,000 POPs expects to</div><div>have 10% growth per year for the next 5 years.</div><div><br></div><div>10,000 end sites/POP grows to 16,105.</div><div>1,000 POPs grows to 1,611 POPs.</div><div><br></div><div>Using the table above, we find that we should plan on requesting</div><div>16 bits for each POP and 12 bits to represent the number of POPs.</div><div>That's 28 bits needed. 48-28 is 20. We should request a /20.</div><div><br></div><div>Quite simple, really. No actual difficult math once the table is</div><div>published.</div><div><br></div><div>If each RIR gives two /20s to EVERY active autonomous system</div><div>currently on the internet, we would still only consume 161 /12s</div><div>from 2000::/3. As such, I would argue this is still a relatively</div><div>conservative consumption of the IP address space.</div><div><br></div><div>To prevent this from impacting the routing system, yes, providers</div><div>should be discouraged from disaggregating this space. I believe</div><div>that the community is, generally, quite capable of doing this through</div><div>education.</div><div><br></div><div>It hasn't been possible in IPv4 because it wasn't possible to have</div><div>this kind of allocation policy to reduce the number of opportunities</div><div>to legitimately advertise disparate prefixes.</div><div><br></div><div>Owen</div><div><br></div></body></html>