[LACNIC/Politicas] Consulta
Nicolas Antoniello
nantoniello at gmail.com
Thu Nov 25 18:34:17 BRST 2010
<chair hat> = off;
Estimados,
Este problema de definir que métrica se adapta mejor a la asignación de
direcciones IPv6 es algo que creo que aún no está claro ni definido del
todo.
En ARIN por ejemplo, está en discusión la propuesta
https://www.arin.net/policy/proposals/2010_8.html que justamente (si no
interpreté mas las cosas) habla de utilizar porcentajes para medir
eficiencia, en lugar del HD.
Entiendo que es un problema de mucha actualidad y sería bueno volver a
analizar entre todos una propuesta de métrica que se adecue a IPv6.
Debemos tener en cuenta que los paradigmas de utilización y uso del espacio
de direcciones IPv4, no son necesariamente válidos para IPv6... el
considerar un HD a partir de una RFC del año 2001 que menciona direcciones
de hasta 32 bits, con paradigmas de asignación, utilización y eficiencia
útiles para un espacio de tal tamaño, no necesariamente aplica hoy a un
esquema de 128 bits, donde aún discutimos si lo mejor es asignar a un
cliente residencial un /56 y a uno empresarial un /48, más o menos que eso.
Pero era totalmente válido considerarlo en su momento y así lo entendió la
comunidad (basado además en los escasos casos prácticos de despliegue de
IPv6 en ese entonces).
Por otro lado, el problema de la "reserva" a nivel de ISPs para evitar luego
tener bloques fragmentados en las redes internas (por no prever o no tener
espacio para prever) responde al hecho de que inevitablemente tenemos que
seguir algún criterio de asignación (por parte de los RIR) y algún criterio
a la hora de armar el plan de direccionamiento de las redes (por parte de
los ISPs y usuarios en general), sin tener aún definida cual es la
asignación mínima o "recomendable" para usuarios finales, empresas, grandes,
pequeños y medianos clientes... temas aún en discusión y de opiniones
bastante variadas en la comunidad. Ese es el desafío y es inevitable
afrontarlo SIN tener aún el resultado final... el tiempo y la historia
contarán luego si los criterios, métricas y recomendaciones hechas fueron
felices o no... :) Para eso existen estos foros, estas y otras instancias
de discusión, justamente, para ser dinámicos y adaptarnos a los cambios que
las tecnologías y la realidad actual requieran.
Saludos,
Nicolas
2010/11/25 Carlos G Mendioroz <tron at huapi.ba.ar>:
> Carlos,
> dije "alegre imposición" haciendo referencia a algo que refleja lo que por
> ahora creo que es lo que los psicólogos llaman transferencia,
> en alusión a una frase cortita de Arturo: "Lo cual es muy poco"
> (acerca del 10% de utilización).
>
> El objeto de mi interés es entender la razón del cambio. Todavía no
entiendo
> el fundamento así que lejos estoy de creer que está mal.
> Cuanto mucho, creo que está mal dooumentado porque en donde figura
> no hay referencias directas a la razón, pero Arturo ha sido muy
> diligente en compartirlas.
>
> De hecho, toda mi curiosidad surgió de un argumento de un ISP donde
> explica que con la política actual vamos a tener mucha fragmentación
> y eso no parece ser bueno. De hecho, dado que tenemos direcciones como
> para ponerle a cada grano de arena del Sahara, no entiendo por qué
> tanta insistencia con la eficiencia de uso... pero bue, aunque sea
> trato de entender un poco.
>
> -tron
>
> Carlos Martinez-Cagnazzo @ 25/11/2010 9:45 -0300 dixit:
>>
>> Carlos,
>>
>> solo quiero aclarar que en estas cosas no hay imposiciones, de hecho
estas
>> cosas fueron aprobadas en el Foro de Politicas.
>>
>> Si te parece que es incorrecto, admite mejoras, etc, el camino para
>> modificarlo es justamente volver a recorrer el proceso de desarrollo de
>> politicas.
>>
>> saludos
>>
>> Carlos (Martinez)
>>
>> 2010/11/24 Carlos G Mendioroz <tron at huapi.ba.ar>
>>
>>> TODO el tema se basa en que alguien sacó el galerazo de que 10% de uso
>>> de un espacio de cierto tamaño es muy poco.
>>> Pero lo que traté de argumentar en términos llanos es que JUSTAMENTE
>>> la línea de pensamiento de las RFCs en la que se basa el punto es que
>>> NO TIENE SENTIDO pensar en porcentajes!
>>>
>>> Tu "alegre" imposición de que el 10% de uso es muy poco no tiene en
>>> cuenta, por ejemplo, las reservas para crecimiento que un ISP debería
>>> hacer para que una eventual asignación posterior no genere
fragmentación.
>>>
>>> Mi duda es de donde salió el argumento de que 10% es poco. Y si quien
>>> quiera que lo propuso entiende el argumento de las RFCs que
>>> supuestamente son la base del uso de HD.
>>>
>>> -tron (mi viejo y fiel alias que ahora se pondrá de moda nuevamente :)
>>>
>>> Arturo Servin @ 24/11/2010 21:54 -0300 dixit:
>>>>
>>>> Carlos,
>>>>
>>>> No se si estoy entiendo tu duda.
>>>>
>>>> El cambio de 0.80 a 0.94 es por lo siguiente (de acuerdo a lo que
>>>
>>> entiendo):
>>>>
>>>> Si usas 0.80 como medida para justificar nuevo espacio de IPv6,
>>>
>>> requieres solamente haber asignado 6500 /48s (de acuerdo a la política,
>>> de
>>> acuerdo a mis cálculos son 7, 132 pero igual me equivoco) de los 65536
>>> que
>>> tiene un /32. Lo cual es muy poco.
>>>>
>>>> En cambio, si usas un HD de 0.94 para pedir más espacio requieres
>>>
>>> haber asignado 33689 /48s, que es un poco más de la mitad.
>>>>
>>>> Te mando una tabla de excel que hice con varios HDs y los
>>>
>>> porcentajes de eficiencia en IPv4 e IPv6.
>>>>
>>>> Saludos,
>>>> -as
>>>>
>>>>
>>>>
------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 24 Nov 2010, at 17:37, Carlos G Mendioroz wrote:
>>>>
>>>>> Arturo,
>>>>>
>>>>> juro que no entiendo el tema del HD @ 0.94
>>>>>
>>>>> Este es mi análisis:
>>>>>
>>>>> -Primero, RFC1715, Huitema hace un análisis de como muchas redes
>>>>> que comparten el hecho de estar segmentadas artificialmente logran
>>>>> una utilización no obvia del espacio de direcciones.
>>>>> Mantiene que la percepción de uso por porcentaje del espacio completo
>>>>> es engañoso, y que una mejor métrica es el coeficiente H,
>>>>> que usa una relación logarítmica. Finalmente muestra que la capacidad
>>>>> de varias redes efectivamente comparten valores similares de H,
>>>>> por lo que propone H como métrica de uso apropiado.
>>>>>
>>>>> -Luego, RFC3194, cambia a HD, una relación entre 2 logarítmos con lo
>>>>> que
>>>>> se independiza de la base y lleva a numeros más facilmente manejables.
>>>>> (aunque no necesariamente más entendibles para el que no sigue el
>>>>> argumento).
>>>>> Luego de un análisis variado cataloga los valores de HD como
>>>>> razonable (.80) molesto (.85) muy molesto (.86) y máximo práctico
(.87)
>>>>>
>>>>> -La asignación de IPv6 había originalmente usado el esquema con HD=.86
>>>>> para justificar asignaciones subsiguientes al /32 inicial, medida en
>>>>> uso de /48s (o /56s ?) pero cambió a HD=.94.
>>>>>
>>>>> Acá lo que no me cierra: el cambio parece estar justificado en el
pobre
>>>
>>> uso de las direcciones cuando se lo exresa en porcentaje!
>>>>>
>>>>> Que es lo que el origen de todo este esquema de medición dice que es
>>>>> un mal sistema de percepción de uso apropiado!
>>>>>
>>>>> Que me perdí ?
>>>>>
>>>>> Como si esto fuera poco, después de haberle dado un par de vueltas al
>>>
>>> asunto, no logro entender el párrafo de justificación del documento
>>>>>
>>>>> que mandaras:
>>>>>
>>>>>> Si tomamos en cuenta que la asignación inicial establecida por la
>>>>>> política es un /32, y si para hacer una nueva
>>>>>> asignación al mismo LIR utilizamos un HD Ratio de 0.8, se satisface
>>>>>> el
>>>>>> umbral de evaluación de utilización histórica de
>>>>>> direcciones con una utilización eficiente del 10,9% (alrededor de
>>>>>> 6500
>>>>>> utilizados de los 65536 /48s disponibles en un
>>>>>> /32. Si aplicáramos el mismo valor a un /20, la utilización
eficiente
>>>>>> cae a un 2,1%.
>>>>>>
>>>>>> Por consiguiente se propone que se cambie el valor del HD Ratio de
>>>>>> 0.8
>>>>>> a 0.94, de manera de aumentar los niveles de eficiencia.
>>>>>>
>>>>> Alguien puede ayudarme a entender esto ?
>>>>>
>>>>> Muy agradecido de antemano,
>>>>> --
>>>>> Carlos G Mendioroz <tron at huapi.ba.ar> LW7 EQI Argentina
>>>>> _______________________________________________
>>>>> 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
>>>
>>> --
>>> Carlos G Mendioroz <tron at huapi.ba.ar> LW7 EQI Argentina
>>> _______________________________________________
>>> Politicas mailing list
>>> Politicas at lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>
>>
>>
>>
>
> --
> Carlos G Mendioroz <tron at huapi.ba.ar> LW7 EQI Argentina
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
>
More information about the Politicas
mailing list