[LACNIC/Politicas] Pol í tica de publicaciones de bloques IPv6

ARG-O'FLAHERTY, CHRISTIAN COFLAHERTY at IMPSAT.COM
Tue Jan 16 13:59:23 BRST 2007 

Hola Jordi, nuestros mails se cruzaron ;-)

Una aclaración sobre tu propuesta:

>	- Anuncia el /30 a sus 3 upstreams (cada uno con uno o varios enlaces), en este caso situados en US.
>	- Anuncia el /32 de cada pais en el IX de dicho pais (en realidad no esta desagregando, ya que los IX solo cursan trafico "local"). 

Muchas veces el anuncio en el país es para tener conexión con algun proveedor local que tambien anunciará ese bloque a la tabla global. Es una buena política de planificación tener los anuncios "consistentes" siempre que sea posible ya que el tamaño del bloque le gana a cualquier otro criterio de balanceo del BGP.

Christian

-----Original Message-----
From: politicas-bounces at lacnic.net [mailto:politicas-bounces at lacnic.net] On Behalf Of JORDI PALET MARTINEZ
Sent: Martes, 16 de Enero de 2007 12:28 p.m.
To: LACNIC Policy mailling list
Subject: Re: [LACNIC/Politicas]Pol í tica de publicaciones de bloques IPv6

Sigo dudando que este caso no se haya dado en otras regiones, con otros ISPs. Vamos, que no me parece habitual que surja este problema en LAC cuando no ha surgido en otras regiones con mas despliegue (en tiempo y volumen) ...
Quizas el siguiente paso antes de proponer una politica es consultar el caso abiertamente en listas globales (incluso en la de Nanog ?). Asi saldriamos de dudas.

Una posible explicacion es que si se ha dado, y han utilizado el metodo de la desagregacion como en IPv4, nadie se haya "apercibido" de que la politica que le ha adjudicado el prefijo no le permite hacerlo, y ha quedado "impune". Si es asi, creo que lo razonable es cambiar la politica, no solo en LAC, sino en todas las regiones (hay que entender/recordar, que todas las politicas de IPv6 fueron confeccionadas en conjunto por todas las regiones existentes en aquel momento - APNIC, ARIN, RIPE), luego los "errores" se han
propagado) ...

El caso que yo comente en su momento es un poco diferente. Basicamente se trata de ISPs que tienen cobertura en diferentes regiones en las que necesitan intercambiar trafico local en un IX (para lo cual anuncian prefijos desagregados a nivel local). Sin embargo, sus upstreams son unicos para toda su red (no diferentes por cada region), y por tanto no necesitan desagregar el prefijo de cara a sus upstreams. Mas concretamente (es un
ejemplo):

- ISP que tiene red en Chile, Argentina, Venezuela y Brasil.
- En uno o varios de estos paises participa en el IX, y por tanto no puede anunciar alli nada mas pequeño que un /32.
- Asi que recibe (lo puede justificar, por el tamaño de la red, por la necesidad de no anunciar algo mas pequeño de /32 en un pais, etc.), un /30.
- Anuncia el /30 a sus 3 upstreams (cada uno con uno o varios enlaces), en este caso situados en US.
- Anuncia el /32 de cada pais en el IX de dicho pais (en realidad no esta desagregando, ya que los IX solo cursan trafico "local").

Saludos,
Jordi




> De: marcelo bagnulo braun <marcelo at it.uc3m.es> Responder a: LACNIC 
> Policy mailling list <politicas at lacnic.net>
> Fecha: Tue, 16 Jan 2007 15:57:30 +0100
> Para: LACNIC Policy mailling list <politicas at lacnic.net>, 
> <nantoniello at antel.net.uy>
> Asunto: Re: [LACNIC/Politicas] Política de publicaciones de bloques 
> IPv6
> 
> 
> El 16/01/2007, a las 15:43, Nicolás Antoniello escribió:
> 
>> Marcelo,
>> 
>> Respondiendo entre lineas:
>> 
>> marcel >> Como caso de análisis supongamos lo siguiente:
>> marcel >> Tengo un ISP con 3 enlaces OC-12 contra 3 proveedores
>> (carriers)
>> marcel >> diferentes, que terminan en routers diferentes en ambas 
>> partes (del marcel >> lado marcel >> del ISP y del lado de los 
>> carriers).
>> marcel >> Y tengo asignado un /28 que insume un tráfico entrante de 
>> unos 1.5Gbps marcel >> (2.5 x OC-12 a modo de ejemplo).
>> marcel >> Entonces, la pregunta es: ¿Como distribuyo el tráfico, 
>> publicando marcel >> unicamente el /28?
>> marcel >
>> marcel >que pasa si anuncias el /28 por los 3 carriers? ellos 
>> anunciarian el /28 marcel >y entonces las fuentes de paquetes mas 
>> cercanos de cada uno de ellos marcel >preferirian la ruta mas 
>> cercana. De esta forma se balancearia la carga marcel >naturalmente 
>> en los enlaces,no?
>> 
>> 
>> Esto me parece que es un caso bastante teórico, me refiero a que esto 
>> sucede si el ISP esta conectado con 3 puntos geograficamente 
>> distribuidos
>> 
> 
> esta claro que a medida que los 3 carriers estan mas lejos en la 
> topologia (en particular en la parte de la topologia por donde estan 
> distribuidas las fuentes que envian mensajes), la distribucion de la 
> carga entrante mejorara
> 
>> 
>> y si la distribución greográfica de las fuentes es uniforme. En la 
>> práctica, es caci imposible que esto suceda si un ISP esta conectado 
>> a
>> 3
>> carriers en USA por ejemplo.
>> 
> 
> como menciono antes, creo que lo importante no es la distribucion 
> geografica sino la cercania topologica de los carriers a las distinas 
> fuentes de mensajes.
> 
> pero en cualquier entiendo que esto depende de la topologia
> 
>> 
>> marcel >
>> marcel >Lo que puede pasar es que este balanceo no sea el que deseas 
>> y quieras marcel >desplazar parte de el trafico de un enlace hacia 
>> otro. en este caso te marcel >podes ayudar del AS path prepending. 
>> Mediante esta tecnica podes marcel >desplazar parte del trafico que 
>> antes venia por el camino al que le marcel >agregas ASes 
>> artificialmente.
>> 
>> 
>> Una vez mas, creo que la utilización de prepending no permite pasar
>> parte
>> del tráfico hacia otro lado, sino que en la práctica, se lográ pasar un
>> porcentaje minimo y en determinado momento se tiene un punto de quiebre
>> luego del cual (al seguir agregando prepends) todo el tráfico se va
>> para
>> el "otro" lado.
> 
> si, la granulidad de este esquema es el punto debil... o bien pasas muy
> poco o puede que si haces mas prepending pases todo el trafico, de
> acuerdo
> 
>> Es decir, esta técnica creo que no provee la granularidad adecuada
>> para la
>> tarea de distribuir el tráfico, y creo que el problema empeora cuanto
>> mayor sea el bloque del que estamos hablando (por ej. para un /28).
>> 
>> Adicionalmente a lo anterior, el hecho de publicar un solo bloque por
>> todos lados, reduce el control del ISP al mínimo, dejando al carrier o
>> lo que es peor, a la "suerte" la tarea de la distribución del tráfico,
>> eperando que la distrubución de fuentes sea uniforme.
>> 
> 
> mas que a la suerte, tambien a lo que prefieran los carriers y los
> otros ISPs
> 
> lo que parece estar claro es que la desagregacion artificial como
> herramienta de ingenieria de trafico es una tecnica muuuy utilizada hoy
> en IPv4 al menos.
> Las ventajas que plantea esta tecnica es un control muy fino y fuerte
> de la distribucion del trafico y los isps parece necesitarlo.
> 
> 
> Por otra parte, IPv6 no ofrece ninguna herramienta alternativa para
> realizar estas funciones de ingenieria de trafico. entonces, si IPv6 no
> ofrece alternativas tecnicas, sera necesario hacerlo como en IPv4, es
> decir desagregar.
> 
> Creo que el punto que planteas es muy valido y creo que se deberia
> discutir una politica que ofreciera soluciones al problema que planteas
> 
> Saludos, marcelo
> 
> 
>> 
>> marcel >El tema que tenes aca es que puede que no sea suficientemente
>> fino y que
>> marcel >quieras mas control. Por ejemplo, un caso en el que veo eso es
>> en que tu
>> marcel >red este distribuida geograficamente y tengas distintos
>> accesos locales
>> marcel >en distintos puntos de la geografia y quieras que las
>> direcciones que
>> marcel >asignas en uruguay sean accedidas a traves de tu proveedor en
>> uruguay y
>> marcel >no a traves de tu proveedor en chile. de forma de no tener que
>> usar tus
>> marcel >propios enlaces internacionales internos a tu red. En este caso
>> marcel >pareceria que lo que tenes que hacer es tener varios bloques y
>> asignar
>> marcel >cada uno de esos bloques a las redes locales de cada pais.
>> marcel >Pero creo que esto es posible en la politica actual...(creo
>> que hay
>> marcel >varios proveedores grandes en europa que hacen esto, creo
>> recordar a
>> marcel >Jordi comentar algo de este tema..?)
>> 
>> Esto último no es el caso que planteaba, pero creo que es interesante
>> ver
>> este problema también.
>> 
>> Saludos,
>> Nicolas.
>> 
>> 
>> 
>> 
>> 
>> marcel >> On Tue, 16 Jan 2007, marcelo bagnulo braun wrote:
>> marcel >>
>> marcel >> marcel >Hola Nicolas,
>> marcel >> marcel >
>> marcel >> marcel >El 15/01/2007, a las 17:27, Nicolás Antoniello
>> escribió:
>> marcel >> marcel >
>> marcel >> marcel >> Hola Francisco,
>> marcel >> marcel >>
>> marcel >> marcel >> Si, el texto que se presenta en ese libro, habla
>> de los
>> marcel >> mecanismos y
>> marcel >> marcel >> alternativas "convencionales" digamos, para
>> realizar
>> marcel >> publicaciones BGP
>> marcel >> marcel >> (muti-path, med, prepends, etc...).
>> marcel >> marcel >>
>> marcel >> marcel >> En lo referente al balanceo, pone un caso muy
>> simple (y
>> marcel >> facil de
>> marcel >> marcel >> resolver)
>> marcel >> marcel >> que es el caso en que se tiene un router en el que
>> terminan
>> marcel >> mas de un
>> marcel >> marcel >> enlace con un mismo ISP, en cuyo caso se pueden
>> armar
>> marcel >> bundles BGP y
>> marcel >> marcel >> banacear el tráfico (utilizando el multi-path).
>> marcel >> marcel >>
>> marcel >> marcel >> El caso que yo planteo es un poco mas complejo
>> (incluso se
>> marcel >> menciona
>> marcel >> marcel >> como
>> marcel >> marcel >> un recurso en el texto que tu citas) que es cuando
>> un ISP
>> marcel >> tiene
>> marcel >> marcel >> enlaces
>> marcel >> marcel >> desde diversos routers contra diversos ISP y
>> pretende (por
>> marcel >> obvias
>> marcel >> marcel >> razones)
>> marcel >> marcel >> balancear el tráfico entrante.
>> marcel >> marcel >> Esto, no será posible si se publica todo en un
>> solo bloque
>> marcel >> sumarizado.
>> marcel >> marcel >>
>> marcel >> marcel >
>> marcel >> marcel >podrias hacer AS path prepending, no?
>> marcel >> marcel >
>> marcel >> marcel >saludos, marcelo
>> marcel >> marcel >
>> marcel >> marcel >
>> marcel >> marcel >> Por ello es que no veo que en la práctica sea
>> aplicable esa
>> marcel >> politica
>> marcel >> marcel >> de
>> marcel >> marcel >> "sumarizacion en un solo bloque" a la hora de
>> publicar...
>> marcel >> sin
>> marcel >> marcel >> mencionar
>> marcel >> marcel >> que estamos hablando de un bloque ralmente muy
>> grande de
>> marcel >> direcciones
>> marcel >> marcel >> IPv6.
>> marcel >> marcel >>
>> marcel >> marcel >> Imaginate que si por ejemplo ese bloque tiene unos
>> 100.000
>> marcel >> usuarios
>> marcel >> marcel >> DSL
>> marcel >> marcel >> "atras" con un tráfico promedio de unos 70-80Mbps
>> por cada
>> marcel >> /21
>> marcel >> marcel >> publicado
>> marcel >> marcel >> (para el caso de IPv4)... esto, llevado a IPv6 en
>> un bloque
>> marcel >> /29 por
>> marcel >> marcel >> ejemplo, es inmanejable publicarlo por un unico
>> enlace,
>> marcel >> incluso por
>> marcel >> marcel >> unos
>> marcel >> marcel >> pocos enlaces (ni que hablar de los ISP que poseen
>> enlaces
>> marcel >> de relativo
>> marcel >> marcel >> bajo ancho de banda como STM-1). La unica forma es
>> subnetear
>> marcel >> ese
>> marcel >> marcel >> bloque y
>> marcel >> marcel >> publicarlo para lograr distribuir el tráfico entre
>> unos
>> marcel >> cuantos
>> marcel >> marcel >> enlaces...
>> marcel >> marcel >> esa es la realidad (creo) de muchos ISPs.
>> marcel >> marcel >>
>> marcel >> marcel >> Saludos,
>> marcel >> marcel >> Nicolas.
>> marcel >> marcel >>
>> marcel >> marcel >>
>> marcel >> marcel >>
>> marcel >> marcel >>
>> marcel >> marcel >>
>> marcel >> marcel >> On Mon, 15 Jan 2007, Francisco Obispo wrote:
>> marcel >> marcel >>
>> marcel >> marcel >> fobisp >Estimado Nicolas,
>> marcel >> marcel >> fobisp >
>> marcel >> marcel >> fobisp >Aunque mi especialidad no es routing,
>> considero que
>> marcel >> el
>> marcel >> marcel >> desagregar
>> marcel >> marcel >> fobisp >bloques
>> marcel >> marcel >> fobisp >para "balancear" cargas, en realidad pone
>> en riesgo
>> marcel >> la
>> marcel >> marcel >> estabilidad de tu
>> marcel >> marcel >> fobisp >red
>> marcel >> marcel >> fobisp >en caso de que uno de estos enlaces se
>> caiga.
>> marcel >> marcel >> fobisp >
>> marcel >> marcel >> fobisp >Es decir, probablemente tengas el
>> beneficio de un
>> marcel >> balanceo a
>> marcel >> marcel >> la fuerza,
>> marcel >> marcel >> fobisp >pero
>> marcel >> marcel >> fobisp >luego incrementas el tamaño de la tabla de
>> marcel >> ruteamiento y
>> marcel >> marcel >> pierdes el
>> marcel >> marcel >> fobisp >componente
>> marcel >> marcel >> fobisp >de redundancia que probablemente necesitas.
>> marcel >> marcel >> fobisp >
>> marcel >> marcel >> fobisp >Te recomiendo que revises
>> marcel >> marcel >> http://www.oreilly.com/catalog/bgp/chapter/
>> marcel >> marcel >> fobisp >ch06.html
>> marcel >> marcel >> fobisp >donde el capitulo de "traffic engineering"
>> está
>> marcel >> bastante
>> marcel >> marcel >> explícito de
>> marcel >> marcel >> fobisp >como debe
>> marcel >> marcel >> fobisp >manejarse esas situaciones.
>> marcel >> marcel >> fobisp >
>> marcel >> marcel >> fobisp >
>> marcel >> marcel >> fobisp >Saludos
>> marcel >> marcel >> fobisp >
>> marcel >> marcel >> fobisp >
>> marcel >> marcel >> fobisp >_____________________________
>> marcel >> marcel >> fobisp >Francisco Obispo
>> marcel >> marcel >> fobisp >Jefe de Oficina de NIC-VE
>> marcel >> marcel >> fobisp >Centro Nacional de Tecnologías de
>> Información
>> marcel >> marcel >> fobisp >
>> marcel >> marcel >> fobisp >
>> marcel >> marcel >> fobisp >
>> marcel >> marcel >> fobisp >
>> marcel >> marcel >> fobisp >
>> marcel >> marcel >> fobisp >On 15/01/2007, at 09:27 AM, Nicolás
>> Antoniello
>> marcel >> wrote:
>> marcel >> marcel >> fobisp >
>> marcel >> marcel >> fobisp >> Estimados,
>> marcel >> marcel >> fobisp >>
>> marcel >> marcel >> fobisp >> Tengo una consulta sobre la política de
>> marcel >> publicaciones de
>> marcel >> marcel >> bloques de
>> marcel >> marcel >> fobisp >> direcciones IPv6 que me genera una duda
>> en cuanto
>> marcel >> a la
>> marcel >> marcel >> aplicación
>> marcel >> marcel >> fobisp >> práctica de la referida política.
>> marcel >> marcel >> fobisp >>
>> marcel >> marcel >> fobisp >> En la política se plantea que a la hora
>> de
>> marcel >> publicar bloques
>> marcel >> marcel >> IPv6
>> marcel >> marcel >> fobisp >> asignados por los NICs (por ejemplo un
>> /29 o lo
>> marcel >> que sea), se
>> marcel >> marcel >> envíe una
>> marcel >> marcel >> fobisp >> unica publicación con el superbloque.
>> marcel >> marcel >> fobisp >>
>> marcel >> marcel >> fobisp >> Ahora bien, que sucede si un ISP u otro
>> proveedor
>> marcel >> de acceso
>> marcel >> marcel >> a Internet
>> marcel >> marcel >> fobisp >> posee varios enlaces con diversos
>> carriers
>> marcel >> internacionales y
>> marcel >> marcel >> desea
>> marcel >> marcel >> fobisp >> balancear la carga de tráfico que
>> "vuelve" por
>> marcel >> dichos
>> marcel >> marcel >> enlaces?
>> marcel >> marcel >> fobisp >>
>> marcel >> marcel >> fobisp >> Es decir, cuando se publican bloques
>> subneteados,
>> marcel >> se busca
>> marcel >> marcel >> balancear
>> marcel >> marcel >> fobisp >> el tráfico entrante por los enlaces
>> marcel >> internacionales hacia el
>> marcel >> marcel >> ISP, lo
>> marcel >> marcel >> fobisp >> cual no sería posible implementar si se
>> publicara
>> marcel >> por todos
>> marcel >> marcel >> los
>> marcel >> marcel >> fobisp >> enlaces el superbloque asignado.
>> marcel >> marcel >> fobisp >>
>> marcel >> marcel >> fobisp >> Tal vez no me quedó claro el enunciado
>> de dicha
>> marcel >> política y
>> marcel >> marcel >> por ello
>> marcel >> marcel >> fobisp >> remito la consulta al foro.
>> marcel >> marcel >> fobisp >>
>> marcel >> marcel >> fobisp >> Saludos,
>> marcel >> marcel >> fobisp >> Nicolas
>> marcel >> marcel >>
>> Antoniello._______________________________________________
>> marcel >> marcel >> fobisp >> Politicas mailing list
>> marcel >> marcel >> fobisp >> Politicas at lacnic.net
>> marcel >> marcel >> fobisp >>
>> https://mail.lacnic.net/mailman/listinfo/politicas
>> marcel >> marcel >> fobisp >
>> marcel >> marcel >> fobisp
>>> _______________________________________________
>> marcel >> marcel >> Politicas mailing list
>> marcel >> marcel >> Politicas at lacnic.net
>> marcel >> marcel >> https://mail.lacnic.net/mailman/listinfo/politicas
>> marcel >> marcel >
>> marcel >> marcel >
>> marcel >_______________________________________________
>> Politicas mailing list
>> Politicas at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/politicas
> 
> _______________________________________________
> 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


Esta comunicación es confidencial y puede contener información cuya divulgación esté restringida por la ley o en virtud de obligaciones de confidencialidad asumidas por acuerdos escritos. Si usted no es su destinatario, por favor advierta que cualquier divulgación, distribución o copia de esta comunicación le está estrictamente prohibida. Si usted recibió este mail por error, agradeceremos tenga a bien informar esa circunstancia al remitente mediante comunicación a la dirección de e-mail o al número telefónico : (5411) 5170-0000, y le solicitamos asimismo que por favor proceda a borrarlo de su computadora. Por favor no copie ni use la información contenida en este mail para ningún propósito y no divulgue su contenido a ninguna otra persona. 


This communication is confidential and may contain information that is exempt from disclosure by law or pursuant to confidentiality obligations assumed by written agreement. If you are not the intended recipient, please note that any dissemination, distribution, or copying of this communication is strictly prohibited. If you receive this e-mail in error, please notify the sender immediately at the electronic mail address or phone number : (5411) 5170-0000  and delete the information from your computer. Please do not copy or use it for any purpose nor disclose its contents to any other person.

More information about the Politicas mailing list