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

Tue Mar 20 13:22:24 BRT 2007

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.