Re: Review of draft-ietf-dhc-dhcpv6-failover-protocol-03

[Carlos Jesús Bernardos Cano <[e-mail]>]

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 <[e-mail]>
> > 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)?
> > 
> 
>