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

"Bernie Volz (volz)" <volz@cisco.com> Mon, 16 September 2013 21:57 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 3103711E819E for <dhcwg@ietfa.amsl.com>; Mon, 16 Sep 2013 14:57:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.413
X-Spam-Level:
X-Spam-Status: No, score=-10.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 9VU9WVv2bHdy for <dhcwg@ietfa.amsl.com>; Mon, 16 Sep 2013 14:57:34 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2483E11E819C for <dhcwg@ietf.org>; Mon, 16 Sep 2013 14:57:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8253; q=dns/txt; s=iport; t=1379368654; x=1380578254; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0fvwybYieOuYws1od/QTHhV4LcUNfqmlOOiTVP3bYaE=; b=mqv1+xcnhzjR0OoCuOvBmuVRwW+7ec2vLHtgBcWWpzZwNeR6GH4pOwnp bCG/d1zhC1+hcx0rNuCzFNxbCGh7XLgmgD395+xIp0GgVJzTXuUM60TjX /lgvf71Rm/t74B2WwYkKKRxDL+u7X4CkYhp6gj/CTWH4KZjPYf75+FroZ 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAHh+N1KtJV2a/2dsb2JhbABagwc4UsEDgSIWdIIlAQEBBAEBASQTNAMIDAQCAQgRBAEBCxQJByEGCxQJCAIEAQ0FCBGHWAMPDLEODYk3BI0Fgj0mCwcGgxiBAAOMUIlCiROFF4UzgySBaCQe
X-IronPort-AV: E=Sophos;i="4.90,918,1371081600"; d="scan'208";a="260607326"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 16 Sep 2013 21:57:33 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8GLvXJH024141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Sep 2013 21:57:33 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.21]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Mon, 16 Sep 2013 16:57:33 -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+5nIeOQAgABwCSA=
Date: Mon, 16 Sep 2013 21:57:32 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AC80B82@xmb-rcd-x04.cisco.com>
References: <3ADDE687-5B24-4CC0-93DA-97A76F3EEAC8@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AC805E9@xmb-rcd-x04.cisco.com>
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AC805E9@xmb-rcd-x04.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 21:57:39 -0000

Kim and I discussed the issue with section 9.7.1 that I raised.

That actually raised a new issue in that 9.6.1 and 9.7.1 should have the same "operation".

Kim will think about what to write for both of these sections (RECOVER-WAIT + RECOVER-DONE). The bottom line is that if communication with the partner is up, it most likely is in NORMAL state and fully responsive so the recovering server can be unresponsive. However, if the partner communication is down or the partner is not in a responsive state, there are benefits to the recovering server honoring requests (perhaps RENEWs, CONFIRMs, and INFORMATION-REQUEST) but it MUST NOT allocate any new resources to clients as it doesn't know if it might have allocated those resources (to other clients) before losing its database.

Keeping things simple would argue for the recovering server being unresponsive; but there are benefits if the server is partially responsive (such as to RENEWs or even other requests, of course with the restriction that it not allocate any new resources to a client in these states) if the partner is down or also recovering.

- Bernie

-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Monday, September 16, 2013 3:08 PM
To: Kim Kinnear (kkinnear); Tomek Mrugalski (tomasz.mrugalski@gmail.com)
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-failover-design-04.txt

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
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg