Subject: [dhcwg] Last Call: <draft-ietf-dhc-dhcpv6-failover-requirements-06.txt> (DHCPv6 Failover Requirements) to Informational RFC

From: The IESG <[email-masked]>
Date: Wed, 03 Jul 2013 13:56:58 -0700

The IESG has received a request from the Dynamic Host Configuration WG
(dhc) to consider the following document:
- 'DHCPv6 Failover Requirements'
  <draft-ietf-dhc-dhcpv6-failover-requirements-06.txt> as Informational
RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2013-07-17. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   The DHCPv6 protocol, defined in [RFC3315] allows for multiple servers
   to operate on a single network, however it does not define any way
   the servers could share information about currently active clients
   and their leases.  Some sites are interested in running multiple
   servers in such a way as to provide increased availability in case of
   server failure.  In order for this to work reliably, the cooperating
   primary and secondary servers must maintain a consistent database of
   the lease information.  [RFC3315] allows for but does not define any
   redundancy or failover mechanisms.  This document outlines
   requirements for DHCPv6 failover, enumerates related problems, and
   discusses the proposed scope of work to be conducted.  This document
   does not define a DHCPv6 failover protocol.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-requirements/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-requirements/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Sten Carlsen <[email-masked]>
Date: Thu, 04 Jul 2013 02:29:10 +0200

I wonder if it is beneficial to limit the failover to just two partners
at this level of specification? I should think there should be freedom
for people to consider the option of more than just two partners at this
stage; the definition of the actual protocol could easily limit the case
to just two partners until somebody comes up with a viable scheme for
more than two partners. As written it will take much more effort to
allow for more than two partners, should that be desired in the future.

On 03/07/13 22:56, The IESG wrote:
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

-- 
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Jul 2013 01:08:28 +0000

On Jul 3, 2013, at 8:29 PM, Sten Carlsen <[email-masked]> wrote:
> I wonder if it is beneficial to limit the failover to just two partners at this level of specification? I should think there should be freedom for people to consider the option of more than just two partners at this stage; the definition of the actual protocol could easily limit the case to just two partners until somebody comes up with a viable scheme for more than two partners. As written it will take much more effort to allow for more than two partners, should that be desired in the future.

This document is a list of requirements for the failover protocol that the DHC working group intends to develop.   Its purpose is to state the goals of the current development effort.   Why would this document prevent someone from subsequently developing a 3-way or N-way protocol if they decided that it made sense? It's not even a BCP, so it's not in any way normative.

---

From: Sten Carlsen <[email-masked]>
Date: Thu, 04 Jul 2013 16:02:04 +0200

> This document is a list of requirements for the failover protocol that the DHC working group intends to develop.   Its purpose is to state the goals of the current development effort.   Why would t…
Well this text:
~~~~
5. Principles of DHCPv6 Failover

.......

Had there be more than two partners participating
   in a relationship, there would be a third states in between (some
   partners updated their state, but some didn't).  This would greatly
   complicate protocol design, and would give little advantage in
   return.  /_Therefore an approach that assumes a pair of cooperating
   servers was chosen_/.

~~~~

as well as the all of "7. DHCPv6 Failover Requirements" which
specifically limits failover to " 1.   The number of supported partners
must be _exactly two_, i.e. there are _at most two servers that are
aware of a specific lease._"

This and more text will, I believe severely limit the developments to
only look at the two server solutions. The text may not be normative but
I feel sure it will be read as such. I still feel this is too limiting.

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Jul 2013 14:32:12 +0000

On Jul 4, 2013, at 10:02 AM, Sten Carlsen <[email-masked]> wrote:
>    return.  
> Therefore an approach that assumes a pair of cooperating
>    servers was chosen
> .
> ~~~~
> 
> as well as the all of "7. DHCPv6 Failover Requirements" which specifically limits failover to " 1.   The number of supported partners must be exactly two, i.e. there are at most two servers that are aware of a specific lease."
> 
> This and more text will, I believe severely limit the developments to only look at the two server solutions. The text may not be normative but I feel sure it will be read as such. I still feel this is too limiting.

Sten, I have no idea what substantive point you are attempting to make here.   The working group has in fact considered how to write a failover protocol, and they have concluded that the current effort will focus on a two-peer solution, because that is easier and more efficient.   If you disagree that it is easier, or disagree that it is more efficient, these would be valid points to raise, assuming you could justify them.

Simply saying "the people who are working on failover in the DHC working group should consider N-way solutions rather than 2-way solutions" is not substantive, in particular because the working group _has_ considered N-way solutions, decided not to go that way, and documented that decision in the very draft you are commenting on.

You're an active participant in the DHC working group, and you did not raise this point during the working group last call.   The only point raised on the document during working group last call was raised by Steinar Haug; the document was updated to address his concern, he said he was happy, and the document then passed working group last call with nobody, including you, claiming to be in the rough.

So why are you raising this point now, during the IETF last call?

---

From: Sten Carlsen <[email-masked]>
Date: Thu, 04 Jul 2013 17:07:48 +0200

> So why are you raising this point now, during the IETF last call?
I took the opportunity to read the full length document one last time,
probably late. Then it ocurred to me that the wording would seem to
prohibit later efforts to look at N-way failover. I had no intention to
say the working group should go with anything else but a 2-way approach
as that obviously is easier and has served IPv4 well.

If you don't think the above text will prohibit future N-way
development, I am happy.

I wish I had more time to spend here but other tasks are also calling.

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Jul 2013 15:21:00 +0000

On Jul 4, 2013, at 11:07 AM, Sten Carlsen <[email-masked]> wrote:
> If you don't think the above text will prohibit future N-way development, I am happy.

Okay, thanks.   The document is informational, so it doesn't place any requirements on anyone regarding anything.   So in fact the text does not prevent future n-way development.   It's just the working group saying "here is the functionality we intend to try to deliver."

---

From: Sten Carlsen <[email-masked]>
Date: Thu, 04 Jul 2013 17:26:56 +0200

Ok, my head, being normally kept in a non-English speaking nation, did
not feel certain about that fact. Sorry for the noise.

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"