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