Re: Review of draft-ietf-dhc-dhcpv6-failover-protocol-03
Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Sun, 15 January 2017 19:25 UTC
Return-Path: <cjbc@it.uc3m.es>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E174129668 for <ietf@ietfa.amsl.com>; Sun, 15 Jan 2017 11:25:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level:
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.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 O81uV65Y1CnE for <ietf@ietfa.amsl.com>; Sun, 15 Jan 2017 11:25:05 -0800 (PST)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAEAE129662 for <ietf@ietf.org>; Sun, 15 Jan 2017 11:25:04 -0800 (PST)
Received: by mail-wm0-x22e.google.com with SMTP id r126so133173860wmr.0 for <ietf@ietf.org>; Sun, 15 Jan 2017 11:25:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:cc:date:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=IgU4+jqUx0+7rPuiE6ZQ30ChWimMkoMae2kI6DnmGTQ=; b=p8eHHxtTTNhRSJr8U5QOidBgy5N1nOPswCaFDk7I8sF8fYFXMumXQ/gsw0EbH9LL0h RXJaEOaDlSe4Lzp3Zf80ei3koc5HRccBn/M6pgnjkVauWpwD2hPIZxJu9Fb/gAsKYPv+ RKKqRfOswjzmxF+rqCt643q/Y4vDgpRAk48bu9/C2pzGJ6RlSaUQbwOrbhJdWv1oNLDs tH6Y8uyCQkZJz7AVxXYatNjYYWe/tlbESi8wEqzttJocNiJRd8bb5wkhCo4G79knLr5a atR1AtuOSwoaJf3aOFhmAPFPk71HT0qPhVnfwlyVWQR/ogFTzUR7QMmw454KUCRdhFCM D9IA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:reply-to:to:cc:date :in-reply-to:references:organization:mime-version :content-transfer-encoding; bh=IgU4+jqUx0+7rPuiE6ZQ30ChWimMkoMae2kI6DnmGTQ=; b=mQ5oipxbjVxqi5tBv8lWBszJu/14D4hd1/ijxV4rNBpsCoxMO7ZQ9Gh+4xKNhQ81zc 6gQU4qTpUDNjSD0/C67oW6MT0mB9x+oOqzr6aAtg1XCvWEYyksQ/W8rkJcb/wm6KxLxB yqJ7aisdjn+7wlkdvm0swfqtLGxxEdY+1mJx2eHsqA8IAH34VfjS+JxCv1gy2DXK+gPZ QmAvItX2cic8Zm3YLkLurLdSYEyA4kvbNi1AXENKjJxVOOHom57VzY0igyBDUrHyGd/F kKMyyKswU9tNjKrcbpbCRzkU17wc/vEyqXzZ1q9RhRCcSqkuwKsT0EjYg/9RG6QGD7Aj nA9Q==
X-Gm-Message-State: AIkVDXLvWBGV7pmhLzE1e59vr7C0f3rGLN7H0NtWQgG0gvFVYgpARzphNToy6ZanV1p9BI20
X-Received: by 10.28.229.73 with SMTP id c70mr9027276wmh.82.1484508302987; Sun, 15 Jan 2017 11:25:02 -0800 (PST)
Received: from cjbc_dell.lan (85.251.161.16.dyn.user.ono.com. [85.251.161.16]) by smtp.gmail.com with ESMTPSA id f126sm23012858wme.22.2017.01.15.11.25.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 15 Jan 2017 11:25:01 -0800 (PST)
Message-ID: <1484508299.3758.14.camel@it.uc3m.es>
Subject: Re: Review of draft-ietf-dhc-dhcpv6-failover-protocol-03
From: Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
To: kkinnear <kkinnear@cisco.com>
Date: Sun, 15 Jan 2017 20:24:59 +0100
In-Reply-To: <93075E9F-B464-4829-98AA-12B2AA6793E1@cisco.com>
References: <148256611461.16774.460244554047859645.idtracker@ietfa.amsl.com> <93075E9F-B464-4829-98AA-12B2AA6793E1@cisco.com>
Organization: Universidad Carlos III de Madrid
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.22.3-1
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ExqV4vzs4PzdeNAMw_zEREdUp7Q>
Cc: dhcwg@ietf.org, draft-ietf-dhc-dhcpv6-failover-protocol.all@ietf.org, ietf@ietf.org, int-dir@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: cjbc@it.uc3m.es
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Jan 2017 19:25:08 -0000
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@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)? > > > >
- Review of draft-ietf-dhc-dhcpv6-failover-protocol… Carlos Bernardos
- Re: Review of draft-ietf-dhc-dhcpv6-failover-prot… kkinnear
- Re: Review of draft-ietf-dhc-dhcpv6-failover-prot… Carlos Jesús Bernardos Cano