Subject: [Gen-art] Gen-art LC review: draft-ietf-dhc-dhcpv6-failover-requirements-06

From: Elwyn Davies <[email-masked]>
Date: Sat, 06 Jul 2013 14:01:37 +0100

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-dhc-dhcpv6-failover-requirements-06.txt
Reviewer: Elwyn Davies
Review Date: 6 July 2013
IETF LC End Date: 17 July 2013
IESG Telechat date: (if known) -

Summary: Almost ready.  There are a few very minor issues and a fair
number of editorial nits to fix but generally in good shape.

Major issues:
None

Minor issues:
s1, Introduction of Primary/Secondary terminology: The introduction
talks about multiple servers (i.e., potentially > 2) but then in the
last sentence of para 1 introduces primary and secondary servers.  The
initial impression this gives is that the number of servers has now been
reduced to <= 2.  Having read through the rest of the document I can see
how I am supposed to interpret the last sentence of para 1, but things
would be much clearer if an extra sentence or three describing the
chosen model (and its intended extension) was added just before this
last sentence.  Maybe something like:
   The failover model, to which these requirements apply, will initially
   be a pairwise "hot standby" model (see Section 4.1) with a primary 
   server used in normal operation switching over to a backup secondary 
   server in the event of failure.  Optionally, a secondary server may 
   provide failover service for multiple primary servers.  However the 
   requirements will not preclude a future load-balancing extension 
   where there is a symmetric failover relationship. 

s7: Related to the previous comment, perhaps it should be made explicit
that the resulting protocol is "load-balancing friendly" to avoid rework
if at all possible.  Since both v4 and v6 load-balancing and v4 failover
with load-balancing are in progress, it should be known how to avoid
pitfalls by the time the v6 failover protocol is designed!

s7, item 4, last sentence: 
"Long-lived connections must not be disturbed."
I don't believe the DHCPv6 server or the failover protocol can either
know that an address is in use for long lived connections or guarantee
that they won't be disturbed beyond what is said earlier in this item.
Presumably what is meant is something like: "Lease stability has the aim
of avoiding disturbance to long-lived connections."

s7, item 6:  Maybe irrelevant thought: Presumably you could build a
failover system using a shared, reliable database and a minimalistic
version of the failover protocol instead of using lazy updates.  Should
this be explicitly an option?

s7, last para: "Despite the lack of standardization of DHCPv4
failover...": It appears that work is in progress on this
(http://tools.ietf.org/html/draft-ietf-dhc-failover-12)... so what is
meant here?

Nits/editorial comments:

Global: s/i.e./i.e.,/
Global: s/e.g./e.g.,/

Abstract: s/any way/any way that/

s2: Expoand acronyms CPR, IA - even though IA is defined in RFC 3315, it
would help readability to repeat the expansion.

s2, lease: Should this mention something about length of time for which
the lease will be valid?

s3.1.1: Expand PXE acronym.

s3.1.1, para 1:
OLD
   Address and possibly other
   configuration parameters are used during boot process and are
   discarded afterwards. 
NEW:
   The address and possibly other
   configuration parameters are used during the boot process and are
   discarded thereafter. 

s3.1.1, para 2: s/distinct preference set/a distinct preference set/

s3.1.2, para 2:
OLD:
   There are several well documented approaches how such deployment
   works. 
NEW:
   There are several well-documented approaches showing how such a deployment
   could work.

s3.1.3, para 2:
OLD:
   It is also essential to use only databases that are really
   distributed and do not have single point of failure themselves.
NEW:
   It is also essential to use only a database system that provides 
   equivalent reliability and failover capability. 

s4: This paragraph implies that the document defines a protocol contrary
to its expressed intention and reality.
OLD:
   These scenarios may be inside or
   outside of scope for DHCPv6 failover protocol as defined by this
   document.  They are enumerated here to provide a common basis for
   discussion.
NEW:
   These scenarios may be in or
   out of scope for the DHCPv6 failover model to which this 
   document's requirements apply; they are enumerated here to provide a 
   common basis for discussion.   

s5, para 2: s/General failover concept/The general failover concept/, 
s/in case of the primary server/in case of a primary server/,
s/In case of just/In the case of just/,
s/Had there be more than two partners/Were there more than two partners/
(subjunctive!)

s5, para 2:
OLD:
   there would be a third states in between (some
   partners updated their state, but some didn't).
NEW:
   there would be intermediate, inconsistent states where some partners
   had updated their state and some had not.

s4.1: s/Only one of partners/Only one of the partners/

s4.6, para 2: s/every time IPv6 address changes/every time an IPv6
address changes/

s4.6, para 3: s/having stable address/having a stable address/

s5.1, last sentence:  This seems to imply that *this section* states
whether the failure mode is in or out of scope for the protocol.  It
doesn't - that is postponed to s7.  Either remove this sentence or
redraft to refer to s7.

s5.1.2, para 2: s/is that partner also detected/is that the partner also
detected/

s5.2: s/synchronization methods/synchronization method/,
s/familiarity with distributed database/familiarity with distributed database technology/

s5.2.1, para 1: s/response from partner/response from its partner/

s5.2.1, para 2: 'large' is an over-generalization. Maybe:
s/a large performance penalty/typically a significant performance penalty/

s5.2.1, para 3:
OLD:
Due to advent of SSD disks or battery backed ram disks technology,
NEW:
Due to the advent of fast SSD (solid state disk) and battery-backed RAM 
(random access memory) disk technology,

s5.2.2, para 2: s/if server crashes/if the server crashes/

s7, item 4: s/should pose/should have/

---

From: Jari Arkko <[email-masked]>
Date: Tue, 16 Jul 2013 09:36:37 +0200

Thank you for your review, Elwyn. Do the authors have any thoughts on the issues that Elwyn raises here?

Jari

On Jul 6, 2013, at 3:01 PM, Elwyn Davies <[email-masked]> wrote:

> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Kim Kinnear <[email-masked]>
Date: Tue, 16 Jul 2013 10:38:05 -0400

Jari, Elwyn,

Elwyn -- thank you for the thoughtful review.  My comments
are indented below...

>>  where there is a symmetric failover relationship. 

	Yes, this is a fine idea.  Thanks for the sentence.
>> pitfalls by the time the v6 failover protocol is designed!

	Sure, we'll put something in to deal with that.
>> of avoiding disturbance to long-lived connections."

	Yes, we'll reword this as you suggest.
>> this be explicitly an option?

	Well, this thought is explored in Section 3.1.3, but under
	the overall heading of "Alternatives to Failover".  Is this
	an alternative *to* failover, or an option *for* failover 
	(as you suggest might be appropriate)?  Hard to say. 
 
	I suppose that our design draft, already about to go to
	last call, influenced our thinking to some degree when we
	wrote this.  I don't think the document would be substantively
	better were we to change it so that a distributed database
	solution is an option as opposed to an alternative.  So,
	to be clear, I don't think changing this is a good idea.

>> (http://tools.ietf.org/html/draft-ietf-dhc-failover-12)... so what is

	The work in progress ended years ago.  Many years ago.
	The document which you reference is ~132 pages long, and
	has requirements, design, and protocol all in one
	document.  It was essentially too big and complicated to
	be digested by the IETF.  We could not even get the AD at
	the time to review the entire document.  In part this was
	because the problem was important to solve in an
	intra-vendor way, but inter-vendor capable failover was
	not important in the real world (i.e., nobody really
	cared to pay extra for failover that worked across two
	vendors servers).

	The experience gained during the v4 failover effort is
	the reason the v6 failover effort (of which the document
	under discussion is a part) has been split into three
	separate pieces: requirements, design, and (if sufficient
	interest exists), protocol.  The hope is that these
	pieces will be individually digestible where the v4
	effort was not.

	That said, the v6 failover design draft is already 50
	pages, and it hasn't yet undergone WG last call, though
	it is very close to that point.  

	Plus, it is possible that we will end with the design
	document, since that will have the basics of how you
	build a v6 failover capability.  The protocol document is
	only really interesting if you want to have an
	inter-vendor failover capability.  We don't yet know how
	that will play out, though we certainly expect to give
	it a try.
>> Nits/editorial comments:

	Thank you for catching these.  We will make all of these
	changes.

	Thanks again for your review!

	Regards -- Kim

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 17 Jul 2013 15:41:38 +0100

Hi, Kim.

Thanks for the reponses.

Looks like we are pretty well agreed. Just these two points: 

On s7, item 6: Just a thought so I'll consider it irrelevant.

On the last para of 7, I clearly failed to notice the date on the draft
for DHCPv4 failover protocol! [The hazards of an infinite archive for
I-Ds!]  So I understand why this probably isn't  going to go all the way
to an inter-operable protocol for either v4 or v6.  Perhaps it might be
worth adding in a few words to explain this (and improve an editorial
nit I missed):
OLD:
   Despite the lack of standardization of DHCPv4 failover, the
   coexistence of DHCPv4 and DHCPv6 failover may be taken into
   consideration.  In particular, certain features that are common for
   both IPv4 and IPv6, like DNS Update mechanism should be taken into
   consideration. 
NEW:
   Although progress on a standardized inter-operable DHCPv4 failover
   protocol has stalled, vendor-specific DHCPv4 failover protocols 
   have been deployed that meet these requirements to a large extent.
   Accordingly it would be appropriate to take into account the likely 
   coexistence of DHCPv4 and DHCPv6 failover solutions.  In particular, 
   certain features that are common to both IPv4 and IPv6 
   implementations, such as any DNS Update mechanism, should be taken into
   consideration to ensure compatible operation.

Regards,
Elwyn

---

From: Kim Kinnear <[email-masked]>
Date: Wed, 17 Jul 2013 11:38:18 -0400

Elwyn,

I love the "NEW" paragraph below.  We'll be sure to
use that.  

Thanks!

Kim

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 17 Jul 2013 22:54:54 +0100

:-)

---

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 18 Jul 2013 19:34:30 +0200

>    consideration to ensure compatible operation.
Hi Elwyn,

Thanks a lot for your thorough review and comments. The submission tool
is now closed, so I have put an unpublished -07 version here:
https://github.com/tomaszmrugalski/ietf-dhcpv6-fo/
We will upload it to IETF once the submission tool reopens.

I hope I didn't miss any comments. Please let me know if I did.

Tomek

---

From: Elwyn Davies <[email-masked]>
Date: Mon, 22 Jul 2013 11:21:59 +0100

Hi, Tomak and Kim.

I had a quick look through -07 and it appeared to have fixed all my
quibbles.

I see the draft has now been approved - so hopefully it will progress to
RFC RSN!

Regards,
Elwyn