Re: [dhcwg] 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: 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 B0954129662 for <dhcwg@ietfa.amsl.com>; Sun, 15 Jan 2017 11:25:09 -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 bhh_VV4i5oeq for <dhcwg@ietfa.amsl.com>; Sun, 15 Jan 2017 11:25:08 -0800 (PST)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 C0197129665 for <dhcwg@ietf.org>; Sun, 15 Jan 2017 11:25:04 -0800 (PST)
Received: by mail-wm0-x232.google.com with SMTP id d140so7526627wmd.0 for <dhcwg@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=A29HLZFYcIpfpHgOl2XdZNH6zZTbJ1m4sw6JEEuY+QnvrPSSttFe+3pXcrBiwK75NK GJZsZE1mRFT6Zh1zypMqMjMTqEH8LKd8GZGE7yawGj1NpCBlaEJB4s7/HPUYustojsWX HdjtukoK7iKWUF6XC8pvEpL3Twok/zTEX4LMlIcWjaGAvulH4Lzmmbb5dMusr00Eb15h Q9Y7zD/XW7vDR9Vtc6QNRoUqRLk1AjG7LFs6sZQswCkJ7LV+wNT8/Rct9whxABEkV4VF hoHGsH8aOaQARRuleHudNDsIbt9R9XebpmEvVhax1CZ1x+sa6oAav8kUfegv/D+iaIrw HUOw==
X-Gm-Message-State: AIkVDXL9MjQIlEpBlw65tZY1GXdvInKKyukar19SRuGvdTKDIWb7wn/+qAs73U3tb+odceYM
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>
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/dhcwg/woNixu3VNl-rE2XX8YMKf2Ekh4c>
Cc: dhcwg@ietf.org, draft-ietf-dhc-dhcpv6-failover-protocol.all@ietf.org, ietf@ietf.org, int-dir@ietf.org
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
Reply-To: cjbc@it.uc3m.es
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: Sun, 15 Jan 2017 19:25:10 -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)? > > > >
- [dhcwg] Review of draft-ietf-dhc-dhcpv6-failover-… Carlos Bernardos
- Re: [dhcwg] Review of draft-ietf-dhc-dhcpv6-failo… kkinnear
- Re: [dhcwg] Review of draft-ietf-dhc-dhcpv6-failo… Carlos Jesús Bernardos Cano