Subject: [dhcwg] DHCPv6 Failover -- LAST CHANCE

From: Kim Kinnear <[email-masked]>
Date: Fri, 2 Sep 2016 15:23:13 -0400

We are well into the second and *last* WGLC for the DHCPv6 failover
draft:

https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-protocol-02 <https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-protocol-02>

If there are not enough responses to the draft for this WGLC, we will
drop it and not try again.

We have some detailed technical reviews.  What we *really* need now
are people to just read it and say:

  "I think this draft should move forward".

That's all you have to do.  Any review would be nice, but we really
just need people to read it and send in email that says "move this
forward".  

This is the last chance for DHCPv6 failover.

Thanks -- Kim

---

From: perl-list <[email-masked]>
Date: Fri, 2 Sep 2016 16:08:06 -0400 (EDT)

I think that this draft should move forward. 

> From: "Kim Kinnear" <[email-masked]>
> To: "<[email-masked]>" <[email-masked]>
> Cc: "Kim Kinnear" <[email-masked]>
> Sent: Friday, September 2, 2016 3:23:13 PM
> Subject: [dhcwg] DHCPv6 Failover -- LAST CHANCE

> https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-protocol-02
> <https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-protocol-02>

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

---

From: Lewis Donzis <[email-masked]>
Date: Fri, 2 Sep 2016 15:12:35 -0500

We have reviewed this draft and think that it is valuable and should move forward.

Thanks,
lew

> On Sep 2, 2016, at 2:23 PM, Kim Kinnear <[email-masked]> wrote:
>

---

From: 神明達哉 <[email-masked]>
Date: Fri, 2 Sep 2016 13:23:11 -0700

At Fri, 2 Sep 2016 15:23:13 -0400,

> just need people to read it and send in email that says "move this

I feel sorry that I simply couldn't find time to read this big
document and provide useful feedback, but I also feel nervous by
seeing this action...it's hard to believe that if someone reads this
size of complicated technical document and can just say "it should
move forward".  Even after getting reviews and revised, it's quite
likely for every new reader to find at least one or a few non-trivial
issues.  So, if the only response to the call is just "move forward",
I wonder if it's really a careful read.  And, now, if we move forward
just by counting a certain number of 'yes', does that mean something?
If we think we've already got sufficient level of technical reviews,
isn't it itself enough to move forward (to which I wouldn't be
opposed)?  If not, counting more simple "move forward" responses just
as a prerequisite for moving forward doesn't seem to be a good way to
move forward.

Just my two cents.  Again, I'm sorry I cannot be more productive...

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Sat, 3 Sep 2016 09:21:38 -0400

Jinmei-san, the question is, is it better to publish something that's
basically good but has a few non-blocking issues, or to not publish it at
all?   I too would like to see the document get more review and maybe a
couple of interoperating implementations, but if we have to wait for the
bis document for that, I'm okay with it.

---

From: "Karsten Krone (kkrone)" <[email-masked]>
Date: Mon, 5 Sep 2016 14:37:37 +0000

Dear working group,

Following your last call:
——8<————
We are well into the second and *last* WGLC for the DHCPv6 failover draft:
https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-protocol-02

——8<————

I would very much appreciate to see this draft come into existence.
Please move it forward, it does make sense, also for a number of smaller ISPs I work (and have worked) with.

Kind regards,

--
Karsten Krone .:|:..:|:. 
Cisco Germany| Systems Engineer GSP | [email-masked]

---

From: Simon Hobson <[email-masked]>
Date: Mon, 5 Sep 2016 16:46:33 +0100

Unfortunately I failed to find time to go through the whole document - and take it in. As far as I did get, seemed OK.
It's an important function and it would be a shame to let it drop - I too would like to see it go forward.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 6 Sep 2016 01:41:42 +0000

And, there’s still time to read the entire document (WGLC ends a week for now). And, the WGLC could be extended if someone requested more time – yes, it is a rather long and somewhat complex document. We extended 3315bis.

-          Bernie

From: dhcwg [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Saturday, September 03, 2016 9:22 AM
To: 神明達哉 <[email-masked]>
Cc: <[email-masked]> <[email-masked]>; Kim Kinnear (kkinnear) <[email-masked]>
Subject: Re: [dhcwg] DHCPv6 Failover -- LAST CHANCE

Jinmei-san, the question is, is it better to publish something that's basically good but has a few non-blocking issues, or to not publish it at all?   I too would like to see the document get more review and maybe a couple of interoperating implementations, but if we have to wait for the bis document for that, I'm okay with it.

On Fri, Sep 2, 2016 at 4:23 PM, 神明達哉 <[email-masked]<mailto:[email-masked]>> wrote:
At Fri, 2 Sep 2016 15:23:13 -0400,

--
JINMEI, Tatuya

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

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 6 Sep 2016 13:28:53 +0200

>   "I think this draft should move forward".
Being one of the people who reviewed it, let me reiterate my support for
this document moving forward. It defines useful functionality and there
are people running actual networks who asked for failover.

Tomek

---

From: 神明達哉 <[email-masked]>
Date: Wed, 7 Sep 2016 11:25:05 -0700

At Sat, 3 Sep 2016 09:21:38 -0400,

> bis document for that, I'm okay with it.

This is the conclusion of the previous WGLC (including the original
call text)):
https://www.ietf.org/mail-archive/web/dhcwg/current/msg17438.html

The last call states:

>> We will need several serious reviews of this document for it to
>> pass WGLC.

and the conclusion was:

>> But sadly (as I need to make the call as Tomek is a co-author), I
>> don’t think we’re ready to advance this document. We will try again
>> and hopefully get some more participation.

I interpreted it as it didn't pass because there were not sufficient
number of "serious reviews".  If my interpretation is correct and the
situation hasn't changed since then (I wasn't in Berlin even remotely
and the meeting minutes and the retried last call text are not very
clear on this), I would expect this latest last call is also seeking
"several serious reviews".  So it looked awkward to me that the wg now
seems to ask people for stating a one-line, lightweight "support or
not support" feedback.

According to your above comment, perhaps the sense of the bar to
advance it has been revised from "several more serious reviews" to a
few more one-line "yes" responses through a discussion that I didn't
participate in.  If so, I have no problem with that, although it would
have been nicer if that had been clarified in the revised last call
text.  If the bar hasn't changed, I personally think we are having a
due diligence issue.

In any case, I don't intend to be a blocker for this document
especially when I can't be more productive by providing a "serious
review" myself.  So I'll shut up on this with this message.

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Sep 2016 14:26:37 -0400

Kim specifically stated that it had had enough detailed review at this
point.

---

From: Kim Kinnear <[email-masked]>
Date: Wed, 7 Sep 2016 14:47:38 -0400

Folks,

I don't have any idea *how many* detailed reviews are necessary to
move a draft forward, since there isn't any fixed number of which I am
aware.

I would *love* more serious, detailed reviews.  Do we have to have
more to move it forward?  I don't know for sure, since I'm not the
person making the call to move it forward. 

I *do* know that on the prior WGLC, we had *only* serious, detailed
(i.e., many pages of comments) technical reviews.  We had few (if I
recall correctly, none) of the "I read it and I think this is
important" responses.

While I am not the decision maker, my experience from working with at
least the DHC WG over the years is that to move a draft through WGLC,
one needs to have several really detailed technical reviews, and one
*also* has to have a enough people say that this work is not only
important but largely correct.  There is always a range of "depth" of
reviews.

I was in no way saying that people shouldn't review it in detail.  I
was saying that it looked to me like that thing that we were lacking
before was the general groundswell of opinion that this was worthy
work to spend time on and that it was generally correct.

If you (any of you) would be willing to do a detailed review -- of any
level -- have at it!  That would be great!!!

That said, we *also* need people to do whatever level of review they
can do and to say that they have done that and that they think this
draft is worthwhile and even important to push to an RFC.

We have had a few folks chime in and say this, and I want to thank
everyone who has read the draft and responded.  Have *enough* people
done that now for it to pass WGLC?  I doubt it -- I think we still
have a good ways to go.  But that is just my guess.

Thanks - Kim

> On Sep 7, 2016, at 2:26 PM, Ted Lemon <[email-masked]> wrote:
> 
> Kim specifically stated that it had had enough detailed review at this point.
>

---

From: tianxiang li <[email-masked]>
Date: Thu, 8 Sep 2016 10:37:06 +0800

Hi,

I think this a useful draft and I think it should forward. The DHCPv6
failover is an important mechanism with real network needs. It is quite a
long document and I read through part of it. I have a few comments below:

3. Glossary

“Delegable prefix: A prefix from which other prefixes may be delegated, as
described in [RFC3633].”

The term “delegable prefix” was never used in RFC3633, so maybe it should
be considered a new term defined in this particular draft?

4.2.1 Independent allocation

“In this allocation scheme, used for allocating individual IPv6 addresses,
available IPv6 addresses are permanently (until server configuration
changes) split between servers…”

If active-passive mode is used, it would mean that the addresses in the
secondary server would not be used unless the primary server fails. In that
case, wouldn’t permanently splitting the addresses between the primary and
secondary server a waste of addresses?

If the address pool in the primary server becomes scarce, wouldn’t a
rebalancing mechanism be useful?

4.2.2 Proportional Allocation

“The flow of a delegable prefix is as follows: initially the delegable
prefix is part of a larger delegable prefix, all of which are initially
owned by the primary server. A delegable prefix may be allocated to the
secondary server and then it is owned by the secondary server. Either
server can allocate and delegate prefixes out of the delegable prefixes
which they own…”

“In PARTNER-DOWN state the operational partner can delegate prefixes from
either pool (both its own, and its partner's after some time constraints
have elapsed)…”

How are the prefixes in the primary server passed on to the secondary
backup server in such a case? Should there be some text added here to
explain this?

These are my individual comments, please correct me if I misunderstood
something.

Thanks,

Tianxiang

2016-09-03 3:23 GMT+08:00 Kim Kinnear <[email-masked]>:

> https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-protocol-02 <
> https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-protocol-02>
>

---

From: perl-list <[email-masked]>
Date: Thu, 8 Sep 2016 09:09:19 -0400 (EDT)

> From: "tianxiang li" <[email-masked]>
> To: "Kim Kinnear" <[email-masked]>
> Cc: "dhcwg" <[email-masked]>
> Sent: Wednesday, September 7, 2016 10:37:06 PM

> available IPv6 addresses are permanently (until server configuration changes)
> split between servers…”

> If the address pool in the primary server becomes scarce, wouldn’t a rebalancing
> mechanism be useful?

I read this section as just a codifying of what we do now without failover. We put half the /64 on the "primary" and half on the "secondary". It provides for some enhanced behavior where clients won't need to get a new address in the case of server failure as the remaining server can renew addresses. Also, you wouldn't need to do any math as the server would arithmetically split in half for you any subnets that are marked for this behavior. If offered a choice in the future, I would probably choose this method as it is the simplest. 

Also, this bit here: "It also assumes that the pool assigned to each server will never deplete." negates your comment about addresses becoming scarce. It is highly recommended (by all articles and documentation that I've seen) that all end networks be configured as /64 subnets. There are quite a lot of addresses in a /64. More than are in the entire IPv4 address space, is my understanding. It is unlikely that a /64 will experience IP address scarcity.

---

From: tianxiang li <[email-masked]>
Date: Mon, 12 Sep 2016 11:01:57 +0800

Thank you for explaining this point. It does seem like the desirable
method, and a /64 is sufficient enough for address allocation, so  I
guess there's no need to address rebalancing.

Thanks,
Tianxiang

2016-09-08 21:09 GMT+08:00 perl-list <[email-masked]>:

>
>
> ------------------------------
>
> *From: *"tianxiang li" <[email-masked]>
> *To: *"Kim Kinnear" <[email-masked]>
> *Cc: *"dhcwg" <[email-masked]>
> *Sent: *Wednesday, September 7, 2016 10:37:06 PM
> *Subject: *Re: [dhcwg] DHCPv6 Failover -- LAST CHANCE
>
> I read this section as just a codifying of what we do now without
> failover.  We put half the /64 on the "primary" and half on the
> "secondary".  It provides for some enhanced behavior where clients won't
> need to get a new address in the case of server failure as the remaining
> server can renew addresses.  Also, you wouldn't need to do any math as the
> server would arithmetically split in half for you any subnets that are
> marked for this behavior.  If offered a choice in the future, I would
> probably choose this method as it is the simplest.
>
> Also, this bit here: "It also assumes that the pool assigned to each
> server will never deplete." negates your comment about addresses becoming
> scarce.  It is highly recommended (by all articles and documentation that
> I've seen) that all end networks be configured as /64 subnets.  There are
> quite a lot of addresses in a /64.  More than are in the entire IPv4
> address space, is my understanding.  It is unlikely that a /64 will
> experience IP address scarcity.
>

---

From: yogendra pal <[email-masked]>
Date: Wed, 14 Sep 2016 11:04:14 +0530

Tomek/Bernie,

Given this draft is in very much detailed and focused w/ HA design. I would
request if we can extend the WGLC for another date (21st). I have started
reading it and will be finishing mid of next week.

Thanks,
Yogendra Pal

On Mon, Sep 12, 2016 at 8:31 AM, tianxiang li <[email-masked]> wrote:

>> “In this allocation scheme, used for allocating individual IPv6
>> addresses, available IPv6 addresses are permanently (until server
>> configuration changes) split between servers…”
>>
>>
>>

---

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 14 Sep 2016 14:46:34 +0200

On 14/09/16 07:34, yogendra pal wrote:
> Given this draft is in very much detailed and focused w/ HA design. I
> would request if we can extend the WGLC for another date (21st). I have
> started reading it and will be finishing mid of next week.
Hi,
Thank you for spending your time on this. As I'm co-author, it is up to
Bernie to make the actual decision, but I would be very much in favor of
extending the deadline. This draft has been around for years, so a week
one way or the other doesn't change anything. And additional technical
reviews are something we definitely could wait for.

Thank you for reviewing this draft,
Tomek

---

From: Kim Kinnear <[email-masked]>
Date: Wed, 14 Sep 2016 09:12:03 -0400

I agree with Tomek, we'd love more technical reviews.  Another
week is a small price to pay for that.  Who knows, maybe some
other folks will take the time to review it too :-)

But, as Tomek said, it is up to Bernie.

Cheers -- Kim

> On Sep 14, 2016, at 8:46 AM, Tomek Mrugalski <[email-masked]> wrote:
>