<HTML>
<HEAD>
<TITLE>Re: [arin-ppml] Advisory Council Meeting Results - July 2009</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>I would just like to echo my support and agreement of the points Leo has made below. Thanks.<BR>
<BR>
<BR>
On 7/23/09 1:35 PM, "Leo Bicknell" <<a href="bicknell@ufp.org">bicknell@ufp.org</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>In a message written on Thu, Jul 23, 2009 at 12:08:00PM -0400, Jason Schiller wrote:<BR>
> So the question is does the community still feel we need to send a message<BR>
> to the vendors and the providers that they need to support 32 bit ASNs in<BR>
> a real way?<BR>
<BR>
I believe that message was sent, and received. While the vendors are<BR>
not quite where I would like them to be in terms of availability, I<BR>
don't think sending more messages at this point is going to be<BR>
productive.<BR>
<BR>
> Does the community feel there is value in arbitrarily setting a date to<BR>
> aid in setting a reasonable expectation of when vendors and providers<BR>
> need to be able to support 32 bit ASNs in a real way?<BR>
<BR>
I believe there is value in knowing the date, but it need not be<BR>
arbitrary. For instance, 16 bit ASN's will run out in less than two<BR>
years it would appear, which is a fairly well known date.<BR>
<BR>
> Or is vendor support and provider support sufficiently advanced that is is<BR>
> no longer a concern?<BR>
<BR>
AFAIK, the vast majority of the vendors have working code at this point.<BR>
The issue is that it may not be in all of the various forms they release<BR>
code yet, but that is going to be a function of their release cycles and<BR>
no amount of policy will change that.<BR>
<BR>
> Does the community feel that removal of the date and giving out low<BR>
> numbered 32 bit ASNs will slow adoption of 32 bit ASNs as the "problem of<BR>
> needing to support 32 bit ASNs" will be out of sight and out of mind, and<BR>
> then suddenly and surprisingly re-emerge on some unknown date when the<BR>
> lowest valued 32 bit ASN clicks over that 16 bit boundary?<BR>
<BR>
I'm not sure I think it will surprisingly reemerge, as the run-out date<BR>
is fairly well predicted, but it will re-emerge. From an ISP<BR>
perspective, it only takes one customer needing this feature for you to<BR>
have to go off and do the work to figure out what you need to do; so I<BR>
don't think a short reprieve makes us really go backwards in terms of<BR>
support. If anything, it may provide for a smoother transition as<BR>
providers can roll out the code in normal cycles, rather than a router<BR>
at a time as customers demand it.<BR>
<BR>
> Does the community think there is value in being able to request a higher<BR>
> valued (over the 16 bit boundary) 32 bit ASN when smaller valued ASNs are<BR>
> available to allow providers to test and prepare for supporting 32 bit<BR>
> ASNs? <BR>
<BR>
This is the only area where I have some concern. I think folks should<BR>
be able to show up and say "I want a 32 bit ASN" while there are 16 bit<BR>
ones still in the free pool, be it for testing or because they want to<BR>
leave 16 bit ones for those who need them.<BR>
<BR>
That said, all indications are that you could probably count the number<BR>
of folks who would request and use 32 bit ASN's on one hand during the<BR>
timeframe in question. Because of that I have my doubts it is worth the<BR>
community, ac, board and staff time to pass a policy at this point. We<BR>
do have many other issues on the table. :)<BR>
<BR>
--<BR>
Leo Bicknell - <a href="bicknell@ufp.org">bicknell@ufp.org</a> - CCIE 3440<BR>
PGP keys at <a href="http://www.ufp.org/~bicknell/">http://www.ufp.org/~bicknell/</a><BR>
<BR>
<HR ALIGN=CENTER SIZE="3" WIDTH="95%"></SPAN></FONT><FONT SIZE="2"><FONT FACE="Consolas, Courier New, Courier"><SPAN STYLE='font-size:10pt'>_______________________________________________<BR>
PPML<BR>
You are receiving this message because you are subscribed to<BR>
the ARIN Public Policy Mailing List (<a href="ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<BR>
Unsubscribe or manage your mailing list subscription at:<BR>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a><BR>
Please contact <a href="info@arin.net">info@arin.net</a> if you experience any issues.<BR>
</SPAN></FONT></FONT></BLOCKQUOTE>
<pre>This E-mail and any of its attachments may contain Time Warner
Cable proprietary information, which is privileged, confidential,
or subject to copyright belonging to Time Warner Cable. This E-mail
is intended solely for the use of the individual or entity to which
it is addressed. If you are not the intended recipient of this
E-mail, you are hereby notified that any dissemination,
distribution, copying, or action taken in relation to the contents
of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify
the sender immediately and permanently delete the original and any
copy of this E-mail and any printout.
</pre></BODY>
</HTML>