Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-failover-protocol-02 - Respond by September 12, 2016

Marcin Siodelski <> Thu, 08 September 2016 07:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2440612B149 for <>; Thu, 8 Sep 2016 00:54:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fF5wVwDp3HE6 for <>; Thu, 8 Sep 2016 00:54:52 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EBAFE12B138 for <>; Thu, 8 Sep 2016 00:54:51 -0700 (PDT)
Received: by with SMTP id l131so15210823lfl.2 for <>; Thu, 08 Sep 2016 00:54:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=r3HXrtfPQr3yLvp9j7whIb1rr4TZ8DpK7YA6C5iWKpg=; b=j+zKfFbaXbqCpj/1ewykyuV+KEHraWFDnDobTz+cref/QBtV9LQvK6rl/5dNg7NQUI dNuIKSnD+A0KOkC1yEyBfmcMDYy6ci7CtbL8g2M5G2/zcTTTuL+JmhAsCDaGKre56Z72 PUX8yMyZjvIKSqGE0E5S8hktRkz+IOGY9F7udFyKVUJEY5eTguoVRGHQLR0vIAPVCkU3 g5J1yGPTy1VA93UikHmGWDpAabupe0qx4CKEHq/k1vh+EyCC9YPla/1lpPolXUYe1BBW Jh6roPs9Gfg6sp7DtaJVKtXiV1sRYlfz+w74nfTKkZmxM6xOqcGH7U9UYFGT/bI2+LeE BNiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=r3HXrtfPQr3yLvp9j7whIb1rr4TZ8DpK7YA6C5iWKpg=; b=cSqt3uWFTHwEozJgX0rH6nOA15xA26JN+udoY7OFh64PasTrlK0sWl9Rco520bouwg 559XPN8KQ+XBp0Z7A5ozJsMsWWHusp4n3Pe53UpfrnylS/ZmthKumEYpZ/hDIO85NlIx yKUVT2tVIxomS6RSFD9OuTnsL0FRYluI2n6HZuPe+BtXvz4nbC0NyGJy/jMRaZwAsL5Y uyNxzAov2602sA3DCxjP0f1cyyVBNJj2uCqGb/0dFNkhBUQHs3+ZJoINjK9/kJofzPeV /dFdPjvTaByAK1scJMnEdr93IyUU7qPk9QTwvoUeby7YwXEVnx5VO1K/Icvnw2ElPjpV c8Sg==
X-Gm-Message-State: AE9vXwPKN2CuFhFCcFW+QMJ1QDDyJeIVklkIyLnbaue3Yts2eZUbof/syyp+P5lja+B0Cw==
X-Received: by with SMTP id f6mr1123008lji.24.1473321289857; Thu, 08 Sep 2016 00:54:49 -0700 (PDT)
Received: from MacBook-Pro-Marcin.local ( []) by with ESMTPSA id 73sm4406355ljf.9.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Sep 2016 00:54:49 -0700 (PDT)
To: "Bernie Volz (volz)" <>, "" <>
References: <>
From: Marcin Siodelski <>
Message-ID: <>
Date: Thu, 08 Sep 2016 09:54:48 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-failover-protocol-02 - Respond by September 12, 2016
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Sep 2016 07:54:54 -0000

On 22.08.2016 01:18, Bernie Volz (volz) wrote:
> Hi all,
> This message starts the DHC Working Group Last Call to advance
> draft-ietf-dhc-dhcpv6-failover-protocol-02, DHCPv6 Failover Protocol.
> This document’s intended status is Proposed Standard. At present, there
> is no IPR file against this document.
> Please send your comments by September 12, 2016. If you do not feel this
>  document should advance, please state your reasons why.
> Note: We are trying another WGLC based on the discussion regarding this
> document led by Tomek at the Berlin (IETF-96) meeting and the feedback
> from those in attendance (see
> Bernie Volz is the assigned shepherd (Tomek is a co-author).
> - Tomek & Bernie
> PS: I decided to make this a 3 week WGLC because some may still be on
> summer holiday and because of Labor Day (September 5) in the United
> States. And, some may be need a break from reviewing
> draft-ietf-dhc-rfc3315bis-05 for the just ending WGLC (August 22^nd ).

I have read the document, which appears to be very well written and
given a lot of consideration. Given that, and the fact that
redundancy/high availability in DHCP is desired by the server operators
I strongly support advancing this document.

A couple of comments provided below.

Marcin Siodelski


1. Introduction
"The failover protocol is designed to provide lease stability for
   leases with valid lifetimes beyond a short period.  The DHCPv6
   Failover protocol MUST NOT be used for leases shorter than 30

I wonder if anywhere it should say what is the implication for a lease
(having initially a lifetime longer than 30 seconds) which is expiring
and for which the remaining valid lifetime is below 30 seconds. Plus,
what are the implications of having leases shorter than that in general.

3. Glossary
Every occurrence of "Absolute Time" in the text repeats the definition
in the glossary. This is technically ok but redundant. So, perhaps
remove the repetitions from the text?

"Delegable Prefix"
In RFC3315bis we use the term "delegated prefixes" for both assigned
prefixes (for which there are leases) and for those that haven't been
assigned. I wonder if we should make the same distinction between
delegable and delegated there.

I'd just like the two documents use the same terminology. So, this might
be more an action item for the RFC3315bis authors, rather than for the
failover authors.

Shouldn't it say: "A server that is responsive will respond to all
*valid* DHCP client requests"?

A request that is invalid will not be responded by a responsive server.

4.4.1. MCLT Example
This is slightly confusing.

"However, the desired partner lifetime will be composed of
   one half of the current actual lifetime added to the desired
   lifetime.  Thus, the failover partner is updated with a BNDUPD with a
   partner lifetime of 1/2 hour + 3 days."

First of all, the "desired partner lifetime" is not explained in section
4.4. Secondly, I am not sure why that lifetime is composed of one half
of the current lifetime plus desired lifetime. Specifically, why half of
it? Is it because the renewal time is half the lifetime? I think that
could be made clearer.

5.3.5.  UPDREQ
OLD: ...request that its partner send all binding...
NEW: ...request that its partner sends all binding...

7.1.  Time Skew
What happens if the time skew exceeds 5 seconds (perhaps significantly).
Should servers refuse to establish communication during CONNECT time?
log a warning?

Further reviewing the document I saw in section 7.5.1. that the
connection is dropped when the time skew exceeds 5 seconds, but this
seems to only refer to the BNDUPD case. Is this intended to only monitor
connection during BNDUPD?

I think it may be useful to say that the status message to the user
SHOULD be displayed/logged when the connection has dropped, giving the
reason of time skew being exceeded.

7.5.3. Processing Binding Updates
I suggest that the paragraph that talks about "better" information state
etc. refers to next section 7.5.4. saying that what is better will be
explained in that section. For a while, reading section 7.5.3. I was
trying to figure out what the "better" might mean and then I discovered
that the next section discusses that. Although, it seems that 7.5.4. is
a little broader than discussing "better" information, as it also talks
about ConfigurationConflict.

In addition, it seems to me that in general saying that some information
is better than the other is confusing and doesn't really fit into this
kind of document.

So perhaps, it is sufficient to say:

"The server receiving a BNDUPD update from its partner must evaluate
   the received information in each OPTION_CLIENT_DATA or IAPREFIX
   option to see if it is consistent with the server's already known
   state, and if it is not, decide on accepting or rejecting the
information. Section 7.5.4. provides the details how the server makes
this determination."