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

["Bernie Volz (volz)" <[e-mail]>]

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:[e-mail]] On Behalf Of Bernie Volz (volz)
Sent: Monday, November 30, 2015 9:53 AM
To: [e-mail]
Subject: [dhcwg] Review of draft-ietf-dhc-dhcpv6-failover-protocol-00

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