Re: [dhcwg] draft-ietf-dhc-dhcpv6-failover-design-04.txt

"Bernie Volz (volz)" <volz@cisco.com> Mon, 16 September 2013 19:08 UTC

Return-Path: <volz@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 1820411E831C for <dhcwg@ietfa.amsl.com>; Mon, 16 Sep 2013 12:08:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.366
X-Spam-Level:
X-Spam-Status: No, score=-10.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUXWjuRi-p1V for <dhcwg@ietfa.amsl.com>; Mon, 16 Sep 2013 12:08:31 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC1411E8306 for <dhcwg@ietf.org>; Mon, 16 Sep 2013 12:08:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6622; q=dns/txt; s=iport; t=1379358505; x=1380568105; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+/eDsvI9hndeGgFJ1nQ/urAbLhrJEbubs7pR+5mTfjM=; b=NkyxxloL6snvrb1aA9/fwJW3IS6mjHoHJ7ofNn6gfxv4WBXuXKP+4K8o 0HpAkgqXLmxkxkPKTMRAtDEk2mvZ7/bwoyB9Cv37JO38CGRUMSGIC0n5D GIb/Ffpa81zHy4ud8Af+iLHw7t6V1cHOf81ONuSLM1IU9EbZzeiNhd8pq I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAKVWN1KtJXG+/2dsb2JhbABagwc4UsEAgSAWdIIlAQEBBAEBASQTNAMIDAQCAQgRBAEBCxQJBycLFAkIAgQBDQUIEYdqDLpABI9CJgsHBoMYgQADjFCSVYpKgySBaCQe
X-IronPort-AV: E=Sophos;i="4.90,917,1371081600"; d="scan'208";a="260271117"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 16 Sep 2013 19:08:02 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8GJ82g0001165 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Sep 2013 19:08:02 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.21]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Mon, 16 Sep 2013 14:08:02 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "Kim Kinnear (kkinnear)" <kkinnear@cisco.com>, "Tomek Mrugalski (tomasz.mrugalski@gmail.com)" <tomasz.mrugalski@gmail.com>
Thread-Topic: [dhcwg] draft-ietf-dhc-dhcpv6-failover-design-04.txt
Thread-Index: AQHOsMX+bkxkidD+QEGCHdnHppDy+5nIeOQA
Date: Mon, 16 Sep 2013 19:08:01 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AC805E9@xmb-rcd-x04.cisco.com>
References: <3ADDE687-5B24-4CC0-93DA-97A76F3EEAC8@cisco.com>
In-Reply-To: <3ADDE687-5B24-4CC0-93DA-97A76F3EEAC8@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.86.245.244]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-failover-design-04.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Mon, 16 Sep 2013 19:08:36 -0000

Hi:

So here's a list of the 'issues' I found with the 04 draft while review the changes. All of these are minor. I'd wait for other comments (due early next week) before considering what to do.

3.1.  Design Requirements

   The following requirements are not related to failover the mechanism
   in general, but rather to this particular design.

-- The "related to failover the mechanism" ... "the" got added in between failover/mechanism rather than in front of mechanism.

Looking at this again, I also wonder as there is only 1 item, whether "requirements" is best and whether a list is needed?

Perhaps this should just be:

"While not a requirement of the failover mechanism, this particular design attempts to minimize asymmetry -- while there are two distinct roles in failover (primary and secondary server), the differences between those two roles should be as small as possible. This will yield a simpler design as well as a simpler implementation of that design."

Or something like that? The section title is also rather odd given the content? The paragraph prior to this section references the failover requirements draft, so perhaps this should be titled "Additional Design Requirements"? Or? This isn't a big deal.

----

4. Protocol Overview
...
   used.  The MCLT is the maximum amount of time that one server can
   extend a lease for a client's binding beyond the time known by its
   failover partner.  See Section 8.4 8.3 for a detailed description how the
   MCLT affects assigned lifetimes.

-- "on" missing - "a detailed description on how"?

----

6.3.  Choosing Allocation Algorithm

   well understood.  For example in a network that delegates /64
   prefixes out of a /48 prefix (so there can be up to 65536 prefixes
   delegated) and a 1000 requesting routers, it is safe to use
   independent allocation.

-- Replace "a" in the "and with 1000 requesting routers"?

----

8.1.  Time Skew

...
   is added to the send queue of the socket (or the equivalent), as the
   application may not know about the time of the actual transmission of
   the "wire".

-- "on the "wire"", (of -> on).

----

9.4.2.  Transition Out of PARTNER-DOWN State

   o  If the partner is in: [ NORMAL, COMMUNICATIONS-INTERRUPTED,
      PARTNER-DOWN, POTENTIAL-CONFLICT, RESOLUTION-INTERRUPTED, or
      CONFLICT-DONE state ] state, then transition to POTENTIAL-CONFLICT state

-- This is minor, but drop ", then" to be consistent with the other entries in this list?

----

9.7.1.  Operation in RECOVER-DONE State

   A server in RECOVER-DONE state MUST SHOULD be unresponsive, but MAY
   respond to RENEW requests but MUST only change the state of resources
   that appear in the RENEW request.  It MUST NOT allocate any
   additional resources when in RECOVER-DONE state.

-- Comment: CONFIRM, INFORMATION-REQUEST, and REBIND were removed from this? Any reason why? I guess technically a server can even respond to SOLICIT and REQUEST messages, as long as those just deal with existing (not new) leases? But perhaps this isn't worth the effort?


I think that does it - looks great otherwise.

- Bernie

-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Kim Kinnear (kkinnear)
Sent: Friday, September 13, 2013 5:13 PM
To: dhcwg@ietf.org WG
Cc: Kim Kinnear (kkinnear)
Subject: [dhcwg] draft-ietf-dhc-dhcpv6-failover-design-04.txt


Folks,

I have just posted a new version of the DHCPv6 Failover design
draft:

	draft-ietf-dhc-dhcpv6-failover-design-04.txt

There were a large number of spelling and wording errors pointed out to us by Bernie Volz in his review, which I have fixed.  Tomek added some contributors to the acknowledgments section as well.

In addition, Bernie found several more or less substantive issues that we needed to address -- in some cases clarifying the original intent of the draft, in other cases making slight changes to the draft.  I have listed these more substantive changes below.

Regards -- Kim

---------------------

1. Section 2: Added "DDNS" and "Lease" to the Glossary.

2. Section 2: Included temporary (IA_TA) addresses in the resources that are handled by failover.

3. Section 5.1: Made attempting to connect to failover partner a MUST instead of a SHOULD, for both primary and secondary servers.

4. Section 6.1: Removed ordering requirement for POOLRESP message to be sent prior to BNDUPD triggered by POOLREQ.  Also removed implicit requirement (largely in figures) that POOLRESP contain number of resources allocated to partner.

5. Section 6.3: Removed MUST requirement for proportional algorithm support, and deferred algorithm assignment to resource allocation domain to subsequent documents.

6. Section 8.2: Removed entire section on Time Expression.  This will be addressed in any subsequent protocol document(s) produced. 

7. Old Section 8.7 (new 8.6): Removed requirement for every server to be able to support multiple binding update transactions in a single message.  Instead such use is now negotiated during connection establishment with the CONNECT and CONNECTACK message exchange.

8. Old Section 8.7 (new 8.6): Removed requirement to send the valid life time requested by DHCPv6 client in every BNDUPD.

9. Old Section 8.7 (new 8.6): Removed requirement to reject BNDUPD messages that contain (or do not contain) specific values.  Kept MUST directives for what must go into the BNDUPD, but allowed receiving code to do the best it can and not be required to reject any particular packet.

10. Old Section 8.7 (new 8.6): Removed explicit requirement for the following data items:
 o Remote-ID, defined in [RFC4649];
 o Relay-ID, defined in [RFC5460], section 5.4.1;  o Link-layer address [RFC6939]; and replaced it with a reference to the Relay Data option defined in RFC 5007 (the DHCPv6 Leasequery draft).  Along with this, moved RFC 5007 from the Informative to the Normative Bibliography section.

11. Section 9.7.1: Restricted ability of server to process messages in RECOVER-DONE state to RENEW message with no new resource allocations allowed even for RENEW message.

12. Section 9.11: Clarified reasoning for RESOLUTION-INTERRUPTED state, to avoid confusion.

[end of changes to -04.txt draft]


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg