<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jul 28, 2009, at 10:46 AM, Kevin Kargel wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><blockquote type="cite">AFAIK, there are no ISPs allowing customers to multihome with less<br></blockquote><blockquote type="cite">than a /24 currently but many who are allowing those /24s. So if that<br></blockquote><blockquote type="cite">Org gets a /24 from ARIN or a /24 from it's ISP, there is the same 1<br></blockquote><blockquote type="cite">entry in the table. <br></blockquote><br>This is incorrect. If the Org gets a /24 from it's upstream ISP there is<br>the same entry in the routing table. If the Org gets a discontiguous /24<br>from ARIN there is an additional entry in the routing table. <br><br>What it boils down to is whether or not the Org's ISP can aggregate the<br>netblock.<br><br></div></blockquote>If an ORG multihomes with a /24 from their ISP, then, that /24 will appear</div><div>in the routing table either from the second transit provider, or, from</div><div>both transit providers, depending on configuration.</div><div><br></div><div>If an ORG multihomes with a /24 from ARIN, then, the /24 from ARIN will</div><div>appear in the routing table from both transit providers.</div><div><br></div><div>Otherwise, there is no difference to the routing table for a multihomed /24.</div><div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font></div><div><font class="Apple-style-span" color="#000000"><br></font>But if ARIN is handing out the /24's instead of the ISP isn't the likelihood<br>far greater that the /24's will not be agregable? I doubt that ARIN will be<br>able to only hand out /24's that would be.<br><br></div></blockquote>The likelihood of the next /24 being aggregable is low regardless.</div><div><br></div><div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>I have no problem with extending the minimum mask length so long as it is<br>tied hard to a requirement that anyone with a long mask have only one<br>allocation, and to get another allocation the long mask netblock must either<br>be aggregated in to the new allocation or returned.<br><br></div></blockquote>So how about a policy like:</div><div><br></div><div><br></div><div>1.<span class="Apple-tab-span" style="white-space:pre"> </span>Amend current policy to extend mutihoming to /24 instead of /22 for end users.</div><div><br></div><div>2.<span class="Apple-tab-span" style="white-space:pre"> </span>Add the following phrase to policy:</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>If an organization requesting additional space already possesses one or more</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>ARIN assignments less than /22, ARIN will, if possible make available to the</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>organization sufficient space to aggregate existing smaller blocks into the new</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>space in addition to the justified additional space and shall allow a period</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>of no less than 18 nor more than 36 months before reclaiming the previously</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>assigned smaller blocks. If ARIN does not have a sufficiently large block, ARIN</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>shall issue space in such a way as to alllow maximal aggregation possible</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>and the return of as many addresses as possible after renumbering.</div><div><br></div><div>Owen</div><div><br></div></body></html>