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

From: Kim Kinnear <[email-masked]>
Date: Fri, 13 Sep 2013 17:12:39 -0400

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]

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 16 Sep 2013 19:08:01 +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: [email-masked] [mailto:[email-masked]] On Behalf Of Kim Kinnear (kkinnear)
Sent: Friday, September 13, 2013 5:13 PM
To: [email-masked] WG
Cc: Kim Kinnear (kkinnear)
Subject: [dhcwg] draft-ietf-dhc-dhcpv6-failover-design-04.txt

Folks,

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

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

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.

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 16 Sep 2013 21:57:32 +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: [email-masked] [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Monday, September 16, 2013 3:08 PM
To: Kim Kinnear (kkinnear); Tomek Mrugalski ([email-masked])
Cc: [email-masked]
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-failover-design-04.txt

Hi:

3.1.  Design Requirements

----

4. Protocol Overview
...

----

----

8.1.  Time Skew

...

----

----

- Bernie

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

Folks,

Regards -- Kim

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