Subject: [dhcwg] Review of draft-ietf-dhc-dhcpv6-failover-protocol-00

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 30 Nov 2015 14:52:30 +0000

Hi:

I have reviewed draft-ietf-dhc-dhcpv6-failover-protocol-00. I have lots of minor nits which I will provide these to Kim directly (marked up on a paper copy) instead of here.

For the others that volunteered to review at IETF-94 meeting (Ted, Marcin, Jinmei, and Shawn), if you haven't started, it may make sense to wait until Kim updates the document.

So here's the list of (mostly) non-nits:

-          There is no port for failover mentioned. I presume the IANA assigned Failover Port (647) will be used?

And, as these are not DHCPv6 messages then, perhaps the DHCPv6 message registry is not appropriate?

This does raise an interesting question though with the (long ago abandoned) DHCPv4 failover draft. As there are existing implementations of that protocol, we should likely ask IANA to set up a new DHCP Failover Message registry and reserve the message numbers from draft-ietf-dhc-failover (messages 1-12).

-          Perhaps "DHCP" should be used throughout this document instead of "DHCPv6" (DHCPv6 can be used at the start). It is pretty clear that this is all about DHCPv6? (RFC 3315 used DHCP in most places.) I'd also suggest replacing "DHCPv6 client" with just "client"?

-          DDNS (Dynamic DNS) should probably just be "DNS Update" or similar? The Dynamic part has pretty much been dropped these days?

-          Resource could be replaced with lease? We are moving in that direction with the RFC3315 bis document.

-          4.2.1.1 (Independent Allocation Algorithm) - the "low order" bit is 127 not 15.

-          BNDUPD/BNDACK are defined to allow bulking; I think this should be simplified to not allow bulking (one message per client or lease).

-          BNDUPD/BNDACK are defined to only support OPTION_CLIENT_DATA as container; this must be modified to support an IA_* option directly as there are cases where there may not be a client associated with a lease (consider pool rebalancing). So, a BNDUPD can contain an OPTION_CLIENT_DATA or an IA_* option.

-          7.1 (Time Skew) - Should we require NTP to synchronize the clocks on failover partners?

-          7.2 (Informational Model) - I think there needs to be an additional state (i.e., something like DELETED) to indicate when a lease is removed.

-          7.2 - The "FREE*" state is a bit odd, not sure if there's a better name for this? First time I saw it I was looking for the footnote.

-          The term "lease times" may need to be defined as this controls the valid lifetime that can be given to the client. Perhaps this should be added to the terminology or replace "lease times" with "valid lifetime"?

And, I'll suggest the following answers to Kim's "questions" on slide 8 of https://www.ietf.org/proceedings/94/slides/slides-94-dhc-0.pdf:

* Probably OPTION_F_DNS_REMOVAL_INFO should use IANA (top level) encapsulated options, instead of defining its own suboption space

Yes - top level.

* What is missing?

Document seems pretty complete.

* Does DDNS belong (i.e., is 6 pgs too much)?

Yes, it does belong and OK if 6 pages. I think what's there is pretty much needed.

* Does the protocol hang together?
- Time definitions and use in BNDUPD/BNDACK
- Endpoint states and state transitions

Yes, seems pretty complete (much of this came from the DHCPv4 document and has been tried and tested in various implementations).

I will add that people should look at the Independent Allocation (section 4.2.1) for addresses (IA_NA/IA_TA) and Proportional Allocation (section 4.2.2) for Prefix Delegation (IA_PD) to confirm that they are fine with these models. The idea here is that Proportional is more like what was done for DHCPv4 failover (requiring pool balancing/rebalancing). Whereas Independent uses an algorithm approach (a single bit) and doesn't require pool (re)balancing - but effectively requires double the address space in the worst case situation (but with generally 64 bits of address space available on each prefix, this should not be a significant issue).

-          Bernie

---

From: Kim Kinnear <[email-masked]>
Date: Mon, 30 Nov 2015 10:34:44 -0500

Folks,

Yes, please wait until I've folded Bernie's comments and corrections
into the document before you review it.  That will be the -01.txt version.
I expect to do this in December.

I'll respond to the rest of the points inline, below...

> On Nov 30, 2015, at 9:52 AM, Bernie Volz (volz) <[email-masked]> wrote:
> 
> Hi:
>  
> For the others that volunteered to review at IETF-94 meeting (Ted, Marcin, Jinmei, and Shawn), if you haven’t started, it may make sense to wait until Kim updates the document.

	Yes, as I said above, wait for the -01 draft, which I expect
	to do in December.
>  
> So here’s the list of (mostly) non-nits:
>  

	Oops.  Yes, managed to leave that out completely.  Good catch.
> This does raise an interesting question though with the (long ago abandoned) DHCPv4 failover draft. As there are existing implementations of that protocol, we should likely ask IANA to set up a new…

 	Seems like we will need a failover message registry.  Maybe we could just start
	the message-id's with say 20, and not have to invoke exactly why?
> 
>  
> -          Perhaps “DHCP” should be used throughout this document instead of “DHCPv6” (DHCPv6 can be used at the start). It is pretty clear that this is all about DHCPv6? (RFC 3315 used DHCP in most places.) I’d also suggest replacing “DHCPv6 client” with just “client”?

	Sure.

> -          DDNS (Dynamic DNS) should probably just be “DNS Update” or similar? The Dynamic part has pretty much been dropped these days?

	Ok,

> -          Resource could be replaced with lease? We are moving in that direction with the RFC3315 bis document.

	Ok.
> -          4.2.1.1 (Independent Allocation Algorithm) – the “low order” bit is 127 not 15.

	Oops.  Thanks for catching that.

> -          BNDUPD/BNDACK are defined to only support OPTION_CLIENT_DATA as container; this must be modified to support an IA_* option directly as there are cases where there may not be a client ass…

	Wow, good catch.  I missed that completely.

> -          7.1 (Time Skew) – Should we require NTP to synchronize the clocks on failover partners?

	An interesting idea.  I'll send separate email on this.

> -          7.2 (Informational Model) – I think there needs to be an additional state (i.e., something like DELETED) to indicate when a lease is removed.

	Ok.  I may need help fitting this in, but let me try
	something and I'll get back to you if I can't figure
	out a good answer.

> -          7.2 – The “FREE*” state is a bit odd, not sure if there’s a better name for this? First time I saw it I was looking for the footnote.

	Good point.  We'll find a better name.

> -          The term “lease times” may need to be defined as this controls the valid lifetime that can be given to the client. Perhaps this should be added to the terminology or replace “lease times” with “valid lifetime”?

	Sure, worth doing.
>  
> And, I’ll suggest the following answers to Kim’s “questions” on slide 8 of https://www.ietf.org/proceedings/94/slides/slides-94-dhc-0.pdf:
>  
> • Probably OPTION_F_DNS_REMOVAL_INFO should use IANA (top level) encapsulated options, instead of defining its own suboption space
>  
> Yes – top level.

	Ok.
> • What is missing?

	That's nice.
>  
> • Does DDNS belong (i.e., is 6 pgs too much)?
>  
> Yes, it does belong and OK if 6 pages. I think what’s there is pretty much needed.

	Thanks.
>  
> • Does the protocol hang together?
> – Time definitions and use in BNDUPD/BNDACK
> – Endpoint states and state transitions
>  

	Good.  I've been pretty close to it and it can be hard to
	know what is missing.
>  
>  
> I will add that people should look at the Independent Allocation (section 4.2.1) for addresses (IA_NA/IA_TA) and Proportional Allocation (section 4.2.2) for Prefix Delegation (IA_PD) to confirm that they are fine with these models. The idea here is that Proportional is more like what was done for DHCPv4 failover (requiring pool balancing/rebalancing). Whereas Independent uses an algorithm approach (a single bit) and doesn’t require pool (re)balancing – but effectively requires double the address space in the worst case situation (but with generally 64 bits of address space available on each prefix, this should not be a significant issue).

	Good point!

	Thanks much for the detailed review -- Kim

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

---

From: Kim Kinnear <[email-masked]>
Date: Mon, 30 Nov 2015 10:44:55 -0500

Folks,

> -          7.1 (Time Skew) – Should we require NTP to synchronize the clocks on failover partners?

The current draft (-00.txt) has a capability to allow the failover
protocol to operate with two machines which have clock skew of a
largely arbitrary amount (limited in some way to perhaps 24 hours or
something).  So two systems that are 3-5 minutes apart (the usual
skew, if any) will work fine.

Bernie is suggesting that we require failover partners to have
essentially synchronized time by requiring NTP sync.  If they are
synchronized to the level of 1-2 seconds, that would be synchronized
for the purposes of this protocol.  We aren't talking milliseconds
here.

Is that a good idea?  Should that be a requirement for DHCPv6
failover?

Most folks running our particular v4 failover seem to run synchronized
systems, though we have a few customers that don't.  Those systems
don't tend to be off by more than a couple of minutes, usually.

I'm interested in opinions as to whether we should require time sync
between failover partners for the DHCPv6 failover protocol.

Thanks -- Kim

---

From: Simon Hobson <[email-masked]>
Date: Mon, 30 Nov 2015 16:56:29 +0000

> for the purposes of this protocol.  We aren't talking milliseconds

I see two points :

1) If the time should be synced, then I would suggest merely requiring that, rather than specifying NTP - ie specify the what rather than the how.

2) Are there any other benefits to having time synced ? Eg, does having a significant time offset make troubleshooting any harder - eg by having logs on two servers with different timestamps for the same event ?
I'm inclined to thinking that there's isn't really any argument against having server times set correctly, particularly for services (such as DHCP) which include a time element. Perhaps if it's not an actual requirement, it should be suggested as recommended practice for stability and ease of troubleshooting - or is that going too far into "stuff any half decent admin shouldn't need telling" territory ?

---

From: Brian Haberman <[email-masked]>
Date: Mon, 30 Nov 2015 13:30:32 -0500

As the AD who shepherds the time-related WGs...

On 11/30/15 11:56 AM, Simon Hobson wrote:
>> largely arbitrary amount (limited in some way to perhaps 24 hours
>> or something).  So two systems that are 3-5 minutes apart (the
>> usual skew, if any) will work fine.
>> 
>> synchronized to the level of 1-2 seconds, that would be
>> synchronized for the purposes of this protocol.  We aren't talking
>> milliseconds here.
> 
> I see two points :
> 
> 1) If the time should be synced, then I would suggest merely
> requiring that, rather than specifying NTP - ie specify the what
> rather than the how.

The above makes sense since NTP is not the only protocol available to
synchronize time.

Regards,
Brian

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 30 Nov 2015 18:56:21 +0000

Sorry if I confused things as I did say "-	7.1 (Time Skew) - Should we require NTP to synchronize the clocks on failover partners?". The point wasn't about NTP (I don't really care how someone synchronizes the time), but to require synchronized time (we might say "(i.e., using NTP or other mechanisms)" or something similar).

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Brian Haberman
Sent: Monday, November 30, 2015 1:31 PM
To: [email-masked]
Subject: Re: [dhcwg] Review of draft-ietf-dhc-dhcpv6-failover-protocol-00

On 11/30/15 11:56 AM, Simon Hobson wrote:
> 1) If the time should be synced, then I would suggest merely requiring 
> that, rather than specifying NTP - ie specify the what rather than the 
> how.

The above makes sense since NTP is not the only protocol available to synchronize time.

Regards,
Brian

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 30 Nov 2015 19:05:33 +0000

>1) If the time should be synced, then I would suggest merely requiring that, rather than specifying NTP - ie specify the what rather than the how.

See my email to Brian (sent a few minutes ago).

>2) Are there any other benefits to having time synced ? Eg, does having a significant time offset make troubleshooting any harder - eg by having logs on two servers with

The protocol does mostly send relative times, but also includes the base time and the time at which the packet was "sent" (well, this should be as close as possible to the time sent from the application's view (I.e., at socket send). The reason time matters is that there could be time spent "in the transport" (i.e., send queue on the sender, network latency, and receive queue on the receiver). This time could easily tens of seconds. Which can thus skew things when events occur "close" to each other (perhaps the client is communicating with both servers such as when in communications interrupted) - it is then difficult to determine what happened "before" something else. By using synchronized clocks, the time the packet was sent/received no longer matters and it is possible to "correct" events. Though as we are only using second resolution (for base, sent, and relative time), we obviously can't do much better than that (and when a clock ticks over a second may also introduce small drifts - 1 or 2 seconds).

The main advantage of using synchronized clocks is that you no longer need to worry about calculating any drift related to the transport latency. And, with TCP this is a bit more problematic.

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Simon Hobson
Sent: Monday, November 30, 2015 11:56 AM
To: [email-masked]
Subject: Re: [dhcwg] Review of draft-ietf-dhc-dhcpv6-failover-protocol-00

I see two points :

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 30 Nov 2015 22:16:46 +0000

Hi:

The privacy draft comments about temporary addresses caused me to remember one other item with respect to failover.

Presently the draft-ietf-dhc-dhcpv6-failover-protocol-00 document excludes failover for temporary addresses. The main reason for excluding these is that as temporary addresses are generally not renewed, failover rules would restrict them to MCLT lifetimes (which could be OK). If a problem, it may require adjusting MCLT (which for v6 failover may not be as significant an issue - at least for address assignment as plenty of address space available).

But, I think that including them is required ...

1.       Leasequery (which can go to either or both servers) would give odd results as only one server would have a record of these leases. How would the partner know to respond appropriately?

2.       Comparing partners' (pool) status is easier - otherwise, someone may wonder why are addresses missing from the other partner.

3.       Failover - if a client communicates with its partner, it may get a different set of temporary addresses (which in most cases may not be an issue).

4.       Recovery - if one server's DB is lost, its temporary leases would be lost (perhaps not a great loss).

I think #1 is the key reason - especially for some deployments like Cable DOCSIS where CMTS's often do Leasequery to recover state and verify information. #2 and #3 are secondary. #4 is probably minor / non-issue.

-          Bernie

From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Monday, November 30, 2015 9:53 AM
To: [email-masked]
Subject: [dhcwg] Review of draft-ietf-dhc-dhcpv6-failover-protocol-00

Hi:

Yes - top level.

* What is missing?

-          Bernie