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

[Andrew 👽 Yourtchenko <[e-mail]>]

Hi Bernie,

On 10/8/14, Bernie Volz (volz) <[e-mail]> wrote:
> 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.

I just thought it'd be a question I'd have if implementing this, and
"shortest T1" seemed an okay-ish strawman. Maybe this is a non-issue
altogether and we do not care if the client decides in a different
way.

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

Conceptually, with this update we want to have a single instance of
T1/T2; yet it has to be multiple instances in the PDU. We specify that
this instance is "virtually" derived as a "minimal" (cf. the comment
above) pair. So, conceptually it "feels" right as well to force the
servers to send the T1/T2 pairs identical - because conceptually they
are a duplicate of the same thing.

But, violating this requirement that the servers send the same T1/T2
for all, does not prevent the interop - this in my book makes "MUST"
too strong of a word. OTOH, we still want to make it easy to
understand the interaction and get the expected results even if the
clients somehow do not sort the T1/T2, so "MAY" is too weak. This
makes it a SHOULD in my book.

Now, an example.

Say I have two address pools A & B with different lifetimes, and one
prefix pool P.

I have different policies on the A and B - for A, I want to recycle
the addresses every day (it's a public wifi network where people come
and go), for B I want to keep them for three weeks (it's my employees,
I'd like to try keep the addresses stable even if they go for a PTO).
The prefixes, I want to keep as permanent as possible.

This "MUST" for the server means that either I will have to split the
P in two, or that the server will have to "tweak" the values from my
config before sending onto the wire.

Both of which add operational complexity and reduce transparency.

So, it's this type of a use case that made me write the comment - I
could not find a good argument to say why the servers *must* set the
T1/T2 pairs identically beyond "because conceptually it's the same
value", and that seemed too weak in comparison... What did I miss ?

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

Makes sense, thanks!

I do not have a strong feeling about it, but it's easy to revisit &
junk the ticket later, so I tabled it at:
http://trac.tools.ietf.org/group/dhcpv6bis/ticket/122

--a


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