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

[Rogerio Mariano]

Luis, estoy de acuerdo con usted ..

Así que yo por ejemplo adopto algunos principios siempre:

- Mantener en lo posible un enfoque abierto y flexible. Mira centrarse en
resolver el problema, no en una tecnología específica.

- Mediante el estudio de una tecnología y entender su proposición y en
especial sus limitaciones.

-  Como amantes de la tecnología, por supuesto, nos encanta nueva, pero
evitar la trampa de tecnologías elaboradas.

- Busque el sencillo, limpio y asequible como sea posible.

La estabilidad y la calidad está antes que la funcionalidad. :-)

Un abrazo,
Rogerio Mariano

2016-11-07 16:34 GMT-02:00 Luis Balbinot <luis en luisbalbinot.com>:

> I wonder what Peter Lothberg thinks about all this complexity :-)
>
> I will miss the days where network design was something you could call
> "elegant".
>
> Luis
>
> 2016-11-07 15:56 GMT-02:00 Hernan Contreras (hcontrer) <hcontrer en cisco.com
> >:
> > Como uno de los pioneros en el despliegue de redes IPv6 (only), Comcast
> ha sido uno de los promotores del uso de SR en IPv6. Aca un caso de uso que
> fue presentado en un par de conferencias
> >
> > http://blogs.cisco.com/sp/bringing-segment-routing-and-ipv6-together
> >
> > Hay un draft del WG de SPRING que documenta mas casos de uso
> > https://www.ietf.org/id/draft-ietf-spring-ipv6-use-cases-07.txt
> >
> >
> >
> >
> >
> > Aca les dejo una implementación de SR-IPv6 en Linux por si quieren
> probarlo ;-)
> > http://www.segment-routing.org
> >
> > Slds
> > Hernan
> >
> > 11/7/16, 11:26 AM, "LACTF on behalf of Christian O'Flaherty" <
> lactf-bounces en lacnic.net on behalf of christian.oflaherty en gmail.com>
> wrote:
> >
> >>> 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
> >>
> >>> 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
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20161107/0cd0b494/attachment.html>