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

kkinnear <kkinnear@cisco.com> Wed, 11 January 2017 20:27 UTC

Return-Path: <kkinnear@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31E91297D0; Wed, 11 Jan 2017 12:27:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.721
X-Spam-Level:
X-Spam-Status: No, score=-17.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bd03gk1X4AWp; Wed, 11 Jan 2017 12:26:59 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7CD31289C4; Wed, 11 Jan 2017 12:26:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6137; q=dns/txt; s=iport; t=1484166418; x=1485376018; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=oUEQmMxfEFxCp788gMc1KHTMQc/JzCk0veG6MF4qdKc=; b=Lrln7g3gGt+pjx83cZCuetZK2JhIYl35uRpA5U3/yD/UQxUpR1k5Ldjz VAK7QNDqjf7t1t0ebJpfFBRJtN2FBiswmiyzkGGORJLmjfQbJlnvKP9+U UsHAdYXySMh6OHfr70sCs/6WpZ68JLAgmucOiLgceiX1Tofip7V6iHSIc Y=;
X-IronPort-AV: E=Sophos;i="5.33,346,1477958400"; d="scan'208";a="191703649"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Jan 2017 20:26:58 +0000
Received: from dhcp-161-44-67-122.cisco.com (dhcp-161-44-67-122.cisco.com [161.44.67.122]) (authenticated bits=0) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v0BKQv12028626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jan 2017 20:26:57 GMT
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: kkinnear <kkinnear@cisco.com>
In-Reply-To: <148256611461.16774.460244554047859645.idtracker@ietfa.amsl.com>
Date: Wed, 11 Jan 2017 15:26:57 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <93075E9F-B464-4829-98AA-12B2AA6793E1@cisco.com>
References: <148256611461.16774.460244554047859645.idtracker@ietfa.amsl.com>
To: Carlos Bernardos <cjbc@it.uc3m.es>
X-Mailer: Apple Mail (2.3124)
X-Authenticated-User: kkinnear@cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/2lwphYJcb_GDpF5k9MbfplyZXq8>
Cc: dhcwg@ietf.org, int-dir@ietf.org, ietf@ietf.org, draft-ietf-dhc-dhcpv6-failover-protocol.all@ietf.org, Kim Kinnear <kkinnear@cisco.com>
Subject: Re: [dhcwg] Review of draft-ietf-dhc-dhcpv6-failover-protocol-03
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Jan 2017 20:27:01 -0000

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@it.uc3m.es> 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)?
>