[LACNIC/Politicas] Politica de publicaciones de bloques IPv6 (propuesta para modificacion de politica)
Roque Gagliano
rgaglian at antel.net.uy
Wed Mar 21 08:56:18 BRT 2007
Gustavo, muchas gracias por el resumen. Estoy 100% de acuerdo con el
análisis de la situación.
Yo estoy de acuerdo con la postura de Nicolás de eliminar el inciso d),
creo que las políticas tienen que ser concretas y no marcar un espacio
de "deseo" o de debate. Cuando haya algún BCP o similar por parte del
IETF o IESG, lo estudiamos y podemos pues modificar la política para
hacer referencia al mismo.
slds
r.
On Wed, 2007-03-21 at 09:53 +0100, Gustavo Lozano wrote:
> 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
>
>
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
More information about the Politicas
mailing list