[dhcwg] Updated dhcpv6-failover-protocol draft after WGLC

[kkinnear <[e-mail]>]

Folks,

I have submitted draft-ietf-dhc-dhcpv6-failover-protocol-03.txt, which
contains changes based on comments received during the WGLC.  Thanks
to everyone who commented, either with changes or just with support!
We really appreciate the effort that you all put into this!

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

While it is not there yet, I expect that there will appear a "Diff3"
link which will show you the differences between this version and the
-02.txt version.  I have a diff I generated -- if you would like it let
me know, and I'll send it to you.  It is a short .html file.

I have reproduced all of the comments requesting changes that I
recovered from my email, below, with my response coming after KK>.
While there is a fair bit of discussion (represented below), the
actual changes were in large part clarifications with some few
substantive changes.  All of the changes were from the folks listed as
To: on this email.  If you requested changes and aren't listed below
or on the To: for this email, please respond to me immediately so I
can fold your changes in.

We would appreciate hearing from the folks who requested changes as to
whether these changes meet your needs.  Thanks!

Here is what was done to the draft along with who requested the
changes.  They are in time order of reception:

Naiming Shen:
------------

Since the two servers using TCP to communicate with each other
and with explicit user provisioning, I’m wondering this ‘on the
same network’ term is needed here.

KK> No, I agree, it is not.  I removed it.

Tianxiang Li:
------------

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?

KK> Marcin also discusses this, below, in the context of RFC3315-bis,
suggesting that RFC3315-bis and this draft share a common term.
I'm not in love with "delegable prefix", but "delegated prefix"
implied to me that it has been delegated, making it difficult for
me to use that term to describe a prefix which *could* be delegated
but has not been delegated.  I have clarified the glossary to not
imply that "delegable prefix" was defined in RFC3633.

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?

perl-list: responded:

    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.

Tianxiang Li: responded:

        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.

KK> To my reading, the above discussions seem to be slightly missing
each other's points, but I agree that there is no need to address
rebalancing -- since any likely prefix being used for address
allocation in a DHCPv6 server using failover will be at least a
/64, and therefore have more than enough leases any reasonable
deployment.  I have made no change in the draft due to this comment.

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?

KK> They aren't "passed on" in an active sense.  Each server knows
about all of the delegable prefixes, and which ones reside in each
pool.  When a server is in PARTNER-DOWN state and the aforementioned
time constraints have elapsed, it knows that it can use its partners
pool of delegable prefixes.  I have added some text that says pretty
much that.

Marcin Siodelski:
----------------

1. Introduction
"The failover protocol is designed to provide lease stability for
 leases with valid lifetimes beyond a short period.  The DHCPv6
 Failover protocol MUST NOT be used for leases shorter than 30
 seconds."

I wonder if anywhere it should say what is the implication for a
lease (having initially a lifetime longer than 30 seconds) which
is expiring and for which the remaining valid lifetime is below 30
seconds. Plus, what are the implications of having leases shorter
than that in general.

KK> There is no problem with a short time at the end, but I believe
that there might be edge cases with leases shorter than 30 seconds
that I didn't want to bother to formulate and handle or explain.
I don't have specifics of these edge cases, and as it seemed like
there was no particular value to short leases, simply saying that
they are not allowed seemed like a good plan.  I'm trying to not
explain and justify every decision in the draft (been there, done
that, draft didn't make it to RFC).  So I have added text that says
that there is no problem at the end of a lease and have not added
additional explanation or justification.

3. Glossary
Every occurrence of "Absolute Time" in the text repeats the definition
in the glossary. This is technically ok but redundant. So, perhaps
remove the repetitions from the text?

KK> It *is* redundant.  That was intentional, for two reasons.
First, absolute time is kind of new for DHCP, and I wanted to drive
home what we are talking about.  Second, and more importantly, this
is not your normal time based on 1970.  I don't want someone to
start using 1970 based time by thinking that they know what an
absolute time it.  Nobody reads the glossary.  Except us.

"Delegable Prefix"
In RFC3315bis we use the term "delegated prefixes" for both assigned
prefixes (for which there are leases) and for those that haven't been
assigned. I wonder if we should make the same distinction between
delegable and delegated there.

I'd just like the two documents use the same terminology. So, this might
be more an action item for the RFC3315bis authors, rather than for the
failover authors.

KK> The term "delegable prefix" was already in the glossary.  I
tried to gently disentangle it from RFC3633 in an update to the
glossary. I will mention this issue to someone working on the
RFC3315-bis effort.

"Responsive"/"Unresponsive"
Shouldn't it say: "A server that is responsive will respond to all
*valid* DHCP client requests"?

A request that is invalid will not be responded by a responsive server.

KK> I changed both "Responsive" and "Renew Responsive" to include
the word "valid".

4.4.1. MCLT Example
This is slightly confusing.

"However, the desired partner lifetime will be composed of
 one half of the current actual lifetime added to the desired
 lifetime.  Thus, the failover partner is updated with a BNDUPD with a
 partner lifetime of 1/2 hour + 3 days."

First of all, the "desired partner lifetime" is not explained in
section 4.4. Secondly, I am not sure why that lifetime is composed
of one half of the current lifetime plus desired lifetime. Specifically,
why half of it? Is it because the renewal time is half the lifetime?
I think that could be made clearer.

KK> Good catch.  You are correct, it is because the renewal time
is typically half of the lifetime.  I have fixed both the
"desired partner lifetime" and clarifed this discussion.

5.3.5.  UPDREQ
OLD: ...request that its partner send all binding...
NEW: ...request that its partner sends all binding...

KK> Fixed.

7.1.  Time Skew
What happens if the time skew exceeds 5 seconds (perhaps significantly).
Should servers refuse to establish communication during CONNECT
time?  log a warning?

KK> Good point.  I changed this so that they fail to CONNECT
and respond with an ExcessiveTimeSkew status code.

Further reviewing the document I saw in section 7.5.1. that the
connection is dropped when the time skew exceeds 5 seconds, but
this seems to only refer to the BNDUPD case. Is this intended to
only monitor connection during BNDUPD?

KK> Given that I've changed it for CONNECT, I think CONNECT
and BNDUPD is enough.  Good question, though.

I think it may be useful to say that the status message to the user
SHOULD be displayed/logged when the connection has dropped, giving
the reason of time skew being exceeded.

KK> Yes, I think that is implicit in the new Status Code I created
for this issue: ExcessiveTimeSkew.

7.5.3. Processing Binding Updates
I suggest that the paragraph that talks about "better" information
state etc. refers to next section 7.5.4. saying that what is better
will be explained in that section. For a while, reading section
7.5.3. I was trying to figure out what the "better" might mean and
then I discovered that the next section discusses that. Although,
it seems that 7.5.4. is a little broader than discussing "better"
information, as it also talks about ConfigurationConflict.

In addition, it seems to me that in general saying that some
information is better than the other is confusing and doesn't really
fit into this kind of document.

So perhaps, it is sufficient to say:

"The server receiving a BNDUPD update from its partner must evaluate
 the received information in each OPTION_CLIENT_DATA or IAPREFIX
 option to see if it is consistent with the server's already known
 state, and if it is not, decide on accepting or rejecting the
 information. Section 7.5.4. provides the details how the server
 makes this determination."

KK> That is so much "better" than what was there before!  Seriously,
it really is, and I appreciate the effort you went to in order to
word-smith this.  I love it when people give me text that I can just
use as-is.  Thanks!
-------------------------

Another big thanks to all who contributed!

Cheers -- Kim