[LACNIC/Politicas] consulta politica global ASN

Juan Alejo Peirano juan.alejo.peirano at gmail.com
Wed Jun 4 16:28:50 BRT 2014


Estima at s,

Respecto a la propuesta de Fabián, en un primer momento tenía mis dudas
respecto a generar una reserva, para no condicionar en el futuro el trabajo
de los Hostmsters  cuando la situación no sea tan crítica, pero en vista de
los tiempos que se manejan y la necesidad por parte de la comunidad de
LACNIC de disponer de ASNs de por encima de 65535 para asignar y "cuidar "
un poco mas los que se encuentran por debajo de  65535, apoyo la idea de
Fabián Mejía  .Si fuera posible consultarle  al Staff de LACNIC el impacto
(en particular negativo si lo hay) que puede tener la creación de esta
reserva, puramente desde el punto de vista operativo.

Saludos!

Juan


El 4 de junio de 2014, 15:13, Fabián Mejía <ing.fabianmejia at gmail.com>
escribió:

> Hola a todos
>
> Primero, gracias Ricardo por poner sobre la mesa este tema.
>
> Coincido con Juan que en vista de lo largo que puede resultar alcanzar
> consenso en una política global, el punto a poner atención sería:  la
> interpretación de "necesidad" en IANA.
>
> Por otra parte, puede ser también conveniente mantener una reserva
> "adecuada" de ASN de 32 bits con 16 ceros al inicio (acogiendo la
> recomendación de Jorge Villa).
>
> Por lo tanto, me parece que el camino puede ser proponer una política en
> LACNIC que cree una reserva de dichos ASN, que se pueden asignar solo en
> los casos especiales (no por defecto), con ello asumo que si LACNIC no
> puede asignar de ese pool, NECESITA que IANA le asigne otro rango.
>  Estonces todo estaría más claro.
>
> ¿Qué opinan?.
>
> Saludos,
>
> Fabián Mejía
> AEPROVI
>
> El 2014-06-04 12:05, Juan Alejo Peirano escribió:
>
>> Ricardo, tenes razón, pido disculpas por la mala interpretación de tu
>> correo.
>>
>> Y con la correcta (espero) interpretación de tu correo, me gustaría
>> reformular algunas ideas.
>> - El proceso por el cual esta política debe ser modificada es el de
>> Política Global, como menciona Ricardo. Esto hace que los tiempos para
>> alcanzar consenso en todas las regiones y luego pasar por el ASO y
>> finalmente por el Board de ICANN para ser ratificada, sean mas largos de
>> lo
>> que supondría un nuevo pedido a IANA al alcanzar el 80% de utilización
>> total.
>>
>> Mas alla que veo  sumamente importante tratar de conseguir ASNs por encima
>> de 65535 (32 bits) lo antes posible, creo que el camino de modificación
>> como política global no sería el adecuado, a no ser que ya hubiese
>> consenso
>> por este tema en los otro 4 RIRs y se pudiera resolver todo en el próximo
>> semestre del 2014 (si alguien tiene información respecto a esto me
>> encantaría saberlo)
>>
>> Dado que LACNIC asigna ASNs por encima de 65535 por omisión a nos ser que
>> se justifiquen carencias tecnológicas que solo permitan utilizar un ASN de
>> 16 bits ¿cual es la interpretación de " necesidad" que aplica IANA en el
>> punto 9.4.3 ?
>>
>>     - El número de ASNs libres actualmente en poder del RIR es menor que
>> la
>>
>>     NECESIDAD proyectada para 2 meses. La proyección se basa en el número
>>     promedio de ASNs asignados por el RIR durante los 6 meses precedentes.
>>
>>
>> Se puede justificar la "necesidad" de numero altos de ASNs? Creo que si
>> utilizamos el promedio de ASNs de 32 bits entregados se podría justificar
>> la necesidad, ya que mayoritariamente se entregan ASNs de 32 bits (por
>> encima de 65535) , pero de nuevo, todo depende de la interpretación de
>> IANA
>> del concepto de necesidad
>>
>> Saludos
>>
>> Juan
>>
>>
>> El 4 de junio de 2014, 13:07, Ricardo Patara <patara at registro.br>
>> escribió:
>>
>>  Estimados,
>>>
>>> Mis disculpas si mi consulta no fue clara.
>>>
>>> @Juan, la política global *ya no hace* distinción entre ASNs 16 y 32
>>> bits.
>>>
>>> La consulta es si la comunidad está de acuerdo en seguir así. O si
>>> debido al escenario diferente de lo que se imaginaba cuando se propuso
>>> esa política, cambiar el texto para que *sí* se haga distinción.
>>>
>>> Eso implica en una política global que hay que discutir y pasar en los 5
>>> RIRs.
>>>
>>> Y también hay que aclarar que dentro en poco LACNIC no tendrá más ASNs
>>> 32 bits en su estoque con lo que no podrá, como sugerido, asignar 16
>>> bits solamente a quién lo solicite (ese es el procedimiento actual, pero
>>> desde que haya ASNs 32 bits).
>>>
>>> Saludos
>>>
>>> Ricardo Patara
>>>
>>> On 06/04/2014 12:50 PM, villa at reduniv.edu.cu wrote:
>>>
>>>> Hola a tod at s, como estan?
>>>>
>>>> Creo que hay dos partes del problema. Uno referente a terminologia y
>>>> otro referente a operacion.
>>>>
>>>> En realidad todos los ASN son numeros de 32 bits; solo que hay un grupo
>>>> que tienen los primeros 16 bits en cero (del 0 al 65536) y por razones
>>>> historicas se les dice "de 16 bits"; pero no es correcto hacer
>>>> diferenciacion formal, que en algunos casos puede incluso llevar a
>>>> errores conceptuales.
>>>>
>>>> Desde el punto de vista de operacion, la principal razon de pretender
>>>> emplear numeros de los llamados "de 16 bits" es para satisfacer a
>>>> operadores con equipamiento obsoleto que no admiten el manejo de los 32
>>>> bits completos del ASN, y concuerdo con Juan Peirano en que cada vez son
>>>> menos los equipos en esta situacion. Incluso, me parece que pudiera
>>>> haber mas necesidad de estos ASN en los End-Users que en los ISP.
>>>> Paradojicamente, donde mayor demanda hay de estos AS de 16 bits en la
>>>> region de ARIN. Yo creo que seria interesante tener una resreva para
>>>> esos casos extremos, y como regla general, asignar de 32 bits y
>>>> documentar todo con de 32 bits.
>>>>
>>>> Saludos,
>>>> Jorge
>>>>
>>>> -----Original Message----- From: Dario Tuseddu
>>>> Sent: Wednesday, June 4, 2014 11:46 AM
>>>> To: politicas at lacnic.net
>>>> Subject: Re: [LACNIC/Politicas] consulta politica global ASN
>>>>
>>>> Buenos días,
>>>>
>>>> Creo que es importante asignar por default ASN de 32 bits, y solo en el
>>>> caso que el usuario puede demostrar la necesidad del ASN de 16 bits
>>>> cambiarlo, hoy el común denominante de los dispositivos disponibles
>>>> pueden utilizar ASN de 32 bits o en su defecto disponen de métodos de
>>>> transición
>>>>
>>>> Saludos!
>>>>
>>>>
>>>> Dario Tuseddu
>>>>
>>>>
>>>> On 6/4/14 12:41 PM, Jhonder Depablos wrote:
>>>>
>>>>> Hola compañeros, estoy muy deacuerdo con Luis y Juan Alejo, sin embargo
>>>>> debe limitarse un rango de reserva y condiciones restrictivas para su
>>>>> asignacion cuando ya estemos en el area de reserva.
>>>>>
>>>>> Saludos
>>>>> El 04/06/2014 11:04, "Juan Alejo Peirano" <
>>>>> juan.alejo.peirano at gmail.com
>>>>> escribió:
>>>>>
>>>>>  Estimad at s,
>>>>>>
>>>>>> Creo que sería interesante realizar la modificación para que NO haya
>>>>>> distinción entre los ASN de 16 y de 32 bits a la hora de realizar la
>>>>>> asignación por parte de IANA.
>>>>>>
>>>>>> En nuestra región hemos tenido una muy buena "aceptación" (por asi
>>>>>> decirlo)
>>>>>> de ASNs de 32 bits y es importante continuar con la asignación de los
>>>>>> mismos y que no se entreguen ASNs de 16 bits por falta de los
>>>>>> anteriores.
>>>>>>
>>>>>> Concuerdo con Luis de que la mayoría de los equipos ya soportan ASNs
>>>>>> de 32
>>>>>> bits, otra razón por la cual la distinción creo que carece de sentido.
>>>>>>
>>>>>> Saludos!
>>>>>>
>>>>>> Juan Alejo Peirano
>>>>>>
>>>>>>
>>>>>> El 4 de junio de 2014, 11:34, Ricardo Patara <patara at registro.br>
>>>>>> escribió:
>>>>>>
>>>>>>  La política global para asignación de ASN por IANA a los RIRs
>>>>>>> implementada en 2010 indica que a partir de 1er de enero 2011 IANA
>>>>>>> dejaría de hacer distinción entre ASNs de 16 y de 32 bits.
>>>>>>>
>>>>>>> Las asignaciones de IANA a los RIRs pasó a ser de rangos de ASNs que
>>>>>>> podrían ser menores o mayores a 65535 sin distinción.
>>>>>>>
>>>>>>> Y para el RIR obtener ASNs adicionales ha que demostrar utilización
>>>>>>> de
>>>>>>> al menos 80% del rango ya asignado, y nuevamente sin distinción.
>>>>>>>
>>>>>>> Algunos RIRs, incluyendo LACNIC, han asignado más ASN mayores a 65535
>>>>>>> por defecto. Y han reservado los menores a 65535 para redes que
>>>>>>>
>>>>>> todavía
>>>
>>>> no soportan los de numero mayor a 65535.
>>>>>>>
>>>>>>> Pero pasa que estos ASN de numero mayores a 65535 se están agotando
>>>>>>> en
>>>>>>> LACNIC y por eso se está asignado los menores mismo a "redes" que
>>>>>>> soportan y podrían utilizar los de numero mayor.
>>>>>>>
>>>>>>> Eso asta que se pueda justificar ASNs adicionales.
>>>>>>> La proyección de LACNIC para poder justificar asignación adicional de
>>>>>>> ASN es para inicio de 2015.
>>>>>>>
>>>>>>> En otras regiones, en especial la de ARIN, pasa lo contrario.
>>>>>>> Proveedores allá han solicitado más ASNs menores a 65535 y una vez
>>>>>>> que
>>>>>>> se agoten estos numeros, ARIN pasará a asignar los mayores a 65535.
>>>>>>>
>>>>>>>
>>>>>>> La consulta a la comunidad es acerca de la no distinción por parte de
>>>>>>> IANA a estos dos "grupos" de ASN como indica la política.
>>>>>>>
>>>>>>> Piensan que hay que proponer ajustes a la misma?
>>>>>>>
>>>>>>> Y hay que recordar que el "estoque" de ASNs menores a 65535 junto a
>>>>>>> IANA
>>>>>>> es de aproximadamente 500 ASNs.
>>>>>>>
>>>>>>>
>>>>>>> Saludos
>>>>>>> --
>>>>>>> Ricardo Patara
>>>>>>> _______________________________________________
>>>>>>> Politicas mailing list
>>>>>>> Politicas at lacnic.net
>>>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>>>>
>>>>>>>  _______________________________________________
>>>>>> Politicas mailing list
>>>>>> Politicas at lacnic.net
>>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>>>
>>>>>>  _______________________________________________
>>>>> Politicas mailing list
>>>>> Politicas at lacnic.net
>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>>
>>>> _______________________________________________
>>>> Politicas mailing list
>>>> Politicas at lacnic.net
>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>
>>>>
>>>> Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu
>>>>
>>>>
>>>>
>>>>
>>>> Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Politicas mailing list
>>>> Politicas at lacnic.net
>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>
>>> _______________________________________________
>>> Politicas mailing list
>>> Politicas at lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>
>>>  _______________________________________________
>> Politicas mailing list
>> Politicas at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/politicas
>>
>
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
>



More information about the Politicas mailing list