Re: [dhcwg] FW: Please review version -07 of draft-ietf-dhc-dhcpv6-stateful-issues

["Bernie Volz (volz)" <[e-mail]>]

Hi:

Thanks for the comments.

Regarding 4.3 T1/T2 timers:

It really is up to the server (or client) to pick one of the set of lifetimes. Whether it bases its decision on T1 or T2 (or some combination) is up the client or server. The important point is that it picks one IA's T1/T2 values. I would think that shortest ('effective') T1 is probably the best approach. If the WG feels we should mandate that, we could.

While we could relax the server's MUST to a SHOULD, that allows new servers to not follow this which probably is not the best idea. Existing "3315 compatible" servers can still do what they do today.

Regarding 4.4.5, this is a retransmission of Request/Renew/Rebind and not Solicit. The idea here is that we don't want the client to turn around and retransmit immediately the Request/Renew/Rebind as that could create a storm (request followed by Reply with UnSpecFail). This is also the text that was copied DIRECTLY from RFC 3315 - it was  not modified. If you feel this should be changed or clarified, let's take this up in the DHCPv6 bis work (create a ticket for it). I would rather not expand the issues in this draft.

- Bernie

-----Original Message-----
From: Andrew 👽 Yourtchenko [mailto:[e-mail]] 
Sent: Tuesday, October 07, 2014 5:02 PM
To: [e-mail]; Ole Troan; Bernie Volz (volz); [e-mail]
Subject: Re: FW: [dhcwg] Please review version -07 of draft-ietf-dhc-dhcpv6-stateful-issues

I volunteered to review the draft, below go a couple of thoughts that popped up while reading the document.

"4.3.  T1/T2 Timers"

the text says: "To deal
   with the case where servers have not yet been updated to do that,
   clients MUST use the shortest (explicit or implicit) T1/T2 times
   (larger than 0), from the same IA option, in the Reply.  T1/T2 times
   from other IAs are ignored.", but then at the same time mandate the servers to set the timers equal.

Arguably the above requirement to the clients is a simple robustness requirement which will have to always be present - the client has no assurance in advance that the server follows the "MUST" until it checked all T1/T2s - and selected the minimum.

Then - what is the benefit of requiring the server to recalculate the
T1/T2 ? I'd think it should be relaxed to "SHOULD".


"4.4.3.  Updates to section 18.1.3 of RFC 3315"

Record T1 and T2 times.  The client MUST use the shortest
        (explicit or implicit) T1 and T2 times (larger than 0) from the
        same IA option across all of the IA options to facilitate
        initiating the renewal process for all bindings simultaneously.
        T1/T2 times from other IAs are ignored.

What about case T1x > T1y but T2x < T2y ? Should the one with the shortest T1 win ?

"4.4.5.  Updates to Section 18.1.8 of RFC 3315"

This text:

"
     the client retransmits the original message to the same server to
     retry the desired operation, the client MUST limit the rate at
     which it retransmits the message and limit the duration of the time
     during which it retransmits the message.
"

I think it should be more specific about the numbers. Should there be a reference to https://tools.ietf.org/html/rfc7083 in some way as a guidance ?

--a