Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-failover-protocol-02 - Respond by September 12, 2016

From: Kim Kinnear <[email-masked]>
Date: Thu, 1 Sep 2016 09:33:17 -0400

Naiming,

Sure, we can clarify that.  The "on the same network" comment was not,
actually, about where the clients connect at all.  The "on the same
network" phrase was *trying* say that the two DHCPv6 servers could
communicate with each other.  It is assumed that some (most) of the
DHCPv6 clients will be communicating with the DHCPv6 server through
DHCPv6 relays.

We will fix this along with other comments that come in during WGLC.

If you think this document should be moved forward, please send a
comment saying that.  If not, please send a comment saying *that* and
why you don't think it should move forward.

Thanks!

Kim

> On Aug 31, 2016, at 8:31 PM, Naiming Shen (naiming) <[email-masked]> wrote:
> 
> 
> Hi authors,
> 
> I have a simple comment on the document. In the section of abstract,
> it mentioned the two servers ‘on the same network’. This is obvious true
> for the case of serving DHCPv6 request directly from the clients on the
> same network. I’m just wondering how does this work if the server is remote
> and through some DHCPv6 relays. Can we put some text to clarrify this.
> 
> thanks.
> - Naiming
> 
>> On Aug 21, 2016, at 4:18 PM, Bernie Volz (volz) <[email-masked]> wrote:
>> 
>> Hi all,
>>  
>> This message starts the DHC Working Group Last Call to advance draft-ietf-dhc-dhcpv6-failover-protocol-02, DHCPv6 Failover Protocol. This document’s intended status is Proposed Standard. At present, there is no IPR file against this document.
>>  
>> Please send your comments by September 12, 2016. If you do not feel this  document should advance, please state your reasons why.
>>  
>> Note: We are trying another WGLC based on the discussion regarding this document led by Tomek at the Berlin (IETF-96) meeting and the feedback from those in attendance (seehttps://www.ietf.org/proceedings/96/minutes/minutes-96-dhc).
>>  
>> Bernie Volz is the assigned shepherd (Tomek is a co-author).
>>  
>> - Tomek & Bernie
>>  
>> PS: I decided to make this a 3 week WGLC because some may still be on summer holiday and because of Labor Day (September 5) in the United States. And, some may be need a break from reviewing draft-ietf-dhc-rfc3315bis-05 for the just ending WGLC (August 22nd).
>>  
>> _______________________________________________
>> dhcwg mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dhcwg
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Thu, 1 Sep 2016 14:26:18 +0000

Kim,

Thanks for the clarification. Since the two servers using TCP to
communicate with each other and with explicit user provisioning,
I’m wondering this ‘on the same network’ term is needed here.

thanks.
- Naiming

> On Sep 1, 2016, at 6:33 AM, Kim Kinnear (kkinnear) <[email-masked]> wrote:
> 
> Naiming,
>

---

From: Kim Kinnear <[email-masked]>
Date: Thu, 1 Sep 2016 11:05:15 -0400

> On Sep 1, 2016, at 10:26 AM, Naiming Shen (naiming) <[email-masked]> wrote:
> 
> 
> Kim,
> 

	No, I think that is isn't needed here, I agree.  I
	will fix that in the next edit.

	Thanks.

	By the way, could you *please* either say that you think
	this document should or should not move forward?

	Thanks -- Kim

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Thu, 1 Sep 2016 16:26:06 +0000

Kim,

Sure. this document should move forward.

thanks.
- Naiming

On Sep 1, 2016, at 8:05 AM, Kim Kinnear (kkinnear) <[email-masked]<mailto:[email-masked]>> wrote:

On Sep 1, 2016, at 10:26 AM, Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>> wrote:

Kim,

Thanks.

Thanks -- Kim

thanks.
- Naiming

On Sep 1, 2016, at 6:33 AM, Kim Kinnear (kkinnear) <[email-masked]<mailto:[email-masked]>> wrote:

Naiming,

Thanks!

Kim

On Aug 31, 2016, at 8:31 PM, Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>> wrote:

Hi authors,

thanks.
- Naiming

On Aug 21, 2016, at 4:18 PM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

- Tomek & Bernie

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

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 6 Sep 2016 01:36:13 +0000

Hi:

<WG chair hat off>

Having based an implementation on much of what is here (though we did use different messages and vendor options for those items still requiring option assignments) and in reviewing this document (several times now), I fully support seeing it move forward.

A few minor nits in the 02 version:

-          Delegated is misspelled as deletegated in section 3.

-          Transaction-is is misspelled as tranasction-id in section 5.4.

-          Bernie

From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Sunday, August 21, 2016 7:18 PM
To: [email-masked]
Subject: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-failover-protocol-02 - Respond by September 12, 2016

Hi all,

This message starts the DHC Working Group Last Call to advance draft-ietf-dhc-dhcpv6-failover-protocol-02, DHCPv6 Failover Protocol. This document's intended status is Proposed Standard. At present, there is no IPR file against this document.

Note: We are trying another WGLC based on the discussion regarding this document led by Tomek at the Berlin (IETF-96) meeting and the feedback from those in attendance (see https://www.ietf.org/proceedings/96/minutes/minutes-96-dhc).

- Tomek & Bernie

---

From: Marcin Siodelski <[email-masked]>
Date: Thu, 8 Sep 2016 09:54:48 +0200

On 22.08.2016 01:18, Bernie Volz (volz) wrote:
> Hi all,
> 
>  
> 
> This message starts the DHC Working Group Last Call to advance
> draft-ietf-dhc-dhcpv6-failover-protocol-02, DHCPv6 Failover Protocol.
> This document’s intended status is Proposed Standard. At present, there
> is no IPR file against this document.
> 
>  
> 
> Please send your comments by September 12, 2016. If you do not feel this
>  document should advance, please state your reasons why.
> 
>  
> 
> Note: We are trying another WGLC based on the discussion regarding this
> document led by Tomek at the Berlin (IETF-96) meeting and the feedback
> from those in attendance (see
> https://www.ietf.org/proceedings/96/minutes/minutes-96-dhc).
> 
>  
> 
> PS: I decided to make this a 3 week WGLC because some may still be on
> summer holiday and because of Labor Day (September 5) in the United
> States. And, some may be need a break from reviewing
> draft-ietf-dhc-rfc3315bis-05 for the just ending WGLC (August 22^nd ).
> 
>  

I have read the document, which appears to be very well written and
given a lot of consideration. Given that, and the fact that
redundancy/high availability in DHCP is desired by the server operators
I strongly support advancing this document.

A couple of comments provided below.

Marcin Siodelski

---------

1. Introduction
"The failover protocol is designed to provide lease stability for
   leases with valid lifetimes beyond a short period.  The DHCPv6
   Failover protocol MUST NOT be used for leases shorter than 30
   seconds."

I wonder if anywhere it should say what is the implication for a lease
(having initially a lifetime longer than 30 seconds) which is expiring
and for which the remaining valid lifetime is below 30 seconds. Plus,
what are the implications of having leases shorter than that in general.

3. Glossary
Every occurrence of "Absolute Time" in the text repeats the definition
in the glossary. This is technically ok but redundant. So, perhaps
remove the repetitions from the text?

"Delegable Prefix"
In RFC3315bis we use the term "delegated prefixes" for both assigned
prefixes (for which there are leases) and for those that haven't been
assigned. I wonder if we should make the same distinction between
delegable and delegated there.

I'd just like the two documents use the same terminology. So, this might
be more an action item for the RFC3315bis authors, rather than for the
failover authors.

"Responsive"/"Unresponsive"
Shouldn't it say: "A server that is responsive will respond to all
*valid* DHCP client requests"?

A request that is invalid will not be responded by a responsive server.

4.4.1. MCLT Example
This is slightly confusing.

"However, the desired partner lifetime will be composed of
   one half of the current actual lifetime added to the desired
   lifetime.  Thus, the failover partner is updated with a BNDUPD with a
   partner lifetime of 1/2 hour + 3 days."

First of all, the "desired partner lifetime" is not explained in section
4.4. Secondly, I am not sure why that lifetime is composed of one half
of the current lifetime plus desired lifetime. Specifically, why half of
it? Is it because the renewal time is half the lifetime? I think that
could be made clearer.

5.3.5.  UPDREQ
OLD: ...request that its partner send all binding...
NEW: ...request that its partner sends all binding...

7.1.  Time Skew
What happens if the time skew exceeds 5 seconds (perhaps significantly).
Should servers refuse to establish communication during CONNECT time?
log a warning?

Further reviewing the document I saw in section 7.5.1. that the
connection is dropped when the time skew exceeds 5 seconds, but this
seems to only refer to the BNDUPD case. Is this intended to only monitor
connection during BNDUPD?

I think it may be useful to say that the status message to the user
SHOULD be displayed/logged when the connection has dropped, giving the
reason of time skew being exceeded.

7.5.3. Processing Binding Updates
I suggest that the paragraph that talks about "better" information state
etc. refers to next section 7.5.4. saying that what is better will be
explained in that section. For a while, reading section 7.5.3. I was
trying to figure out what the "better" might mean and then I discovered
that the next section discusses that. Although, it seems that 7.5.4. is
a little broader than discussing "better" information, as it also talks
about ConfigurationConflict.

In addition, it seems to me that in general saying that some information
is better than the other is confusing and doesn't really fit into this
kind of document.

So perhaps, it is sufficient to say:

"The server receiving a BNDUPD update from its partner must evaluate
   the received information in each OPTION_CLIENT_DATA or IAPREFIX
   option to see if it is consistent with the server's already known
   state, and if it is not, decide on accepting or rejecting the
information. Section 7.5.4. provides the details how the server makes
this determination."