First off, I'd like to also add my voice in support of this<br>proposal for the record.<br><br>On 3/20/06, <b class="gmail_sendername">Louis Lee</b> <<a href="mailto:louie@equinix.com">louie@equinix.com</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;">[...]<br>Just some additional thoughts....<br><br>ARIN already documents the micro-allocations as lists:
<br><a href="http://www.arin.net/reference/micro_allocations.html">http://www.arin.net/reference/micro_allocations.html</a><br><br>That being the case, is it really necessary to have specific<br>blocks reserved for each of the 3 (or 4) categories (times 2: one
<br>set for v4 and another set for v6)?  I'd imagine that operators<br>may find it convenient to configure route filters and IP filters<br>so they can treat each block differently.  But is that happening<br>today?  And would someone with a crystal ball tell me if these
<br>filters will be built based on these blocks in the future? ;)</blockquote><div><br>The filters do exist today, but they're painful to keep updated<br>because in v4 space the allocations are done as individual /24s,<br>
so each time a new IX comes online, it means adding yet another<br>line to the filter.   206.223 seemed like a step in the right direction,<br>I was hoping that we'd get to the point of just being able to filter<br>206.223
/16 and not have to keep updating filters--but existing<br>exchange points never went back and re-numbered off their old<br>198.32 space, and now there's new IXs being numbered out of<br>206.197 (personally, my favorite from the ARIN list at the link
<br>above is 206.197.310.0/24 -- I still haven't managed to get my<br>router to accept that in the filter.  Good thing I'm not planning to<br>connect to that IX any time soon!).  Yes, I know that's a typo--but<br>that's one consequence of assigning the microallocations in the
<br>current fashion.  Let's not use 'this is how we do it today' be a reason<br>for not doing it better in the future.<br><br>So--yes, let's set aside 4 microallocation blocks in v6 for the<br>categories listed; all such allocations will come from the associated
<br>microallocation block, and those of us operating large networks<br>will then be able to use our filters without the current headache<br>of updating them on such a regular basis.<br><br>Thanks!<br><br>Matt<br>(putting his crystal ball away until next time)
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Best regards,<br>Louie<br>--<br>Louis Lee<br>Sr. Network Architect<br>New Service Development
<br>Equinix, Inc.<br><a href="mailto:louie@equinix.com">louie@equinix.com</a><br>desk: 408/360-5253<br>main: 650/513-7000<br>_______________________________________________<br>PPML mailing list<br><a href="mailto:PPML@arin.net">
PPML@arin.net</a><br><a href="http://lists.arin.net/mailman/listinfo/ppml">http://lists.arin.net/mailman/listinfo/ppml</a><br></blockquote></div><br>