[lacnog] [LAC-TF] IPv6, el principio E2E, e IPv6 EH insertion

[Luis Balbinot]

Correct. There's a label stack with all "segments" that the packet
should follow. It's much simpler to the network core and it relies on
the existing IGP for label distribution. Also, you can make routing
decisions on-the-go, without having to rely on path calculation
algorithms when something bad happens. Even though it's a "simpler"
approach to the core, it depends on external controllers (PCE) for
configuration, just like BIER (no more cli).

LDPv6 is already available on JunOS 16.1. I'm testing it and it looks
good so far.
https://www.juniper.net/techpubs/en_US/junos16.1/topics/task/configuration/configuring-ldp-native-ipv6-support.html

Luis

2016-11-07 12:40 GMT-02:00 Tomas Lynch <tomas.lynch en gmail.com>:
>
> 2016-11-07 9:26 GMT-05:00 Christian O'Flaherty
> <christian.oflaherty en gmail.com>:
>>
>> > I like source routing and I think it's a good idea, but it only makes
>> > sense to me on the MPLS domain. I'd like to see a killer application
>> > for SR on IPv6.
>> >
>>
>> Coincido con Luis... lo que se se usa para traffic engineering en MPLS
>> (MPLS-TE) no escala y no es cómodo. SR parece una muy buena solución a
>> ese problema...
>> No se en que caso se usaría con EH en IPv6... Alguien sabe cual es la
>> utilidad?
>>
>> Christian
>
>
> Según tengo entendido Segment Routing para IPv4 agrega en el ingreso la pila
> de etiquetas MPLS que serán utilizadas en el camino de ingreso hacia el
> ingreso. Entonces con IPv6, y debido a que no existe un "LDPv6", quieren
> utilizar los Extension Headers.
>
> ¿Cómo está la estandarización de "LDPv6"? ¿No es más fácil concentrarse en
> eso que armar a Frankenstein?
>
>>
>>
>> > Luis
>> >
>> > 2016-11-07 0:05 GMT-02:00 Fernando Gont <fgont en si6networks.com>:
>> >> Estimados,
>> >>
>> >> Cuestiones interesantes:
>> >>
>> >> En mas de una oportunidad deben haber escuchado aseveraciones varias
>> >> referidas al principio End-To-End (E2E) e IPv6. De manera simple, en
>> >> las
>> >> redes IPv4 se modifica constantemente los paquetes IPv4, principalmente
>> >> debido al uso de NATs. En principio, tales modificaciones "en vuelo" a
>> >> los paquetes pueden resultar en problemas dificiles de detectar y
>> >> solucionar (ya que el paquete que vemos en un punto de la red es puede
>> >> ser muy distinto al que se ve en otro punto de la red).
>> >>
>> >> Uno de los argumentos en favor de IPv6 tradicionalmente ha sido que
>> >> justamente nos iba a librar de dicha cuestion, ya que, en principio no
>> >> iba a exitir NAT con IPv6 (esto en la practica ya no es así, pero eso
>> >> es
>> >> otra historia).
>> >>
>> >> Lo curioso del caso es algo que ha venido aconteciendo recientemente en
>> >> el ambito de IETF (precisamente en el 6man wg, grupo encargado de la
>> >> estandarización de IPv6): En dicho grupo actualmente se esta
>> >> proponiendo
>> >> la implementacion de una tecnologia (segment routing), que se desea que
>> >> *inserte* encabezados de extension (EHs) en el punto de ingreso a la
>> >> red, y se los remueva en el punto de ingreso. (Si te preguntas de que
>> >> se
>> >> trata la tecnologia, es algo asi como permitir "source routing", con la
>> >> diferencia que en este caso el "camino" lo elige la red en el punto de
>> >> ingreso).
>> >>
>> >> Esa cuestión de insertar encabezados va en contra de IPv6 tal como se
>> >> lo
>> >> conoce, y puede generar una cantidad de problemas (romper IPsec,
>> >> Path-MTU Discovery), y otras tantas. Asi y y todo, el tema se esta
>> >> dscutiendo en el grupo. Peor aun, pareciera como que se buscara generar
>> >> una ambiguedad en esta materia (donde no la hay), basicamente abriendo
>> >> el camino para que luego cosas tales como la insercion de EHs pueda
>> >> estandarizarse. (El motivador de esta cuestión es este documento:
>> >> https://datatracker.ietf.org/ipr/2421/)
>> >>
>> >> P.S.: <https://youtu.be/By83GP_tIJE?t=16s>
>> >>
>> >> Saludos,
>> >> --
>> >> Fernando Gont
>> >> SI6 Networks
>> >> e-mail: fgont en si6networks.com
>> >> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> LACNOG mailing list
>> >> LACNOG en lacnic.net
>> >> https://mail.lacnic.net/mailman/listinfo/lacnog
>> >> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>> > _______________________________________________
>> > LACNOG mailing list
>> > LACNOG en lacnic.net
>> > https://mail.lacnic.net/mailman/listinfo/lacnog
>> > Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>> _______________________________________________
>> LACTF mailing list
>> LACTF en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lactf
>> Cancelar suscripcion: lactf-unsubscribe en lacnic.net
>
>
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>