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

From: Tomek Mrugalski <[email-masked]>
Date: Sun, 04 Nov 2012 08:28:45 +0100

On 12-10-22 17:44, Ted Lemon wrote:
> The authors have asked for a last call on the DHCPv6 failover
> requirements draft.   This just documents the list of requirements
> for a DHCPv6 failover protocol.   If you are interested in DHCPv6
> failover, please review the document and comment on the list.   If
> you favor publishing this requirements document, please say so.   If
> you oppose publishing it, please also say so.
The DHC meeting (and possibly end of this WGLC) is just a couple days
away. Some time ago over 20 people expressed interest in this work, yet
we have not received a single response to that last call.

I know that requirement documents may be somewhat boring at times, but
without this document moving forward we can't really do useful work on
the design document (which haven't received any comments neither).

BTW I support this document and would like it to move forward
(disclaimer: I'm co author).

Cheers,
Tomek

---

From: [email-masked]
Date: Sun, 04 Nov 2012 13:30:23 +0100 (CET)

> the design document (which haven't received any comments neither).

I have read draft-ietf-dhc-dhcpv6-failover-requirements-02 and I support
this work going forward.

Some comments on the document:

- 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.

- 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.

- 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).

- It may be worth while mentioning in section 8 "DHCPv6 Failover
Requirements" points 7 and 8 that such recovery may require manual
intervention.

Steinar Haug, AS 2116

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Mon, 5 Nov 2012 01:58:25 +0000

I support this  work/document.

Thanks,
Gaurav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
Sent: Sunday, November 04, 2012 12:59 PM
To: [email-masked]
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-failover-requirements-02

> you oppose publishing it, please also say so.
The DHC meeting (and possibly end of this WGLC) is just a couple days away. Some time ago over 20 people expressed interest in this work, yet we have not received a single response to that last call.

I know that requirement documents may be somewhat boring at times, but without this document moving forward we can't really do useful work on the design document (which haven't received any comments neither).

Cheers,
Tomek
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Kim Kinnear <[email-masked]>
Date: Mon, 5 Nov 2012 09:56:44 -0500

I have read this document, and believe that it should move forward.

I, too, am a co-author.  

Regards -- Kim

---

From: Paul Ebersman <[email-masked]>
Date: Tue, 06 Nov 2012 12:51:39 -0500

TLemon> The authors have asked for a last call on the DHCPv6 failover
TLemon> requirements draft.   This just documents the list of
TLemon> requirements for a DHCPv6 failover protocol.   If you are
TLemon> interested in DHCPv6 failover, please review the document and
TLemon> comment on the list.   If you favor publishing this requirements
TLemon> document, please say so.   If you oppose publishing it, please
TLemon> also say so.

I am in favor of publishing this document.

---

From: Marcin Siodelski <[email-masked]>
Date: Thu, 8 Nov 2012 20:41:18 +0100

I support this work move forward.

Marcin