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