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

[Kim Kinnear <[e-mail]>]

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) <[e-mail]> wrote:
> 
> 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.

	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:
>  
> -          There is no port for failover mentioned. I presume the IANA assigned Failover Port (647) will be used?

	Oops.  Yes, managed to leave that out completely.  Good catch.
>  
> 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).

 	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.
> -          BNDUPD/BNDACK are defined to allow bulking; I think this should be simplified to not allow bulking (one message per client or lease).

	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 associated with a lease (consider pool rebalancing). So, a BNDUPD can contain an OPTION_CLIENT_DATA or an IA_* option.

	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?
>  
> Document seems pretty complete.

	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
>  
> Yes, seems pretty complete (much of this came from the DHCPv4 document and has been tried and tested in various implementations).

	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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg