[LACNIC/Politicas] Asignacion PI

[marcelo bagnulo braun]

El 15/05/2006, a las 18:27, Nicolás Ruiz escribió:

> Hola a todos:
>
> marcelo bagnulo braun wrote:
>
>> claro pero en el caso del 6bone, la obtencion de direcciones nuevas
>> producia beneficios, en el sentido que el 6bone era una eestrucutra de
>> exprimentacion y las direcciones nuevas eran de produccion... digo 
>> creo
>> que las institiciones en el 6bone no utilizaban esta red como 
>> produccion
>> sino para hacer prubas...
>>
>> esto es un caso completamente diferente, ya que estas asignaciones PI
>> son exactamente para poner en produccion sitios grandes que ya son
>> multihomed en v4 y que quieren poner en produccion sus servicions en 
>> v6.
>> las implicaciones de un evento de renumeracion en ambos casos son muy
>> diferentes...
>
> Personalmente yo no lo veo tan diferente (y en este caso estamos
> especulando porque todos estamos hablando de situaciones futuras), pero
> si en un futuro se decide desincorporar los prefijos PI asignados 
> porque
> hay una solución alternativa, existen beneficios para la renumeración.
>

de acuerdo...
pero una solucion alternativa a que problema?
para el problema de site multihoming ya hay una solucion alternative 
shim6. El tema es que esta solucion no brinda direccciones PI, por lo 
que los usuarios tienen que renumerar cuando cambian de proveedor, por 
lo que para algunos esto es inaceptable.

El tema es que para algunos usuarios, el objetivo real es tener 
direcciones PI y punto. para ellos no hay solucion alternativa que 
valga, ya que no buscan tolerancia a fallos o ingenieria de trafico, 
sino que lo que buscan es su propio bloque de direcciones y no depender 
de un proveedor. en ese caso, va a ser muy dificil de converlos que una 
solucion alternativa que brinda tolerancia a fallos, ingenieria de 
trafico no sera suficiente, ya que lo buscan es otra cosa, 
independencia del proveedor....

>>> Estoy totalmente de acuerdo en no desvirtuar el concepto del LIR. 
>>> Pero
>>> yo tendria cuidado al indicar que un LIR ha de *vender* tránsito. 
>>> Esa es
>>> una restricción innecesaria.
>>
>> bueno, debe proveer transito a otras insituciones, y en general hay
>> algun tipo de venta de transito (solo que los modelos de pago pueden
>> diferir, com por ejemplo las redes academicas, donde el pago es mucho
>> mas indirecto)
>
>
>>> La existencia de los filtros es precisamente la razón que fuerzan a 
>>> que
>>> se asigne un /32. Si se otorga un /48 y el prefijo no se propaga en 
>>> las
>>> tablas de enrutamiento, la asignación no es PI.
>>
>> creo que no tenemos las misma definicion de PI....
>> La asignacion es PI porque no proviene del bloque asignado a uno de 
>> los
>> proveedores del sitio y proviene directamente del RIR
>>
>> Ser o no ser PI no tiene absolutamente nada que ver con el hecho de 
>> que
>> sea routeable o no
>>
>> en mas, los RIRs no tienen ninguna influencia sobre si los prefijos 
>> son
>> routeables en internet o no. Lor rirs, nos hacen ningun tipo de
>> declaracion sobre la potencial routeabilidad de los prefijos
>
> Estas en lo correcto, un prefijo es PI porque lo asigna directamente el
> RIR en lugar del ISP, no tienen nada que ver con que los prefijos sean
> globalmente ruteables y los RIRs no tienen influencia en la 
> ruteabilidad
> de los prefijos.
>
> Pero como tu mismo mencionas más abajo, los "usuarios" más comunes de
> prefijos PI son aquellas redes que son multihomed, y que si obtienen un
> prefijo de usuario final del proveedor A, se les hace dificil llegar a
> un acuerdo con el proveedor B para que publique dicho prefijo en sus
> tablas de enrutamiento, sobre todo si el tamaño del prefijo asignado 
> por
> A, aunque suficiente para las necesidades del usuario, es más pequeño
> que el tamaño mínimo usualmente aceptado por los ISP para redistribuir
> en sus tablas de enrutamiento. Yo lo se bien porque lo he vivido.
>
> Ergo, si bien técnicamente hablando PI no tiene nada que ver con
> multihoming, la realidad es que aquellos que desean (deseamos) PI lo
> quieren principalmente para facilitar/habilitar multihoming, más que
> para evitar renumeraciones a futuro.
>

puede ser cierto en tu caso, pero esto no son los argumentos que 
esgrimen los defensores de este tipo de politicas

shim6 provee soporte a los sitios multihomed y les brinda tolerancia a 
fallos e ingenieria de trafic (esto ultima de una forma diferente, pero 
no es evidente que sea inferior)

sin embargo, esto no es sufiente ya que lo que quieren es independencia 
del proveedor

> Por lo tanto el prefijo PI asignado debe ser un prefijo lo
> suficientemente grande (o pequeño) para que el prefijo sea publicado
> globalmente, sin tener que pasar por un viacrucis cada vez que se
> negocia un contrato con un nuevo ISP.
>

el tema yo lo veo asi:

el uso de una solucion PI impone que las tablas globales de rutas de 
internet tengan una entrada adicional por cada sitio que tiene una 
asignacion PI. Esto implica que _toda_ la comunidad de internet tiene 
que pagar el precio de que _algunos_ sitios sean multihomed (este 
problema es conocido como la tragedia de los communes, el uso abusivo 
de bienes publicos)en este punto, parece ser que un grupo de usuarios 
han logrado convencer al resto que acepten esta situacion

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
>