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

Tue Mar 20 20:03:49 BRT 2007

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.