[LACNIC/Politicas] Asignacion PI

[MARCELO BAGNULO BRAUN]

>
> Voy a sonar cinico y probablemente me gane enemistades,

lo dudo... estas discusiones son estrictamente profesionales, por lo 
que la amistad o la enemistas no pasa por lo que se diga en la lista.


> pero lo que veo
> es que aquellos que quieren direcciones PI buscan tener los mismos
> privilegios que en este momento estan reservados para los proveedores.

de acuerdo

el tema es que un isp agrega muchos clientes mientrras que una 
asignacion PI es un solo cliente

la agregacion y la escalabilidad en el sistema de rutas pasa por 
agregar informacion de muchos clientes en una sola entrada en la tabla 
de rutas, por ello la necesidad de las direcciones PI



> Me cuesta justificar que lo que es un derecho divino de los ISP no sea
> aceptable tambien para grandes usuarios finales.
>
> Y cortando la conversación corta porque se está alargando mucho
>
> - - Me parece que la solución implementada por ARIN y que comentó Roque es
> harto razonable. Designar un espacio específico para rangos PI. Y un /48
> es suficiente.

perfecto, entonces estamos de acuerdo en un /48

>
> - - (este punto es solo una cuestion de principios) Pero los dos
> argumentos principales para utilizar un /48 en lugar de un /32 son
> invalidas. Las tablas de enrutamiento no van a crecer más o menos
> dependiendo del tamaño del prefijo (es una sola entrada por prefijo

esta nunca fue una razon de las expuestas para no asignar un /32....


> hay alguna razón para suponer que el crecimiento de las tablas de
> enrutamiento globales IPv6 se van a comportar en forma distinta de lo
> que se comportan/comportaran las de IPv4? Y el desperdicio es aparente.
> Si hay unas 4 billones de /32 disponibles, cuantas creen que se van a
> consumir por PI? Cien mil? Doscientas? eso es todavia menos del 0.01% de
> las direcciones disponibles. Quien de uds. cuida celosamente en que han
> gastando el 0.01% de sus ingresos?

este razonamiento supone que las direcciones v6 son infinitas.... me 
imagino que al principio de v4 (cuando asignaban clases A a las 
universidades por ejemplo) pensaban lo mimso.... creo que deberiamos 
aprender de la historia y ser mucho mas prudentes esta vez.... no es 
razonable asignar un /32 simplemente porque _no_ lo necesitan y 
desperdiciar direcciones esuna muy mala idea


pero creo que ya estamos de acuerdo entonces....

saludos, marcelo

>
> - - Creo que la disponibilidad de rangos PI es condición necesaria pero no
> suficiente para la adopción masiva de IPv6.
>
>>
>> Ahora bien, la asignacion de un /32 implica un gasto adicional que debe
>> realizar la comunidad por estos usuarios, en particular debe asignarles
>> una cantidad desproporcionada de direcciones. simplemente no creo que
>> esto sea aceptable. Creo que los usuarios que obtenga bloques PI deben
>> obtener un /48  yque los isps que cobran a estos usuarios y que tienen
>> acuerdos con otros isps deben configurar sus filtros de forma adecuada y
>> no pedir que se invierta una cantidad enorme de direcciones en esto
>>
>> ademas, los bloques salen de un prefijo bien conocido reservado para
>> asignaciones PI, los filtros simplemetne tienen que decir que para este
>> bloque, aceptar prefijos mas largos....
>>
>> esto es lo que ha aceptado la gente de ARIN y parece funcionar para
>> ellos...
>>
>> no me gustaria ser participe en una escalada donde se le da mas a los
>> usuarios PI
>>
>> solo estoy de acuerdo en una politica PI para la region de lacnic porque
>> ARIN la ha aceptado y no me parece justo que la comunidad de lacnic
>> tenga qque pagar el costo de los usuarios PI de arin y no tener los
>> beneficios de los mismo, pero no creo que debamos poner mas costos de
>> estos sitios en la comunidad
>>
>>> En consecuencia, si bien los RIRs no tienen injerencia en que si el
>>> prefijo es ruteable o no, lo cierto es que los clientes de PI necesitan
>>> un prefijo que sea distribuido en las tablas de enrutamiento global, de
>>> lo contrario no soluciona nada.
>>>
>>
>> si, pero un /48 puede ser encaminado gloablmente
>>
>>>>> La asignación es básicamente "el prefijo mínimo necesario para que sea
>>>>> propagado con éxito en las tablas de enrutamiento global".
>>>>
>>>> no
>>>> el RIR no toma posicion sobre el potencial routeabilidad del prefijo
>>>> asignado
>>>
>>> el RIR no, pero el cliente quiere un prefijo que sea globalmente
>>> distribuido, aceptado por la mayoria de los ISP.
>>>
>>
>> si, tienen que negociar con los ISPs para que lo acepten
>> asi lo han hecho en arin
>>
>>
>>> Recuerda que el objetivo primordial de este tipo de políticas es
>>> impulsar la adopción de IPv6. Si la solución que ofrece el RIR realmente
>>> no se ajusta a las necesidades del usuario final que quiere ser
>>> multihomed y PI, lo que va a ocurrir es que el usuario final no va a
>>> adoptar IPv6.
>>>
>>
>> te parece entonces que cuando aceptemos una politica de este tipo en la
>> region de lacnic (o en arin) el despliegue de ipv6 va a
>> despegar?...interesante, ya hablaremos en un año...
>>
>>
>>> Ojo que no estoy proponiendo que se le de al usuario final todo lo que
>>> pida. Simplemente que reciba una solución práctica a sus problemas.
>>>
>>>>>  Si los ISP se
>>>>> niegan a aceptar prefijos menores a un /32 para evitar una explosión de
>>>>> las tablas de enrutamiento, todas aquellas organizaciones/instituciones
>>>>> que necesiten PI necesitan un /32.
>>>>>
>>>> pero esto no tiene nada que ver con que la asignacion sea un /32 o un
>>>> /48, sino con el numero potencial de sitios multihomed....
>>>>
>>>>>  Si asumimos que el número de
>>>>> instituciones que requieren direcciones PI es acotado, las entradas en
>>>>> las tabla de enrutamiento asociadas a estas instituciones son acotadas
>>>>> tambien.
>>>>
>>>> si, independientemete que se les asigne un /32 o /48
>>>>
>>>>> La otra alternativa es simplemente que estas instituciones no
>>>>> adopten IPv6, que todos estamos de acuerdo no es deseable.
>>>>>
>>>>
>>>> y la otra alternativa, es que los ISPs propaguen y acepten estos /48 que
>>>> provienen de un prefijo conocido para asignaciones PI
>>>>
>>>> porque? porque los sitios multihomed con PI estan dispuestos a pagar por
>>>> este servicio
>>>
>>> Totalmente de acuerdo. Y ese es el punto que he tratado de aclarar. El
>>> factor determinante no es el tamaño del prefijo "per se" (sigue siendo
>>> una sola entrada en las tablas de enrutamiento globales,
>>> independientemente de que sea una ruta a un /32 o a un /48), sino cual
>>> es el tamaño mínimo que se puede esperar razonablemente que sea aceptado
>>> en las tablas de enrutamiento globales.
>>>
>>
>> eso es configurarble, especialmente si sale de un refijo reservado para
>> prefijos mas largos
>>
>>> Si hoy en día la mayoria de los enrutadores aceptan rutas a prefijos /48
>>> (y es razonable esperar que las sigan aceptando), entonces un /48 es
>>> suficiente. Pero si la mayoria de los enrutadores solo aceptan prefijos
>>> /32 y más grandes, entonces el tamaño del prefijo PI tiene que ser /32.
>>>
>>
>> claro porque la politica hoy es que no se podian hacer asignaciones /48
>> y el modelo era bloques PA /32
>>
>> cuando se acepte una politica de este tipo, los encaminadores aceptaran
>> /48 (sobre todo si vienen de un prefijo conocido)
>>
>> digo antes aseptaban /35 ahora /32 y con esta politica aceptaran /48...
>> no hay ningun problema con esto, solo configurar filtros
>>
>> digo el problema real es si en algun momento las tablas explotan,
>> entonces los ISPs necesitan empezar a filtrar porque no tienen la
>> capacidad de almacenar toda las tabla de rutas, entonces empezaran al
>> usar filtros.
>>
>> en este caso puede ser que no acepten /48
>>
>> pero en esta situacion me parece bien que se filter los usuarios PI y se
>> acepten los bloques PA... al final los usuarios de bloque PA estan
>> haciendo un esfuerzo adicional para asegurar la escalabilida del sistema
>> de rutas y los usuarios PI no lo estan haciendo, por lo que parece justo
>> que si la red no puede escalar mas, sean los usarios que mas contribuyen
>> al problema los primero damnificados, no?
>>
>>> Yo no tengo acceso a tablas de enrutamiento globales en IPv6, y hace
>>> unos 3 meses pregunté (en esta misma lista) a aquellos que trabajan en
>>> ISP cual es la política implementada actualmente y la tendencia a
>>> futuro, y no obtuve respuesta. Por lo tanto yo no puedo hacer una
>>> recomendación sobre el tamaño de prefijo específico, sinó que mi opinion
>>> depende de la política actual de los ISP.
>>>
>>
>>
>>>>> Como digo al principio (y como dije hace varios mes
>>>>> es), yo prefiero que
>>>>> la asignación sea un /48, siempre y cuando el prefijo se propague en
>>>>> las
>>>>> tablas de enrutamiento globales.
>>>>
>>>> pregunta: crees que los /48 PI asignados por ARIN no van a ser
>>>> encaminados?
>>>
>>> no sabia que ARIN estaba asignando /48, así que no puedo creer nada al
>>> respecto. Asumiendo que efectivamente ARIN está asignando /48 y
>>> asumiendo tambien que ARIN está mejor informado que yo como se estan
>>> manejando las tablas de enrutamiento global, entonces creo que si van a
>>> ser ruteados los /48.
>>>
>>
>> ok, perfecto, entonces no hay problema con el /48 entonces?
>>
>> saludos, marcelo
>>
>>
>>> --
>>> Juan Nicolás Ruiz        | Corporación Parque Tecnológico de Mérida
>>> Investigación/Desarrollo | Centro de Tecnologias de Información
>>> nicolas at ula.ve           | Edif B (Fac. Ingeniería) Nivel Plaza, Ala Sur
>>> +58-(0)274-240-3889      | La Hechicera, Mérida - Edo. Mérida. Venezuela
>>>
>>
>>
>>
>
> - --
> Juan Nicolás Ruiz        | Corporación Parque Tecnológico de Mérida
> Investigación/Desarrollo | Centro de Tecnologias de Información
> nicolas at ula.ve           | Edif B (Fac. Ingeniería) Nivel Plaza, Ala Sur
> +58-(0)274-240-3889      | La Hechicera, Mérida - Edo. Mérida. Venezuela
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFEa2XsmjsZS9ZBxv8RAsKZAKCFUm/xzkyzyn41ARLXWZMqKN7RewCfUs1L
> rCPZpIcTXtxnQmsICUo5B3A=
> =BW5w
> -----END PGP SIGNATURE-----
>
>



-- 
----
MARCELO BAGNULO BRAUN
WebCartero
Universidad Carlos III de Madrid