[arin-ppml] Advisory Council Meeting Results - July 2009
john.sweeting at twcable.com
Thu Jul 23 13:58:25 EDT 2009
I would just like to echo my support and agreement of the points Leo has
made below. Thanks.
On 7/23/09 1:35 PM, "Leo Bicknell" <bicknell at ufp.org> wrote:
> In a message written on Thu, Jul 23, 2009 at 12:08:00PM -0400, Jason Schiller
>> > So the question is does the community still feel we need to send a message
>> > to the vendors and the providers that they need to support 32 bit ASNs in
>> > a real way?
> I believe that message was sent, and received. While the vendors are
> not quite where I would like them to be in terms of availability, I
> don't think sending more messages at this point is going to be
>> > Does the community feel there is value in arbitrarily setting a date to
>> > aid in setting a reasonable expectation of when vendors and providers
>> > need to be able to support 32 bit ASNs in a real way?
> I believe there is value in knowing the date, but it need not be
> arbitrary. For instance, 16 bit ASN's will run out in less than two
> years it would appear, which is a fairly well known date.
>> > Or is vendor support and provider support sufficiently advanced that is is
>> > no longer a concern?
> AFAIK, the vast majority of the vendors have working code at this point.
> The issue is that it may not be in all of the various forms they release
> code yet, but that is going to be a function of their release cycles and
> no amount of policy will change that.
>> > Does the community feel that removal of the date and giving out low
>> > numbered 32 bit ASNs will slow adoption of 32 bit ASNs as the "problem of
>> > needing to support 32 bit ASNs" will be out of sight and out of mind, and
>> > then suddenly and surprisingly re-emerge on some unknown date when the
>> > lowest valued 32 bit ASN clicks over that 16 bit boundary?
> I'm not sure I think it will surprisingly reemerge, as the run-out date
> is fairly well predicted, but it will re-emerge. From an ISP
> perspective, it only takes one customer needing this feature for you to
> have to go off and do the work to figure out what you need to do; so I
> don't think a short reprieve makes us really go backwards in terms of
> support. If anything, it may provide for a smoother transition as
> providers can roll out the code in normal cycles, rather than a router
> at a time as customers demand it.
>> > Does the community think there is value in being able to request a higher
>> > valued (over the 16 bit boundary) 32 bit ASN when smaller valued ASNs are
>> > available to allow providers to test and prepare for supporting 32 bit
>> > ASNs?
> This is the only area where I have some concern. I think folks should
> be able to show up and say "I want a 32 bit ASN" while there are 16 bit
> ones still in the free pool, be it for testing or because they want to
> leave 16 bit ones for those who need them.
> That said, all indications are that you could probably count the number
> of folks who would request and use 32 bit ASN's on one hand during the
> timeframe in question. Because of that I have my doubts it is worth the
> community, ac, board and staff time to pass a policy at this point. We
> do have many other issues on the table. :)
> Leo Bicknell - bicknell at ufp.org - CCIE 3440
> PGP keys at http://www.ufp.org/~bicknell/
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> Please contact info at arin.net if you experience any issues.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ARIN-PPML