[LACNIC/Politicas] consulta politica global ASN

Wed Jun 4 17:15:35 BRT 2014

Creo que el problema no son los ASN de 16 bits, si no los de 32 bits que no
hay muchos en el stock de LACNIC y no puede pedir más a IANA hasta que
asigne un buen porcentaje de los de 16 bits.

Slds
as

2014-06-04 13:03 GMT-07:00 Fabián Mejía <ing.fabianmejia at gmail.com>:

> Hola
>
> Lo que debería decir la propuesta de política es básicamente los criterios
> que está aplicando ahora el staff de LACNIC, solo que ahora estarían
> escritos en el manual y más bien les ayuda a no entregar por defecto un ASN
> de 16 bits a alguien que puede usar uno de 32, motivados por el hecho de
> que no se puede solicitar más recursos a IANA.
>
> La pregunta para el staff de LACNIC sería:  ¿cuantos ASN de 16 bits hay en
> el stock de LACNIC, hoy? y ¿cuales son las estadísticas de asignación de
> ASN de 16 bits por año desde que entró en vigencia la política global de no
> diferenciar?, con ello se tiene una mejor base para analizar/discutir si
> conviene o no crear el pool y qué cantidad sería bueno reservar.  Cualquier
> cosa que exceda el pool de reserva (de existir) puede ser asignado
> inmediatamente aunque sea de 16 bits.
>
>
> Saludos,
>
> Fabián Mejía
>
> El 2014-06-04 14:31, Matias Niosi escribió:
>
>  Estoy de acuerdo con Juan.
>>
>> Qué pporcentaje de utilización de ASNs hay hoy en LACNIC? Qué parte de
>> ellos son del 0 al 65536?
>>
>> Slds.
>>
>>
>>
>>
>> El 4 de junio de 2014, 16:28, Juan Alejo Peirano <
>> juan.alejo.peirano at gmail.com> escribió:
>>
>>  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
>>>>
>>>>  _______________________________________________
>>> 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
>