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

[Gustavo Lozano]

Jordi,

Si nos estamos liando como tú comentas, no creo 
que la bandera de que con IPv6 el poder llega a 
las aplicaciones o cosas por el estilo ayude a 
aclarar lo que se esta discutiendo, porque nadie 
esta discutiendo si queremos que el poder llegue 
o no a las aplicaciones o cosas por el estilo.

Voy a tratar de aclarar esta discusión desde un punto de vista neutral.

*Cuando un LIR y proximamente un END-SITE recibe 
un bloque lo puede anunciar por el numero de 
providers que desee y obtener "multihoming". Lo 
que estamos analizando en este thread es que 
actualmente en el mundo de IPv4 muchos hacemos 
desagregación del bloque asignado para hacer 
ingeniería de trafico (TE) o solucionar otros problemas que llegamos a tener.

*Se cree que muchos del anuncios desagregados que 
se ven actualmente en la “tabla de ruteo global 
de IPv4” son por organizaciones haciendo TE. Cada 
vez que alguien desagrega un bloque se incrementa 
el tamaño de la tabla de ruteo. Se le llama 
gastar un routing slot al hecho de que cada 
anuncio ya sea de un bloque desagregado o un 
nuevo bloque agregado utiliza una entrada en la 
tabla de ruteo (los ruteadores tienen cierta 
capacidad para almacenar y procesar entradas en la tabla de ruteo).

*El espacio de direcciones en IPv6 es mucho más 
grande que el de IPv4 y por lo tanto la cantidad 
de rutas que se pueden desagregar es superior, 
pero también en IPv4 se puede llegar a un punto 
de desagregación que sature a los ruteadores actuales.

*Las política de asignación de IPv6 de LACNIC 
dice en el inciso d: “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”. El propósito de este inciso es que 
no desagregues el bloque que te fue asignado para 
tratar de disminuir la velocidad con la que crece la tabla de ruteo.

*Existen otras formas de hacer TE que no dependen 
de desagregar el bloque pero depende la 
cooperación de los upstream providers. El caso 
que les mencione sobre DNS anycast necesita del 
anuncio de un bloque desagregado utilizando dos routing slots en lugar de uno.

*Conforme crezca el número de empresas haciendo 
multihoming y simplemente con el crecimiento de 
Internet algunas personas apuntan a que existe un 
punto en el que ya no puede crecer la capacidad 
de los ruteadores para soportar el crecimiento de 
la tabla de ruteo. En la IETF e IRTF se esta 
trabajando en alternativas que requieran menos 
procesamiento por parte de los ruteadores.

*Existen otros puntos de vista que dicen que a lo 
largo de la historia de la humanidad cuando 
existe un problema (ruteadores sin capacidad 
suficiente) existe el interés económico por 
solucionar el problema (ruteadores con capacidad 
suficiente). Otros puntos de vista apuntan a que 
si realmente ya no existe posibilidad de aumentar 
la capacidad de los ruteadores pues entonces 
entra la ley de la oferta y la demanda, cobrando posiblemente por routing slot.

A partir de esta sección empieza la parte no neutral.

Nadie ha dicho a partir del año 20xx ya no se 
pueden crecer los ruteadores o el limite que 
puede tener la tabla de ruteo es de xxM de rutas. 
La cuestión es que nadie puede saber el futuro, 
se pensaba que estábamos llegando al limite de la 
cantidad de transistores que podemos meter a un 
CPU y sin embargo seguimos viendo avances 
científicos que apuntan a que podemos seguir 
crecimiento la capacidad de procesamiento.

Cuando se mencionó en el thread las soluciones 
que se están buscando para multihoming se 
mencionaron porque algunas permiten hacer TE y 
podrían ayudar a no tener que hacer desagregación.

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

Al parecer el status quo en LACNIC ha sido no 
recuperar recursos por incumplimiento del inciso 
d porque simplemente la política no marca la 
penalización. Se aprobó en el pasado LACNIC una 
política para recuperación de recursos pero al 
parecer se utilizará para cuando la gente no use 
el recurso y no para este punto.

Algunos miembros de la lista hemos mostrado 
preocupación por el inciso d, porque planeamos 
hacer desagregación para TE o con otra finalidad. 
Aunque actualmente no se penalice por no cumplir 
con el inciso d existe la preocupación de algunos 
miembros sobre no estar haciendo lo que plantea la política.

Al hacer desagregación no sabemos si el recurso 
pueda ser marcado para recuperación por no cumplir con la política.

Entonces, la pregunta es, ¿Qué hacemos las 
personas que necesitamos desagregar por alguna razón?.
¿No implementamos IPv6 porque no puedo hacer lo 
mismo que con IPv4? ¿Justificamos ante LACNIC la 
necesidad de desagregar?. Cuando los upstream no 
quieren cooperar, LACNIC habla con providers para 
que cooperen y de esa forma no tener que desagregar.

Mi propuesta es cambiar la política para que diga 
que la organización que recibe un bloque de IPv6 
debe tratar de evitar la desagregación siempre 
que sea posible. Inclusive podemos agregar texto 
sobre el desafío que plantea el crecimiento de las tablas de ruteo a futuro.


At 00:03 21/03/2007, JORDI PALET MARTINEZ wrote:
>No se si nos estamos liando ...
>
>El multihoming para un ISP no es un problema con IPv6. Se anuncia el mismo
>prefijo a todos los upstreams providers.
>
>El problema lo tendria un usuario final que tuviera varios upstreams y un
>prefijo por cada upstream, y por solucionar esto se utiliza, de momento, el
>PI.
>
>El impulso de IPv6 ya esta llegando por las aplicaciones y los sistemas
>operativos en los extremos de la red. Es ya inevitable, aunque los ISPs no
>lo deseean. El retraso en su despliegue por parte de los ISPs es un coste
>sobretodo para ellos. Espero poder hacer una presentacion al respecto en la
>proxima reunion para demostrar lo que estoy diciendo.
>
>Saludos,
>Jordi
>
>
>
>
> > De: <asanchez at anteldata.com.uy>
> > Responder a: <asanchez at anteldata.com.uy>
> > Fecha: Tue, 20 Mar 2007 13:22:24 -0300
> > Para: <politicas at lacnic.net>, <jordi.palet at consulintel.es>
> > Conversación: [LACNIC/Politicas] Politica de publicaciones de bloques IPv6
> > (propuesta para modificacion de politica)
> > Asunto: RE: [LACNIC/Politicas] Politica de publicaciones de bloques IPv6
> > (propuesta para modificacion de politica)
> >
> > Estimados:
> > Coicidimos con Gustavo.
> > En lo inmediato, en ANTEL, tenemos el propósito de impulsar una paulatina
> > implantación de IPv6. Pero una condicionante que no podemos remover, es que
> > debemos hacer multihoming, y más aún, con varios enlaces con cada carrier.
> > Además, como país de reducidas dimensiones, no tenemos alternativa a
> > desagregar, a menos que se nos otorguen más prefijos, lo cual no tendría
> > mejores consecuencias: no sólo no se 
> mitigaría el crecimiento de las tablas,
> > sino que haríamos un uso ineficiente del recurso.
> > En el mediano plazo, si no se encuentra una solución técnica, creemos que
> > quienes deseen hacer full routing deberán 
> prepararse para un hardware potente,
> > o bien evaluar posibilidades de partial routing.
> > Por último, no entusiasma limitar lo 
> difícilmente controlable, o lo que no es
> > sancionable. Eso desacredita la norma.
> > Saludos.
> >
> > -----Mensaje original-----
> > De: politicas-bounces at lacnic.net [mailto:politicas-bounces at lacnic.net]En
> > nombre de Gustavo Lozano
> > Enviado el: lunes, 19 de marzo de 2007 16:58
> > Para: jordi.palet at consulintel.es; LACNIC Policy mailling list; LACNIC
> > Policy mailling list
> > Asunto: Re: [LACNIC/Politicas] Politica de publicaciones de bloques IPv6
> > (propuesta para modificacion de politica)
> >
> >
> > Jordi,
> >
> > Comentarios entre lineas.
> >
> > At 20:12 19/03/2007, JORDI PALET MARTINEZ wrote:
> >> Hola Gustavo,
> >>
> >> Ya he indicado que no soy experto en este 
> campo, y me he dejado guiar por lo
> >> que me han comentado otros. Por eso he pedido ejemplos concretos, mas
> >> detallados de en que casos la unica solucion es desagregar. Que dependa de
> >> un contacto comercial, coste en dolares, etc., no me parece una respuesta,
> >> porque ese coste que el ISP que desagrega se ahorra, lo pagamos todos los
> >> demas, y la verdad, no creo que sea justo.
> >
> > Cuando se implementan servidores de DNS bajo
> > esquema de Anycast desagregamos para evitar el
> > problema que te mencione en correos anteriores.
> >
> > De igual forma la utilización de comunidades como
> > solución y en general cualquier solución para
> > balancear tráfico de entrada en BGP depende de
> > los upstream providers y muchas veces no cooperan
> > o no saben. Y no puedes decir tan fácilmente que
> > es opción cambiar de proveedores. Hay cuestiones
> > de negocio y otros factores (no existen mas
> > proveedores por ejemplo) por la cual tienes que
> > usar x o y proveedor. Desagregar funciona con todos los operadores :).
> >
> > Eso que mencionas del costo no lo pagamos todos.
> > Lo pagan los ISPs que necesitan full routing. Un
> > ISP o empresa que solo tiene un proveedor de
> > Internet recibe lo que se conoce como default
> > route y no ve impacto por la desagregación. Los
> > ISPs que necesitan full routing son los que
> > tienen peerings con otros ISPs, en general los
> > ISPs grandes. Y no es una injusticia, es
> > simplemente el precio que se tiene que pagar por
> > recibir full routing y por como fue diseñado el
> > esquema de ruteo. Ojo, multihoming se puede
> > implementar con default routes o con full routing.
> >
> > El problema del crecimiento de las tablas de
> > ruteo existe y se va a encontrar una solución
> > técnica, porque simplemente el crecimiento de los
> > usuarios de Internet y de las empresas que
> > necesitan multihoming va a seguir en un futuro.
> > No creo que sea buena idea seguir poniendo
> > barreras artificiales al desarrollo de IPv6.
> > Muchos se quejan de que IPv6 no tiene la adopción
> > que debería tener, pero, si seguimos limitando lo
> > que la gente puede hacer en IPv6, su adopción
> > será mas lenta o se llegara a la idea que IPv4 es mejor.
> >
> >
> >> Lo de un bloque adicional ya lo he comentado 
> en un coreo anterior. Creo que
> >> hay un vacio en la politica, y me suena que 
> Roque ya planteo el tema. Ahora
> >> mismo creo que LACNIC hace una reserva mayor, y lo normal es que no te
> >> entregara un nuevo bloque, sino te diera un 
> prefijo mas corto que incluyera
> >> tu bloque actual y el nuevo, con lo cual seguirias sin poder desagregar.
> >
> > Primero me gustaría que se definiera como se van
> > a realizar las mediciones y cual es la
> > penalización por desagregar un bloque. Cual es la
> > tabla oficial de ruteo y porque? Cuantas veces
> > tiene que estar el bloque desagregado, por cuanto
> > tiempo, etc. Si existen penalización (reclamar el
> > recurso por ejemplo) entonces esta política tiene
> > que ser mas clara y detallada.
> >
> >> Regards,
> >> Jordi
> >>
> >>
> >>
> >>
> >>> De: Gustavo Lozano <glozano at nic.mx>
> >>> Responder a: <glozano at nic.mx>
> >>> Fecha: Mon, 19 Mar 2007 19:33:49 +0100
> >>> Para: <jordi.palet at consulintel.es>, LACNIC Policy mailling list
> >>> <politicas at lacnic.net>, "nantoniello at antel.net.uy, LACNIC Policy mailling
> >>> list" <politicas at lacnic.net>
> >>> Asunto: Re: [LACNIC/Politicas] Politica de publicaciones de bloques IPv6
> >>> (propuesta para modificacion de politica)
> >>>
> >>> Comentarios en el texto.
> >>>
> >>> At 18:34 19/03/2007, JORDI PALET MARTINEZ wrote:
> >>>> Hola Nicolas,
> >>>>
> >>>> No se hasta que punto en una politica 
> tiene sentido una recomendación, la
> >>>> verdad, no lo tengo claro. No digo si es bueno o malo.
> >>>>
> >>>> Lo de cuando el uso de IPv6 sea masivo es
> >> algo complejo de responder ... Yo
> >>>> creo que nos llevaremos muchas sorpresas en 12-18 meses, y en una
> >>>> presentacion que me gustaria hacer en el proximo LACNIC puedo aportar
> >>>> estadisticas que dan indicios de lo que esta
> >> pasando, apenas solo unos meses
> >>>> del lanzamiento de Vista, que permite que 
> los usuarios (independientemente
> >>>> de los ISPs) esten utiliando IPv6 sin 
> darse cuenta y atravesando NATs :-)
> >>>>
> >>>> La pregunta critica aquí quizas la tiene 
> que responder el staff de LACNIC.
> >>>> Que ocurre cuando se desagrega y LACNIC lo
> >> detecta ? Mi opinion es que salvo
> >>>> que la comunidad pida una reaccion, no deberia de hacerse nada. Si fuera
> >>>> evidente que hay otras soluciones tenicas
> >> alternativas como las comunidades,
> >>>> quizas la cosa deberia de ser diferente y se
> >> deberia de lanzar un warning a
> >>>> los que desagreguen y darles un plazo.
> >>>
> >>> Te lo digo por experencia de administración de
> >>> varios ASNs y varias sesiones full routing de BGP
> >>> que esto de las comunidades dependes de los
> >>> upstream providers. Y en ocasioens no 
> puedes cambiar de upstream providers.
> >>>
> >>> Ademas, hay casos en que las comunidades no
> >>> sirven y tienes que desagregar. En el correo
> >>> anterior te di un ejemplo de cuando la unica
> >>> solucion es desagregar.
> >>> http://www.merit.edu/mail.archives/nanog/2005-10/msg01229.html
> >>>
> >>> En general anunciar mas especificos es uno de los
> >>> trucos mas usados por los proveedores de contenido.
> >>>
> >>> Por cierto, en la politica no dice que cuando
> >>> recibes un bloque adicional tienes que anunciar
> >>> el agregado. Entonces podrias pedir un /32 y
> >>> despues pedir mas espacio de direcciones que
> >>> posiblemente sean bloques contiguos y no anunciar el agregado.
> >>>
> >>>> Hay que tener en cuenta que hay otros 
> puntos en varias politicas que no se
> >>>> estan cumpliendo, como son los anuncios en
> >> dos años, etc. Y creo que se esta
> >>>> procediendo con cautela, de momento con 
> recordatorios, pero en un momento
> >>>> dado se podria llegar a reclamar un 
> recurso y es evidente que no es usado
> >>>> siguendo la politica y no hay intencion de hacerlo en un plazo concreto.
> >>>>
> >>>> 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: Mon, 19 Mar 2007 13:59:21 -0300 (UYT)
> >>>>> Para: <politicas at lacnic.net>
> >>>>> Asunto: [LACNIC/Politicas] Politica de publicaciones de bloques IPv6
> >>>>> (propuesta para modificacion de politica)
> >>>>>
> >>>>> Nicolas/Jordi,
> >>>>>
> >>>>> Veo que todos estamos deacuerdo en que 
> claramente la solucion al problema
> >>>>> del multi-homing venga por el lado de 
> encontrar un mecanismo que funcione
> >>>>> y sea practicable, sin la necesidad de 
> desagregar... aunque creo que dada
> >>>>> la cantidad de metodologias y planteos de posibles soluciones (con sus
> >>>>> pros y contras) sea algo concretable a 
> corto plazo. Mas que nada, porque
> >>>>> el problema aparecera como algo realmente prioritario para los usuarios
> >>>>> (ISPs, etc...) cuando el uso de IPv6 sea 
> masivo (me refiero globalmente).
> >>>>>
> >>>>> Lo que sucede es que segun esta planteado 
> (corrijanme si me equivoco) en
> >>>>> la politica de LACNIC y en la de los demas RIR, figura como una
> >>>>> condicionante para la asignacion.
> >>>>> Mi pregunta es: que sucedera al cabo de 12
> >> meses si un ISP no agrerga todo
> >>>>> el prefijo? Es mas, estariamos mintiendo al solicitar un bloque
> >>>>> argumentando que cumplimos (y cumpliremos) con lo requerido en la
> >>>>> politica, si al final desagregamos el bloque, no?
> >>>>>
> >>>>> De hecho, en el documento que menciona Jordi
> >>>>> (draft-baker-v6ops-l3-multihoming-analysis-00) la publicacion sin
> >>>>> desagregar es algo que, segun dice en el 
> documento, deben recomendar los
> >>>>> RIR; pero en el caso nuestro, no es una recomendacion sino un
> >>>>> requerimiento para obtener un prefijo IPv6 y eso es lo que creo que
> >>>>> deberiamos modificar (por cierto, las asignaciones PA o la solución de
> >>>>> "exchange-based addressing" creo que presentan grandes obstaculos como
> >>>>> para poder ser facimente implementables o incluso aceptables tanto por
> >>>>> usuarios finales como ISPs, pero eso es otro tema).
> >>>>>
> >>>>> Saludos,
> >>>>> Nicolas.
> >>>>> _______________________________________________
> >>>>> 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
> >>>
> >>> Gustavo Lozano
> >>> NIC Mexico
> >>>
> >>>
> >>
> >>
> >>
> >>
> >> **********************************************
> >> 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
> >
> > Gustavo Lozano
> > NIC Mexico
> >
> >
> > _______________________________________________
> > Politicas mailing list
> > Politicas at lacnic.net
> > https://mail.lacnic.net/mailman/listinfo/politicas
> >
> >
> > Este e-mail y cualquier posible archivo adjunto está dirigido únicamente al
> > destinatario del mensaje y contiene 
> información que puede ser confidencial. Si
> > Ud. no es el destinatario correcto por favor notifique al remitente
> > respondiendo este mensaje y elimine inmediatamente el e-mail y los posibles
> > archivos adjuntos al mismo de su sistema. Está prohibida cualquier
> > utilización, difusión o copia de este e-mail 
> por cualquier persona o entidad
> > que no sean las específicas destinatarias del 
> mensaje. ANTEL no acepta ninguna
> > responsabilidad con respecto a cualquier comunicación que haya sido emitida
> > incumpliendo nuestra Política de Seguridad de la Información.
> > . . . . . . . . .
> > This e-mail and any attachment is 
> confidential and is intended solely for the
> > addressee(s). If you are not intended recipient please inform the sender
> > immediately, answering this e-mail and delete it as well as the attached
> > files. Any use, circulation or copy of this e-mail by any person or entity
> > that is not the specific addressee(s) is 
> prohibited. ANTEL is not responsible
> > for any communication emitted without respecting our Information Security
> > Policy.
>
>
>
>
>**********************************************
>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

Gustavo Lozano
NIC Mexico