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 =?ISO-8859-1?Q?Jes=FAs?= 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)?
> > 
> 
>