Hi Kim, Thanks a lot for the additional explanations. They definitely help. I also like the new figure. Thanks, Carlos On Wed, 2017-01-11 at 15:26 -0500, kkinnear wrote: > 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)? > > > >