[LACNIC/Politicas] Politica de publicaciones de bloques IPv6 (propuesta para modificacion de politica)

[Nicolás Antoniello]

Estimados, agrego comentarios entre lineas a los realizados por Gustavo y 
Jordi:

politi >Voy a tratar de aclarar esta discusi?n desde un punto de vista neutral.
politi >
politi >*Cuando un LIR y proximamente un END-SITE recibe 
politi >un bloque lo puede anunciar por el numero de 
politi >providers que desee y obtener "multihoming". Lo 
politi >que estamos analizando en este thread es que 
politi >actualmente en el mundo de IPv4 muchos hacemos 
politi >desagregaci?n del bloque asignado para hacer 
politi >ingenier?a de trafico (TE) o solucionar otros problemas que llegamos a tener.

Exacto, como se menciona en correos anteriores, parte del problema (y solo 
PARTE de el) es consecuencia de que por diversas razones muchos ISPs hacen 
multi-homing:
* Por razones de seguridad, obteniendo redundancia en lo que refiere a 
posibles problemas de algún carrier en particular.
* Por razones económcas y de negocio (que son sumamente dinámicas) y 
llevan a tener diversos contratos con distintos carriers.
* Por acuerdos regionales entre ISPs o países limitrofes que desean 
pasarse algunas rutas y no todas (y ojo que este es otro problema un tanto 
diferente al multi-homing).
* Porque los enlaces que se tienen (en algunas economías de ISPs) no son 
del ancho de banda suficiente para cursar todo el tráfico, pero en 
conjunto, varios enlaces si lo son aunque con diferentes proveedores (alli 
surge el multi-home).

politi >*Se cree que muchos del anuncios desagregados que 
politi >se ven actualmente en la ?tabla de ruteo global 
politi >de IPv4? son por organizaciones haciendo TE. Cada 
politi >vez que alguien desagrega un bloque se incrementa 
politi >el tama?o de la tabla de ruteo. Se le llama 
politi >gastar un routing slot al hecho de que cada 
politi >anuncio ya sea de un bloque desagregado o un 
politi >nuevo bloque agregado utiliza una entrada en la 
politi >tabla de ruteo (los ruteadores tienen cierta 
politi >capacidad para almacenar y procesar entradas en la tabla de ruteo).
politi >
politi >*El espacio de direcciones en IPv6 es mucho m?s 
politi >grande que el de IPv4 y por lo tanto la cantidad 
politi >de rutas que se pueden desagregar es superior, 
politi >pero tambi?n en IPv4 se puede llegar a un punto 
politi >de desagregaci?n que sature a los ruteadores actuales.

Agrego:
Puedo estar equivocado, pero con la política actual en la que cada ISP 
debe publicar un solo bloque agregado se tendrían muchas menos rutas de 
las que se tienen actualmente en la "tabla de ruteo global" (suponiendo 
que no aumentamos el numero de ISPs). Entonces, no creo que desagregando 
algunos bloques (con cierto criterio, tal cual se hace ahora con IPv4) 
traiga problemas de forma inmediata... más bien, los problemas de 
"espacio" y "capacidad" de los equipos surgiran por otro lado.

politi >*Las pol?tica de asignaci?n de IPv6 de LACNIC 
politi >dice en el inciso d: ?d) Anunciar en el sistema 
politi >de rutas inter-dominio de Internet un ?nico 
politi >bloque, que agregue toda la asignaci?n de 
politi >direcciones IPv6 recibida, en un plazo no mayor 
politi >de 12 meses?. El prop?sito de este inciso es que 
politi >no desagregues el bloque que te fue asignado para 
politi >tratar de disminuir la velocidad con la que crece la tabla de ruteo.

Agrego:
Una vez mas, creo que con esa imposición, se reducen aún mas que hoy las 
tablas de ruteo... cosa que no creo necesaria por el momento.

politi >*Existen otras formas de hacer TE que no dependen 
politi >de desagregar el bloque pero depende la 
politi >cooperaci?n de los upstream providers. El caso 
politi >que les mencione sobre DNS anycast necesita del 
politi >anuncio de un bloque desagregado utilizando dos routing slots en lugar de uno.
politi >
politi >*Conforme crezca el n?mero de empresas haciendo 
politi >multihoming y simplemente con el crecimiento de 
politi >Internet algunas personas apuntan a que existe un 
politi >punto en el que ya no puede crecer la capacidad 
politi >de los ruteadores para soportar el crecimiento de 
politi >la tabla de ruteo. En la IETF e IRTF se esta 
politi >trabajando en alternativas que requieran menos 
politi >procesamiento por parte de los ruteadores.
politi >
politi >*Existen otros puntos de vista que dicen que a lo 
politi >largo de la historia de la humanidad cuando 
politi >existe un problema (ruteadores sin capacidad 
politi >suficiente) existe el inter?s econ?mico por 
politi >solucionar el problema (ruteadores con capacidad 
politi >suficiente). Otros puntos de vista apuntan a que 
politi >si realmente ya no existe posibilidad de aumentar 
politi >la capacidad de los ruteadores pues entonces 
politi >entra la ley de la oferta y la demanda, cobrando posiblemente por routing slot.
politi >
politi >A partir de esta secci?n empieza la parte no neutral.
politi >
politi >Nadie ha dicho a partir del a?o 20xx ya no se 
politi >pueden crecer los ruteadores o el limite que 
politi >puede tener la tabla de ruteo es de xxM de rutas. 
politi >La cuesti?n es que nadie puede saber el futuro, 
politi >se pensaba que est?bamos llegando al limite de la 
politi >cantidad de transistores que podemos meter a un 
politi >CPU y sin embargo seguimos viendo avances 
politi >cient?ficos que apuntan a que podemos seguir 
politi >crecimiento la capacidad de procesamiento.
politi >
politi >Cuando se mencion? en el thread las soluciones 
politi >que se est?n buscando para multihoming se 
politi >mencionaron porque algunas permiten hacer TE y 
politi >podr?an ayudar a no tener que hacer desagregaci?n.

Agrego:
Estas soluciones que se plantean, son las mismas que una y otra vez se 
evaluan y discuten en varios foros como este, nanog, los de la IETF, 
etc... y existe un sinnúmero de papers y presentaciones sobre cada una de 
las posibles soluciones. El hecho es que muchas de ellas requieren (además 
de la coordinación y cooperación con los carriers, cosa que no es tan 
simple de implementar en la práctica, en el sentido que cada uno tiene "su 
forma de hacer las cosas" y siempre es mejor tratar de que las 
"interfaces" entre ISPs y Carriers sean lo mas simples posibles (tal vez 
sea hora de cambiar esos paradigmas, pero llevará tiempo y dinero).
Otras soluciones que se plantean tienen el inconveniente de que son muy 
poco tolerantes a errores humanos (problemas de configuración) y requieren 
mayor expertice por parte de los operadores de los ISPs y de los Carriers.
En general, el mecanismo de escalamiento de problemas en los Carriers es 
muy "impersonal" por decirlo de alguna manera, lo que dificulta mucho la 
depuración de problemas... y esto sería mucho peor si complicamos mas las 
"interfaces".

politi >Cuando se  mencion? en la lista que el costo del 
politi >crecimiento de las tablas de ruteo lo pagamos 
politi >todo y que eso es injusto, mi postura es que el 
politi >crecimiento de las tablas de ruteo afecta a las 
politi >organizaciones que necesitan full routing. Las 
politi >empresas que reciben default routes (la gran 
politi >mayor?a) para salir a Internet no se ven 
politi >afectadas por el crecimiento de las tablas de 
politi >ruteo. Desde mi punto de vista no es una 
politi >injusticia, simplemente es el costo que tienen 
politi >que pagar las organizaciones (generalmente ISPs) 
politi >que quieren recibir full routing.

Exacto, y agrego, que siempre (como se mencionaba en correos anteriores) 
esta la opción de hacer un ruteo parcial en lugar de uno completo.

De todas formas, el full-routing creo que no es una opcion para muchos 
ISPs, no solo por la carga que significa para los equipos de bbone, sino 
porque en muchas ocaciones haría que saturaran los enlaces (ya que hasta 
cierto punto, se pierde el "control" de por donde se cursa el tráfico, 
sobre todo en el caso de multi-home, porque de nada sirve full-routing 
si se tiene un solo enlace).  :)

politi >Al parecer el status quo en LACNIC ha sido no 
politi >recuperar recursos por incumplimiento del inciso 
politi >d porque simplemente la pol?tica no marca la 
politi >penalizaci?n. Se aprob? en el pasado LACNIC una 
politi >pol?tica para recuperaci?n de recursos pero al 
politi >parecer se utilizar? para cuando la gente no use 
politi >el recurso y no para este punto.
politi >
politi >Algunos miembros de la lista hemos mostrado 
politi >preocupaci?n por el inciso d, porque planeamos 
politi >hacer desagregaci?n para TE o con otra finalidad. 
politi >Aunque actualmente no se penalice por no cumplir 
politi >con el inciso d existe la preocupaci?n de algunos 
politi >miembros sobre no estar haciendo lo que plantea la pol?tica.
politi >
politi >Al hacer desagregaci?n no sabemos si el recurso 
politi >pueda ser marcado para recuperaci?n por no cumplir con la pol?tica.

Llegado ese punto, seguramente terminariamos modificando la política... y 
si LACNIC y los otros RIR deciden hacer cumplir las políticas (cosa que 
se supone que hacen porque para eso están las mismas) seguramente 
llegaremos a este punto.

politi >Entonces, la pregunta es, ?Qu? hacemos las 
politi >personas que necesitamos desagregar por alguna raz?n?.
politi >?No implementamos IPv6 porque no puedo hacer lo 
politi >mismo que con IPv4? ?Justificamos ante LACNIC la 
politi >necesidad de desagregar?. Cuando los upstream no 
politi >quieren cooperar, LACNIC habla con providers para 
politi >que cooperen y de esa forma no tener que desagregar.
politi >
politi >Mi propuesta es cambiar la pol?tica para que diga 
politi >que la organizaci?n que recibe un bloque de IPv6 
politi >debe tratar de evitar la desagregaci?n siempre 
politi >que sea posible. Inclusive podemos agregar texto 
politi >sobre el desaf?o que plantea el crecimiento de las tablas de ruteo a futuro.


politi >At 00:03 21/03/2007, JORDI PALET MARTINEZ wrote:
politi >>No se si nos estamos liando ...
politi >>
politi >>El multihoming para un ISP no es un problema con IPv6. Se anuncia el mismo
politi >>prefijo a todos los upstreams providers.

Justamente esto es lo que estamos diciendo que no podemos hacer algunos 
ISPs.

politi >>El problema lo tendria un usuario final que tuviera varios upstreams y un
politi >>prefijo por cada upstream, y por solucionar esto se utiliza, de momento, el
politi >>PI.

El PI no soluciona el problema que se plantea aquí.

politi >>El impulso de IPv6 ya esta llegando por las aplicaciones y los sistemas
politi >>operativos en los extremos de la red. Es ya inevitable, aunque los ISPs no
politi >>lo deseean. El retraso en su despliegue por parte de los ISPs es un coste
politi >>sobretodo para ellos. Espero poder hacer una presentacion al respecto en la
politi >>proxima reunion para demostrar lo que estoy diciendo.

Jordi, no estoy muy deacuerdo con algunas de las cosas que mencionas. Creo 
que los sistemas operativos no impulsan IPv6 (lo apoyan si, como lo hacen 
los sabores de "linux" y el OSX hace ya un tiempo, y como lo esta haciendo 
Microsoft con Vista ahora... pero definitivamente creo que no lo impulsan, 
simplemente porque no tienen motivos para ello, al menos eso creo. 

Por otro lado, las aplicaciones (las de tipo moviles sobre todo) si 
impulsan IPv6 por un tema de masividad y posiblemente (aunque es una 
facilidad que no se ve tan clara por el publico en general) por el tema de 
la autoconfiguración. Los servicios masivos agotan rapidamente las 
direcciones IPv4 y complican la gentión de las mismas, entonces, 
naturalmente se tenderá a un espacio de direcciónes mayor, como el que 
provee IPv6.

No creo que los ISPs no deseen migrar a IPv6; el problema no es la 
migración sino la transisión... cuanto mas abrupta, mas resistida es... y 
políticas como la que discutimos aquí, hacen que se resista mas el cambio 
porque rempen de lleno con la forma de hacer las cosas que tiene la 
mayoría de los ISPs y eso es algo que si cuesta dinero y formación 
técnica... ademas de experiencia, reclamos de clientes, etc...

Como comentario personal, creo que de todas formas, si se transfiere el 
costo de la implantación de IPv6 a los ISPs, lo que se hace es frenar la 
propia implantación, pues a mi entender serán los ISPs los que utilicen 
IPv6 (los carriers no lo necesitan, los que lo necesitan son los serivcios 
masivos).

Por último, lo que estamos intentando aqui es justamente, modificar la 
política para hacer partícipes del impulso de IPv6 a la grán mayoría de 
ISPs que hacen multi-homing y necesitan desagregar (al menos por el 
momento) para poder solucionar un montón de inconvenientes, muchos de los 
cuales se mencionaron en esta discusión... que por cierto veo sumamente 
positiva.

Saludos,
Nicolas.