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

[alberto paz]

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
>>
>