<div dir="auto">Excelente, Fernando!<div dir="auto"><br></div><div dir="auto">Voy a revisar, ojalá pronto venga como RFC y tenga amplia adopción para solucionar ese problema. </div><div dir="auto"><br></div><div dir="auto">Saludos,</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 13, 2021, 23:04 Fernando Gont <<a href="mailto:fernando@gont.com.ar">fernando@gont.com.ar</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Estimados,<br>
<br>
El IESG ha aprobado nuestro documento:<br>
<br>
Titulo: "Improving the Reaction of Customer Edge Routers to IPv6 <br>
Renumbering Events"<br>
URL: <br>
<a href="https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-cpe-slaac-renum-08" rel="noreferrer noreferrer" target="_blank">https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-cpe-slaac-renum-08</a><br>
<br>
Este documento tiene una serie de requerimientos para CPE routers que <br>
intentan mitigar los problemas que ocurren en escenarios de <br>
"flash-renumbering" de IPv6 (como los documentados en <br>
<a href="https://datatracker.ietf.org/doc/html/rfc8978" rel="noreferrer noreferrer" target="_blank">https://datatracker.ietf.org/doc/html/rfc8978</a>).<br>
<br>
Dios mediante ;-), es solo cuestion de tiempo (~3 meses) para que <br>
nuestro documento se publique como RFC.<br>
<br>
Para aquellos que trabajen en operaciones (por ej. en ISPs), este <br>
documento puede ser de utilidad tanto para chequear el funcionamiento <br>
actual de sus CPE routers, como tambien para RFPs a la hora de adquirir <br>
los mismos.<br>
<br>
Los comentarios, como siempre, seran bienvenidos.<br>
<br>
Saludos cordiales, y gracias!<br>
Fernando Gont<br>
<br>
<br>
<br>
<br>
-------- Forwarded Message --------<br>
Subject: [v6ops] Protocol Action: 'Improving the Reaction of Customer <br>
Edge Routers to IPv6 Renumbering Events' to Best Current Practice <br>
(draft-ietf-v6ops-cpe-slaac-renum-08.txt)<br>
Date: Wed, 09 Jun 2021 14:26:06 -0700<br>
From: The IESG <<a href="mailto:iesg-secretary@ietf.org" target="_blank" rel="noreferrer">iesg-secretary@ietf.org</a>><br>
To: IETF-Announce <<a href="mailto:ietf-announce@ietf.org" target="_blank" rel="noreferrer">ietf-announce@ietf.org</a>><br>
CC: <a href="mailto:v6ops@ietf.org" target="_blank" rel="noreferrer">v6ops@ietf.org</a>, <a href="mailto:v6ops-chairs@ietf.org" target="_blank" rel="noreferrer">v6ops-chairs@ietf.org</a>, <br>
<a href="mailto:draft-ietf-v6ops-cpe-slaac-renum@ietf.org" target="_blank" rel="noreferrer">draft-ietf-v6ops-cpe-slaac-renum@ietf.org</a>, The IESG <<a href="mailto:iesg@ietf.org" target="_blank" rel="noreferrer">iesg@ietf.org</a>>, <br>
<a href="mailto:rfc-editor@rfc-editor.org" target="_blank" rel="noreferrer">rfc-editor@rfc-editor.org</a><br>
<br>
The IESG has approved the following document:<br>
- 'Improving the Reaction of Customer Edge Routers to IPv6 Renumbering<br>
    Events'<br>
   (draft-ietf-v6ops-cpe-slaac-renum-08.txt) as Best Current Practice<br>
<br>
This document is the product of the IPv6 Operations Working Group.<br>
<br>
The IESG contact persons are Warren Kumari and Robert Wilton.<br>
<br>
A URL of this Internet Draft is:<br>
<a href="https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/" rel="noreferrer noreferrer" target="_blank">https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/</a><br>
<br>
<br>
<br>
<br>
Technical Summary<br>
<br>
    This document sets forth recommendations intended to improve CPE <br>
default behavior on IPv6 networks.<br>
Specifically, it aims to clarify certain timer interactions on dynamic <br>
prefixes and improve behavior<br>
in scenarios where network configuration information becomes invalid <br>
without explicit signaling<br>
of that condition.<br>
<br>
Working Group Summary<br>
<br>
    The document so far has been approved by the V6OPS working group <br>
(successful working group<br>
last call). The document does not specify new protocol, but rather <br>
changes to the default parameters<br>
in existing protocols.<br>
<br>
Document Quality<br>
<br>
    The document is clear, outlines a real problem and provides clear <br>
advice.<br>
Through the three revisions, the document has received substantial <br>
comments from the working<br>
group and significantly improved with each revision as a result.<br>
<br>
Personnel<br>
<br>
    Owen DeLong is the Document Shepherd<br>
    Fred Baker and Ron Bonica are the WG chairs<br>
    Warren Kumari is RAD!<br>
<br>
_______________________________________________<br>
v6ops mailing list<br>
<a href="mailto:v6ops@ietf.org" target="_blank" rel="noreferrer">v6ops@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/v6ops" rel="noreferrer noreferrer" target="_blank">https://www.ietf.org/mailman/listinfo/v6ops</a><br>
<br>
<br>
-- <br>
Fernando Gont<br>
e-mail: <a href="mailto:fernando@gont.com.ar" target="_blank" rel="noreferrer">fernando@gont.com.ar</a> || <a href="mailto:fgont@si6networks.com" target="_blank" rel="noreferrer">fgont@si6networks.com</a><br>
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1<br>
<br>
<br>
<br>
_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net" target="_blank" rel="noreferrer">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" rel="noreferrer noreferrer" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
</blockquote></div>