[LACNIC/Politicas] Pol í tica de publicaciones de bloques IPv6 (propuesta para modificacion de politica)

[JORDI PALET MARTINEZ]

Hola Rooque,

Contesto entre lineas.

Saludos,
Jordi




> De: Roque Gagliano <rgaglian at antel.net.uy>
> Responder a: <rgaglian at antel.net.uy>
> Fecha: Sun, 18 Mar 2007 19:30:56 -0300
> Para: <jordi.palet at consulintel.es>, LACNIC Policy mailling list
> <politicas at lacnic.net>
> Asunto: Re: [LACNIC/Politicas] Pol í tica de publicaciones de bloques IPv6
> (propuesta para modificacion de politica)
> 
> Contesto entre líneas....
> 
>> 
>> Creo que no lo he confundido. No me estoy refiriendo a prefijos mas
>> pequeños
>> de /32 (en realidad mas largos, bloques de direcciones mas
>> pequeños), sino
>> al texto propuesto por Nicolas, asunto que ya comentamos
>> anteriormente en la
>> lista.
>> 
> 
> Bien. Era sólo para aclarar que estamos viendo el mismo tema.
> 
>>> 
>>> Cuanda hay un BCP que resuelva el problema, podemos simplemente
>>> referenciarlo como hemos hecho en otros casos. Por ahora no lo hay y
>>> no podemos desde una política hacerlo.
>> 
>> Lo logico es trabajar en ese BCP en IETF (y de hecho hay un
>> documento en
>> curso al respecto en v6ops), asi que lo suyo es contribuir a ese
>> documento y
>> si la conclusion es que hay que cambiar la politica, pues se cambia
>> una vez
>> que IETF haga una recomendación al respecto, pero hoy por hoy, la
>> recomendación es no romper la agregacion (no realizar anuncios
>> desagregados).
>> 
>> Si un ISP desda romper la agregacion, como de hecho ya lo hacen
>> algunos,
>> nadie le va a impedir que lo haga, y sera la comunidad la que
>> decida, bien
>> mediante la exigencia de la aplicación rigurosa de la politica, o
>> bien el
>> mercado (el filtrado de las desagregaciones, como asi ya ocurre a
>> algunos).
>> 
>> En casi todas las politicas hay facetas que los RIRs no aplican
>> estrictamente, y me parece logico hasta cierto punto, pero creo que
>> se deben
>> de mantener como medida de seguridad, porque nos permite controlar
>> el uso de
>> los recursos. Y como recursos aquí tambien me refiero a los slots
>> en las
>> tablas de routing, que tienen un coste en cierto modo oculto que
>> pagamos
>> TODOS los que tenemos BGP. Sin embargo, cuando un ISP desagrega, no
>> compensa
>> por ello a todos los demas, verdad ? Hasta que punto es eso
>> logico ? Yo
>> diria que es logico siempre y cuando no este suponiendo un
>> incremento de
>> coste "notable" al resto de los participantes de la red, pero si se
>> produce
>> una explosion y por ello llegamos a tener 100.000 entradas nuevas de
>> routing, debe de pagarse por ello, y esta politica permite que si
>> no se
>> logra "cobrar" ese perjuicio, se pueda exigir su aplicación.
>> 
> 
> Estoy totalmente de acuerdo que el IETF es el ámbito para lograr un
> BCP, pero no las políticas de los RIR. Como hemos planteado, el
> problema no tiene solución actual y sólo hay ideas de cómo atacarlos,
> por ejemplo a través de PCE entre proveedores.
> 

Yo no soy experto en BGP ni en TE, pero acabo de hablar con uno (Iljitsch
van Beijnum), para confirmar si mi punto de vista era bueno o no. Iljistsch
es bastante conocido en este campo en el IETF y ha trabajado mucho en IPv6 y
aspectos como multihoming, shim6, etc.

Me ha dicho que esto se puede resolver con comunidades en lugar de
desagregacion, y que en general los upstreams lo aceptan.

Curiosamente, tiene un libro publicado al respecto y el capitulo que esta
accesible como muestra es el que habla de TE:

http://www.oreilly.com/catalog/bgp/chapter/ch06.html

Los ejemplos son con IPv4, pero me ha confirmado que aplican exactamente
igual con IPv6.

Si quieres, me ha propuesto que le describas *exactamente* tu caso (si me lo
envias en privado en ingles, mejor y me ahorro traducirlo) y te pone
ejemplos concretos y nos confirma si es valido o no.

> 
>>> 
>>> La política actual además genera una injusticia importante,
>>> imaginemos que a mí me asignan un /32 y luego al año me asignan
>>> otro /
>>> 32. Yo podría publicar los dos en forma independiente. Ahora si de
>>> primera me asignan un /31, no puedo separarlo en dos /32. ¿esto es
>>> justo?, ¿realmente los RIR deberian controlar esto?, ¿acaso son la
>>> "policía" del routing?.
>>> 
>> 
>> Creo que discrepo. De la forma en la que se estan haciendo las
>> adjudicaciones y las reservas contiguas, y vosotros mismos habeis
>> pasado por
>> ello, al igual que al menos otros dos ISPs en la region que yo
>> recuerde
>> ahora mismo, si necesitas un prefijo mas grande, se te amplia la
>> asignacion.
>> Es decir, no se te entrega un nuevo /32, sino que tu /32 se
>> convierte en un
>> /31, /30, etc.
>> 
>> Luego no se produce una injusticia. De hecho, pienso que en ningun
>> RIR ha
>> habido este caso hasta el momento, y espero que no ocurra.
> 
>> Es mas, diria que si un ISP intenta "jugar sucio" y pide un /32, a
>> sabiendas
>> de que necesita un /30, y por cualquier motivo ello no fuera
>> posible, pienso
>> que deberia de plantearse que se le exija renumerar su red a un /30
>> nuevo,
>> para evitar que alguien intente dicho "juego".
> 
> te planteo otro ejemplo que ocurre con las políticas de remote -
> whois. Un proveedor tiene un /30, lo publica como 4x/32 y en el
> momento de pedir bloques adicionales, simplemente cambia la
> publicación a un /30, obtiene los bloques adicionales (en realidad no
> es claro que ese sea un requesito para obtenerlo pues no está escrito
> así en la política actual) y luego publica en forma desarreglada.
> ¿quien puede evitar esta situacion? de vuelta los RIR no son policías
> del routing.

No entiendo el ejemplo. Me estais diciendo que se "engañe" al RIR para pedir
mas bloques ? Bueno, siempre es posible, otra cosa es que sea etico y que
mas tarde o mas temprano se puedan dar cuenta o no.

> 
> 
>> 
>>>> Como es evidente, yo en principio estoy en contra de esta propuesta
>>>> y creo
>>>> que no se deben usar politicas para "corregir" *supuestos*
>>>> defectos de
>>>> diseño, cuando en realidad lo que pretendemos es duplicar errores
>>>> cometidos
>>>> con IPv4, en lugar de buscar otras soluciones tecnicas como es
>>>> debido, y
>>>> crear un nuevo factor de explosion de crecimiento de tablas de
>>>> routing, que
>>>> sera un importante coste para TODAS las redes, incluso aquellas
>>>> que no
>>>> desagreguen.
>>> 
>>> No veo que sea un problema de diseño de IPv6 sino es un tema de cómo
>>> se hace el routing en internet (el tema del "hot potatoes" bgp). Lo
>>> que se busca es ingeniería de tráfico. De vuelta no son los RIR el
>>> ámbito para imponer políticas de routing a los proveedores, no lo han
>>> sido en IPv4 y no lo deben ser ahora.
>> 
>> Una de las premisas del diseño de IPv6 fue evitar la desagregacion.
> 
> Bien, pero IPv6 se comenzó a pensar hace 20 años. No olvidemos que
> hoy en días en varias empresas con MPLS, ya están pensando en
> millones de rutas proveenientes de VPNs...

No IPv6 en lo que nos concierne a lo que estamos hablando yo diria que hace
13-14 años :-)

De nuevo te digo lo de antes, no soy un experto pero por lo que comento con
Iljitsch, sigue pudiendo hacerse sin desagregar.

> 
>> 
>> La cuestion de la ingenieria de trafico es un "defecto" tal como se
>> esta
>> haciendo con IPv4, y no debemos duplicar los errores. Ayer en la
>> reunion del
>> RRG, precisamente estuvimos viendo este tema y posible
>> alternativas. Parece
>> que pueda pasar forzosamente por la separcion de Locator/ID.
> 
> ¿hay acceso al acta de estas reunión? se agradecerá.

Supongo que se publicara, si la hay, pero me da la sensacion de que no vi a
nadie tomar notas ...

http://www1.tools.ietf.org/group/irtf/trac/wiki/RRG

Iljitsch tambien me ha apuntado a una propuesta de solucion que el tiene
para TE:

http://www.ietf.org/internet-drafts/draft-van-beijnum-v6ops-pa-mhome-communi
ty-01.txt

El el ultimo RIPE en Amsterdam tambien hizo una presentacion al respecto:
http://www.ripe.net/ripe/meetings/ripe-53/presentations/multihoming_paspace.
pdf

> 
>> 
>> Tambien como te decia antes, se esta trabajando en un documento en
>> v6ops.
>> 
>> Pero en definitiva creo que nos hemos acostumbrado a hacer
>> "chapuzas" para
>> solucionar mas que los problemas, los *intereses* de cada
>> proveedor, aunque
>> esto suponga un coste para el resto de la red, y creo que esto si
>> que es
>> realmente *injusto*. Dejamos de ser buenos "netcitizens" con tal de
>> ser mas
>> competitivos a costa de cargar esos costes no solo a nuestra
>> competencia
>> sino al resto de la red. Fijate, que no lo habia pensado nunca,
>> pero en
>> muchos paises estas practicas podrian ser incluso constitutivas de
>> delito
>> (anti-competencia, anti-trust). Creo que es mejor evitar que
>> ocurra, al
>> menos desde el punto de vista *normativo* (politicas), para evitar
>> que los
>> gobiernos o los reguladores quieran meterse en ello, no te parece ?
> 
> Creo que claramente esta es una herramienta básica para proveedores
> de mediano y pequeño tamañano. El no tenerla beneficia únicamente a
> quienes dan tránsito. Imaginemos que yo tengo un /28 que satura uno
> de mis enlaces con un proveedor de tránsito específico, me veo
> obligado a aumentar mi BW con el, no puedo simplemente desviar el
> tráfico a otros enlaces con por ejemplo menor uso.
> 
> Respecto al plano normativo, no soy abogado, pero como aclaraba en el
> párrafo anterior, me da la impresión que es justamente lo contrario.

Si las practias de unos (los que desagregan) implican un coste obligado para
muchos, creo que es un caso de anti-trust, pero tampoco soy abogado :-)
aunque me parece logico e inadmisible (mas cuando hay otras soluciones si lo
de las comunidades funciona).

> 
> 
>> 
>>> 
>>>> 
>>>> Por otro lado, esta politica SOLO tendria sentido si se logra
>>>> aprobar en
>>>> todas las regiones. Imaginemos que solo LACNIC la aprueba. Cuando
>>>> tus
>>>> prefijos desagregados lleguen a transitos de otras regiones, tu
>>>> trafico
>>>> seria filtrado, porque la desagregacion no coincide con las
>>>> asignaciones de
>>>> tu RIR. Creo que eso, en lugar de ayudarte, empeora tu situacion,
>>>> no ? De
>>>> hecho no es algo teorico, es algo que aquellos ISPs que ya
>>>> desagregan (en
>>>> contra de la politica), ya estan sufriendo (puedo poner varios
>>>> ejemplos,
>>>> pero el mas evidente es el de la propia infraestructura de APNIC,
>>>> que tiene
>>>> un /32, pero anuncian como 2x/33, en contra de su propia politica,
>>>> y dia si
>>>> dia no, no es alcanzable).
>>> 
>>> De vuelta, estamos errando a la intensión de la política. La idea es
>>> que si tenes un /28 puedas publicar 4x/30, no habría problemas con
>>> los filtros. Si vamos a lo que pasa en IPv4, no hay politica al
>>> respecto en los RIR (como deben ser) y hay un BCP no escrito donde se
>>> establece que un /24 es lo mínimo que se puede anunciar.
>> 
>> Precisamente, en IPv6 hay una politica porque es parte del diseño
>> de IPv6,
>> aprendiendo de los errores en IPv4.
>> 
>> Los filtros deben de configurarse en funcion de las adjudicaciones.
>> Un ISP
>> puede abrir la mano, pero no debemos de obligar a los demas ISPs,
>> que no
>> quieran a hacerlo, y si la consecuencia es que si el ISP A decide
>> hacerlo,
>> parte de la red no le pueda alcanzar, se lo pensara dos veces.
>> 
>> De hecho, tras mucho insistir, APNIC creo que ya se ha apuntado
>> esto en
>> serio y posiblemente se resuelva, pues dificulta el acceso a su
>> propia web y
>> considero que es muy mal ejemplo que un RIR incumpla su propia
>> politica.
> 
> Hoy en día la política de /24 para IPv4 funciona correctamente, no
> entiendo porqué podemos suponer que la politica de un /32 no vaya a
> funcionar para IPv6. Los ISPs han sido muy responsables en esto y
> para ser honesto creo que confío más en dajar el tema del filtrados
> en manos de la comunidad de operadores que en los RIRs.

Funciona en el sentido de que haces TE con coste obligado para todos, pero
no es la forma buena tecnicamente hablando.

Los problemas de escalabilidad de la tabla de routing van a ser muy graves,
y en gran parte vienen por las malas practicas adquiridas con IPv4 y que
ahora queremos "propagar" a IPv6, a pesar de que lo diseñamos para evitar
que ocurriera ...

Me gustaria ver mas operadores trabajando en IETF en lugar de quejarse, no
participar, y luego cuando damos soluciones, decir que no les gustan :-)
Ejemplo shim6, por mecionar solo uno.

> 
>> 
>>> 
>>>> 
>>>> El problema empeorara cuando empecemos a utilizar la certificacion
>>>> de los
>>>> prefijos, ya que en ese caso, de forma automatica, todos los
>>>> routers que
>>>> usen esa tecnologia, te filtrarian.
>>>> 
>>>> Por otro lado, creo que seria bueno tener un resumen en la lista de
>>>> los
>>>> comentarios que hayas tenido de Nanog u otros foros.
>>> 
>>> Recordemos que ya hemos tenido esta discusión hace unos meses y la
>>> realidad es que los proveedores lo están haciendo pues...no hay otra
>>> solución con el sistema de routing existente. Recordemos que estamos
>>> en Sudamérica, que el BW cuesta mucha $$$ y por ende necesitamos
>>> poder hacer ingeniería de tráfico para sacarle el mayor provecho a
>>> cada enlaces. En otras regiones para grandes operadores, simplemente
>>> se publican los superprefijos en todos los enlaces y que la red lo
>>> resulve, nosotros NO podemos hacer esto.
>>> 
>> 
>> No solo en LAC el BW cuesta mucho, pero como digo, hasta que punto
>> es justo
>> que tu ahorres a costa de los demas ?
> 
> cuál es el costo de los demás? la memoria de sus enrutadores? el uso
> de cpu? Esto no es sacrificar algo todos por el bien común, es
> sacrificar los que pagamos a los TIER1 por su bien común...

El problema no es el coste ahora, que aun es moderado, sino el que nos va a
suponer en 2-3 años ampliar todas las redes para manjerar 1.000.000 o
incluso xx.000.000 de rutas como se anticipaba en la reunion del RRG.

Es el bien comun, para resolver los males creados por quienes no participan
en la definicion de la tecnologia y ademas abusan de ello para terminar
haciendo lo que quieren. Me parece triste y por si hay dudas que conste que
no tengo nada personal en esto ni en contra de nadie, sino precisamente
busco el bien comun al menor coste para todos si hay alternativas
razonables, como asi parece.

> 
>> 
>>> 
>>>> 
>>>> Saludos,
>>>> Jordi
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> De: Nicolás Antoniello <nicolas at antel.net.uy>
>>>>> Organización: MEI - ANTELDATA
>>>>> Responder a: <nantoniello at antel.net.uy>, LACNIC Policy mailling
>>>>> list
>>>>> <politicas at lacnic.net>
>>>>> Fecha: Fri, 16 Mar 2007 17:53:44 -0300 (UYT)
>>>>> Para: <politicas at lacnic.net>
>>>>> Asunto: [LACNIC/Politicas] Política de publicaciones de bloques
>>>>> IPv6
>>>>> (propuesta para modificacion de politica)
>>>>> 
>>>>> Estimados,
>>>>> 
>>>>> Envío la propuesta formal para la modificación de la política de
>>>>> asigancion de prefijos IPv6:
>>>>> 
>>>>> Propuesta:
>>>>> 
>>>>> Se propone eliminar el punto 5.1.1.d:
>>>>> 
>>>>> 5.1 Adjudicación inicial
>>>>> 5.1.1 Criterio de adjudicación inicial
>>>>> d) Anunciar en el sistema de rutas inter-dominio de Internet un
>>>>> único
>>>>> bloque, que agregue toda la asignación de direcciones IPv6
>>>>> recibida, en un
>>>>> plazo no mayor de 12 meses.
>>>>> 
>>>>> Y promover la remoción de los equivalentes a nivel de todo los RIR.
>>>>> 
>>>>> 
>>>>> 
>>>>> Motivación:
>>>>> 
>>>>> (Adjunto la redacción en ingés que envié al foro de nanog)
>>>>> 
>>>>> The problem raises when a RIR assign a /28 prefix (for example) to
>>>>> an ISP
>>>>> which has 3 internet links with 3 different carriers (tier 1
>>>>> carriers, for
>>>>> example) using BGP publications.
>>>>> 
>>>>> Acording to ARIN (and most other RIRs) policy, the ISP must
>>>>> advertise
>>>>> through all the 3 links the /28 without the possibility of
>>>>> dissagregation.
>>>>> The problem with this policy is that by doing this, the ISP loses
>>>>> control
>>>>> of the traffic, not being able to distribute the traffic over the 3
>>>>> different links.
>>>>> 
>>>>> A /28 prefix may have a lot of incoming traffic associated to it,
>>>>> so I
>>>>> believe the dissagregation (subnets) of the prefix should be
>>>>> allowed by
>>>>> the policy.
>>>>> 
>>>>> Please read http://nro.org/documents/nro42.html for information
>>>>> about
>>>>> possible multi-homing solutions being analysed.
>>>>> 
>>>>> 
>>>>> Saludos,
>>>>> Nicolas Antoniello
>>>>> _______________________________________________
>>>>> 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
>> 
>> 
>> 
>> 
>> **********************************************
>> The IPv6 Portal: http://www.ipv6tf.org
>> 
>> Bye 6Bone. Hi, IPv6 !
>> http://www.ipv6day.org
>> 
>> This electronic message contains information which may be
>> privileged or confidential. The information is intended to be for
>> the use of the individual(s) named above. If you are not the
>> intended recipient be aware that any disclosure, copying,
>> distribution or use of the contents of this information, including
>> attached files, is prohibited.
>> 
>> 
>> 
>> _______________________________________________
>> Politicas mailing list
>> Politicas at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/politicas
> 




**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.