[LAC-TF] Consulta experiencias en el despliegue IPv6 (Dual stack / 6VPE)

Mon May 19 14:41:40 BRT 2014

Alfredo:
        me olvide de esta presentacion  tambien ...
        http://www.cu.ipv6tf.org/lacnic14/lacnog/IPV6_Presentacion-Draft_final.pdf

Atte

AP


El 19/5/14, alberto paz <albertoepaz at gmail.com> escribió:
> Alfredo:
>         pienso que tambien te puede servir de apoyo esta experiencia ...
>
> http://prensa.lacnic.net/news/2011-01-2/ipv6-la-experiencia-de-telecom
>
> Atte
>
> AP
>
> El 19/5/14, Jaris Aizprua <jarisaizprua at gmail.com> escribió:
>> Hola Alfredo buen día,
>>
>> En primer lugar a que te refieres con "no soportan MPLS en IPv6" para el
>> tema de Dual-Stack.
>>
>> Sobre IPv6 y MPLS las opciones son 6PE y 6VPE, siendo la segunda opción
>> la
>> más usada puesto que es equivalente a los servicios L3VPN VPNv4; en dicho
>> escenario se utilizan los mismos LSP establecidos en el Core sobre IPv4
>> para el transporte de IPv6 de manera transparente.
>>
>> Personalmente he trabajado en ambientes 6VPE multi-vendor (Cisco y
>> Huawei)
>> y no he tenido problema alguno en lo referente a data-plane, tampoco en
>> control-plane; algo que te puedo sugerir como "pruebas" es transportar
>> IPv6
>> sobre EoMPLS (L2VPN) y realices las mismas mediciones, al final de
>> cuentas
>> sigue siendo conmutación de etiquetas pero el resultado a nivel de
>> estadísticas puede ser el mismo o diferente; no necesitas soporte de IPv6
>> en el transporte (MPLS) cuando utilizas L2VPN.
>>
>> También puedes leer el RFC4379 (Detecting Multi-Protocol Label Switched
>> (MPLS) Data Plane Failures).
>>
>> Sobre este párrafo que escribiste "cuando trasladamos dichas pruebas, por
>> ejemplo, activando un cliente IPv6 puro, conectado en un punto de acceso
>> (detrás del CPE) que hace tránsito por los mismos equipos de la red
>> MPLS",
>> te refieres a transporte 6VPE o cómo?
>>
>> Saludos!!!
>>
>>
>> El 19 de mayo de 2014, 10:11, Alfredo Makencie<
>> Alfredo.Makencie at telefonica.com> escribió:
>>
>>> Buenos días Estimados,
>>>
>>> Gusto en saludarles. Tengo una inquietud con respecto al despliegue de
>>> IPv6 en ISPs. Estuvimos manejando activación de Dual Stack como primera
>>> opción para la activación de IPv6 en nuestros servicios corporativos y
>>> de
>>> datos móviles, sin embargo, nuestros proveedores (CISCO, Huawei,
>>> Alcatel,
>>> NSN entre otros) no soportan MPLS en IPv6, y tratándose la nuestra de
>>> una
>>> red totalmente MPLS, estamos reorientando la planificación en función de
>>> activar 6VPE en lugar de Dual Stack.
>>>
>>> Durante el desarrollo de varias conferencias donde se habló de IPv6 en
>>> LACNIC21, noté como se hacían comparaciones entre la velocidad de
>>> respuesta
>>> de IPv6 e IPv4, llegándose a la conclusión que IPv6 tiene una tasa de
>>> respuesta más eficiente que IPv4. Personalmente he ejecutado pruebas
>>> controladas directamente en nuestras interconexiones obteniendo los
>>> mismos
>>> resultados, sin embargo, cuando trasladamos dichas pruebas, por ejemplo,
>>> activando un cliente IPv6 puro, conectado en un punto de acceso (detrás
>>> del
>>> CPE) que hace tránsito por los mismos equipos de la red MPLS, nos damos
>>> cuenta que se afecta significativamente el tiempo de respuesta al mismo
>>> destino. Esto se encuentra directamente relacionado al manejo de IPv6
>>> nativo ya que se deben mantener tablas de enrutamiento generales,
>>> basadas
>>> en IP y no en etiquetas como es el caso de MPLS.
>>>
>>> Siendo que MPLS es un protocolo que nació precisamente de la necesidad
>>> de
>>> conmutar grandes volúmenes de paquetes para que los equipos de capa 3
>>> pudieran competir con las capacidades de conmutación de equipos ATM, al
>>> comparar los tiempos de respuesta entre los paquetes IPv4 enviados a
>>> través
>>> de nuestra red MPLS y los paquetes IPv6 enviados por medio de
>>> interconexiones IPv6 (aplicando tráfico de solo 20% de la capacidad en
>>> ambas interfaces) nos damos cuenta que IPv4 es mucho más eficiente en
>>> cuanto a tiempos de respuesta y estadísticas de pérdida de paquetes.
>>> Para
>>> justificar esta situación solo se me ocurre que es precisamente la
>>> conmutación por etiquetas (MPLS) y conmutación por IP (IPv6) lo que está
>>> haciendo la diferencia.
>>>
>>> Dicho lo anterior, quisiera consultarles si alguno de ustedes tiene
>>> experiencia en el despliegue de IPv6 sobre redes MPLS, cuál es el
>>> mecanismo
>>> que aplican y si los resultados han sido satisfactorios o si fue
>>> necesario
>>> sacrificar funcionalidades de MPLS como QoS en el camino.
>>>
>>> De igual manera me pongo a sus órdenes por cualquier duda o comentario.
>>>
>>> Saludos.
>>>
>>> Alfredo Makencie | Telefónica Venezuela
>>> alfredo.makencie at telefonica.com
>>>
>>> -----Mensaje original-----
>>> De: lactf-bounces at lacnic.net [mailto:lactf-bounces at lacnic.net] En nombre
>>> de Alejandro Acosta
>>> Enviado el: sábado, 17 de mayo de 2014 11:25 p.m.
>>> Para: lactf at lac.ipv6tf.org
>>> Asunto: [LAC-TF] Call For IPv6 Case Studies For World IPv6
>>> Launchiversary
>>>
>>> FYI. Seria muy bueno poder meter un caso de LAC por aqui
>>>
>>>
>>> http://www.internetsociety.org/deploy360/blog/2014/04/call-for-ipv6-case-studies-for-world-ipv6-launchiversary/
>>> _______________________________________________
>>> LACTF mailing list
>>> LACTF at lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/lactf
>>> Cancelar suscripcion: lactf-unsubscribe at lacnic.net
>>>
>>> ________________________________
>>>
>>> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
>>> puede contener información privilegiada o confidencial y es para uso
>>> exclusivo de la persona o entidad de destino. Si no es usted. el
>>> destinatario indicado, queda notificado de que la lectura, utilización,
>>> divulgación y/o copia sin autorización puede estar prohibida en virtud
>>> de
>>> la legislación vigente. Si ha recibido este mensaje por error, le
>>> rogamos
>>> que nos lo comunique inmediatamente por esta misma vía y proceda a su
>>> destrucción.
>>>
>>> The information contained in this transmission is privileged and
>>> confidential information intended only for the use of the individual or
>>> entity named above. If the reader of this message is not the intended
>>> recipient, you are hereby notified that any dissemination, distribution
>>> or
>>> copying of this communication is strictly prohibited. If you have
>>> received
>>> this transmission in error, do not read it. Please immediately reply to
>>> the
>>> sender that you have received this communication in error and then
>>> delete
>>> it.
>>>
>>> Esta mensagem e seus anexos se dirigem exclusivamente ao seu
>>> destinatário,
>>> pode conter informação privilegiada ou confidencial e é para uso
>>> exclusivo
>>> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
>>> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
>>> cópia sem autorização pode estar proibida em virtude da legislação
>>> vigente.
>>> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
>>> imediatamente por esta mesma via e proceda a sua destruição
>>> _______________________________________________
>>> LACTF mailing list
>>> LACTF at lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/lactf
>>> Cancelar suscripcion: lactf-unsubscribe at lacnic.net
>>>
>>
>