Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-failover-requirements-02

From: Ted Lemon <[email-masked]>
Date: Mon, 4 Mar 2013 15:04:27 +0000

On Oct 22, 2012, at 11:44 AM, Ted Lemon <[email-masked]> wrote:
> There will be a discussion about this document in the DHC working group meeting on November 8; depending on the outcome of that discussion and the response to this message, we will evaluate consensus on or about November 12.

The last call got lost in the kerfuffle of IETF 85, but it's clear that this document has consensus.   Tomek has offered to publish a new version that addresses Steinar's comments; it would be great if Steinar could review Tomek's updates and make sure that they satisfy his concerns, but the comments were essentially additive, so I don't think they affect consensus (and I'm sure Steinar will not be shy about it if he disagrees!).

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 12 Mar 2013 07:07:18 -0400

On 12-11-04 07:30, [email-masked] wrote:
> I have read draft-ietf-dhc-dhcpv6-failover-requirements-02 and I support
> this work going forward.
> 
> Some comments on the document:
Hi Steinar,

Thanks a lot for your comments. I have uploaded updated -03 that takes
into consideration all of your points. Sorry it took so long.

Can you check if those changes address your comments?

http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-requirements-03

Just for the reference, your comments with my responses:

> - It's possible section 5.6 "Long lived connections" should be expanded.
> Running DHCPv4 in a failover scenario for our customers, we find that
> customers really like stable addresses - because it lets them publish
> names in DNS (DynDNS etc) and run servers.
> 
> It may also be worth while mentioning that such stable DHCP addresses
> is an explicit non-goal for some SPs who want to prevent customers from
> running servers etc.
Added some text explaining that for stable addresses DNS updates may
happen infrequently and the lease change implies DNS update, which
brings in some delays which, depending on DNS settings, may be quite
large due to caching.

It was also pointed out by Krzysztof Nowicki that many monitoring and
statistics systems work on a per IP basis, so it is awkward to obtain
data for specific device if its IP changes.

Finally, there's a text about changing IP may be non-goal for some ISPs.
I'm not sure if this is the best place to have this text. On one hand it
belongs nicely to the long lived connections, but on the other hand,
there's section 4.1 "Alternatives to failover". I imagine that this
section would be read by many people who are not sure if they need
failover or not.

Anyway, I've put the text in section 5.6 as you suggested.

> - It may be worth while mentioning that section 6.2 "Synchronization
> mechanisms" uses concepts from distributed databases, and that some
> familiarity with distributed databases is useful.
Added.

> - It may be worth while mentioning in section 6.2.1 "Lockstep" that
> the large performance penalty of this method can be decreased by using
> SSDs or similar technologies (this is relevant because SSDs are becoming
> increasingly common).
Added a text about SSD and battery backed ram disks. I think this is the
part of the document that will grow old very fast.

> - It may be worth while mentioning in section 8 "DHCPv6 Failover
> Requirements" points 7 and 8 that such recovery may require manual
> intervention.
Added. I decided to not use normative language (lower case 'may') as I
consider it a clarifying comment to points that already have normative
language ('MUST' in points 7 and 8).

Thanks again for your comments.
Tomek

---

From: [email-masked]
Date: Tue, 12 Mar 2013 13:29:19 +0100 (CET)

> http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-requirements-03

I have now read the new document, and I'm happy to report that my
comments have been addressed.

Steinar Haug, AS 2116

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 12 Mar 2013 08:32:55 -0400

> comments have been addressed.
That was quick. Thanks a lot.

Tomek