Carlos, Thanks very much for reviewing the DHCPv6 Failover Protocol draft! To answer your question first, as Bernie mentioned, there is an implementation which is substantially identical to the protocol described in the draft. The on-the-wire packets are not compatible, since there are no IANA numbers for anything at this point, but it is essentially the same protocol. The experience I could report is simply that it *does* appear to work. There have certainly been bugs in the implementation, and there were some small issues early on that were also protocol issues, but any fixes that were made to the protocol were also rolled into previous versions of the draft, so that the draft has reaped the benefit of some real-world experience. There wasn't much, actually, that changed because of that. I expect that is because this DHCPv6 draft is very similar to the DHCPv4 Failover Protocol draft that went through 12 revisions before finally bogging down in its own weight. It finished at 133 pages, and I'll spare you more of that story. That said, the DHCPv4 version was implemented by several companies, and that draft contained much that was learned through those multiple implementations, which certainly informed the work on this DHCPv6 Failover Protocol. Regarding figures for Section 4. I have created one that tries to illustrate the example given in the text in Section 4.1.1. It shows both how the MCLT works as well as Lazy Update. I will publish it in the next version of the draft. Here it is: > Internet-Draft DHCPv6 Failover Protocol January 2017 > > > Fundamental relationship: > lease time = floor(desired lifetime, ack-partner-lifetime + MCLT) > > Initial conditions: MCLT = 1h, desired lifetime = 3d > > DHCPv6 Primary Secondary > time Client Server Server > > | >-SOLICIT------> | | > | acknowledged partner lifetime = 0 | > | lease time = floor( 3d, 0 + 1h ) = 1h | > | <-----ADVERTISE-< | | > | lease-time= 1h | | > | >-REQUEST------> | | > t | <---------REPLY-< | | > | lease-time= 1h | | > | | >-BNDUPD------> | > | | partner-lifetime = 1/2h + 3d > | | <----BNDREPLY-< | > | | partner-lifetime = 1/2h + 3d > 1/2h passes ... ... ... > t+1/2h | >-RENEW--------> | | > | acknowledged partner lifetime = 3d | > | lease time = floor( 3d, 3d + 1h ) = 3d | > | <---------REPLY-< | | > | lease-time=3d | | > | | >-BNDUPD-------> | > | | partner-lifetime = 1.5d + 3d > | | <----BNDREPLY-< | > | | partner-lifetime = 1.5d + 3d > acknowledged partner lifetime = 1.5d + 3d > 1.5d passes ... ... ... > | | | > t+1.5d + 1/2h | >-RENEW--------> | | > | acknowledged partner lifetime = 3d | > | lease time = floor( 3d, 3d + 1h ) = 3d | > | <---------REPLY-< | | > | lease-time=3d | | > | | >-BNDUPD-------> | > | | partner-lifetime = 1.5d + 3d > | | <----BNDREPLY-< | > | | partner-lifetime = 1.5d + 3d > | acknowledged partner lifetime = 1.5d + 3d| > > Figure 1: MCLT Example > > > > > > > Mrugalski & Kinnear Expires July 15, 2017 [Page 17] > I hope this helps folks get a better idea of some of the fundamental ideas on which the draft is based. Thanks again for the thoughtful review! Regards -- Kim > On Dec 24, 2016, at 2:55 AM, Carlos Bernardos <cjbc@xxxxxxxxxx> wrote: > > Reviewer: Carlos Bernardos > Review result: Ready > > I am an assigned INT directorate reviewer for > draft-ietf-dhc-dhcpv6-failover-protocol-03. These comments were > written primarily for the benefit of the Internet Area Directors. > Document editors and shepherd(s) should treat these comments just like > they would treat comments from any other IETF contributors and resolve > them along with any other Last Call comments that have been received. > For more details on the INT Directorate, see > http://www.ietf.org/iesg/directorate.html. > > I'm not an expert in DHCPv6, so please consider this review as a light > one. Keeping this in mind, please find my review below. > > Overall, I have not found any issue. I think the document is quite > complete and deep. Actually, my main overall comment is that it is > sometimes a bit hard to follow, due to its length and level of > complexity. Since a protocol specification has to be precise, my only > recommendation to address this would be to consider adding some > figures in Section 4, for the reader to get a first overall idea. > > Question: is there any implementation available, so some experience > gained from it can be reported (maybe as an annex)? >