Re: [dhcwg] Tsvart Last Call/telechat review of draft-ietf-dhc-rfc3315bis-10

[Allison Mankin <[e-mail]>]

Bernie,

Thank you for the very responsive reply. I just went through it carefully
and I like all of your suggestions for handling my comments.

If it is possible to lower the maximum number of relays now rather than
when going from PS to Full, as you mentioned,  that too would be great.

Best,

Allison
On Jan 25, 2018 12:01 PM, "Bernie Volz (volz)" <[e-mail]> wrote:

> Hi:
>
>
>
> Thanks much for the review.
>
>
>
> See the comments inline below (BV>).
>
>
>
> -          Bernie
>
>
>
> *From:* Allison Mankin [mailto:[e-mail]]
> *Sent:* Wednesday, January 24, 2018 5:44 PM
> *To:* [e-mail]
> *Cc:* IETF Discussion <[e-mail]>; draft-ietf-dhc-rfc3315bis.all@
> ietf.org; [e-mail]
> *Subject:* Tsvart Last Call/telechat review of
> draft-ietf-dhc-rfc3315bis-10
>
>
>
> Reviewer: Allison Mankin
>
> Reviewer Result: Ready with Issues
>
>
>
> I've reviewed this document as part of TSV-ART's ongoing effort to review
> key
> IETF documents. These comments were written primarily for the transport
> area
> directors, but are copied to the document's authors for their information
> and
> to allow them to address any issues raised.  When done at the time of IETF
> Last
> Call, the authors should consider this review together with any other
> last-call
> comments they receive. Please always CC [e-mail] if you reply to
> or
> forward this review.
>
>
>
> The draft brings together and updates multiple RFCs in order to provide a
> cleaned-up version of the DHCPv6 specification.
>
>
>
> It is good to see that this Bis document for DHCPv6 has done some new work
> on congestion control and towards packet storm controls.  This is noted in
> items 12 of Appendix A (the summary of changes) and the sections on Rate
> Limiting (14.1) and Reliability (15) are basically in good shape, which is
> why the summary is Ready with issues.
>
>
>
> The following  transport-related comments should be considered for fixing
> before publication
>
>
>
> 1. In Section 5, which defines that the transport is UDP, add a normative
> reference to BCP 145, UDP Usage Guidelines.
>
>
>
> BV> OK, we can add.
>
>
>
> 2. There are several small issues about retransmissions:
>
>
>
> a) there's a transmit parameters table 7.6 and it would be good for this
> to reference that these parameters are also controlled by the RND factor
> parameter and the backoffs in section 14.1
>
>
>
> BV> OK, we’ll see what text we can craft for this. Perhaps something like
> “Some of the values are adjusted by a randomization factor and backoffs
> (see Section 15) and transmissions may be influenced by rate limiting (see
> Section 14.1).”
>
>
>
> b) The REC_TIMEOUT parameter in the table in section 7.6 is in seconds,
> but it is described as milliseconds in section 18.3
>
>
>
> BV> OK, we will rework the text in 18.3.11. Perhaps replace:
>
>
>
>    If the server does not receive a Renew, Rebind, or Information-
>
>    request message from the client in REC_TIMEOUT milliseconds, the
>
>    server retransmits the Reconfigure message, doubles the REC_TIMEOUT
>
>    value and waits again.  The server continues this process until
>
>    REC_MAX_RC unsuccessful attempts have been made, at which point the
>
>    server SHOULD abort the reconfigure process for that client.
>
>
>
> With:
>
>
>
> When transmitting the Reconfigure message, the server sets the
> retransmission time (RT) to REC_TIMEOUT. If the server does not receive a
> Renew, Rebind, or Information-request message from the client before the RT
> elapses, the server retransmits the Reconfigure message, doubles the RT
> value, and waits again. The server continues this process until REC_MAX_RC
> unsuccessful attempts have been made, at which point the server SHOULD
> abort the reconfigure process for that client.
>
>
>
> c) does the rate-limit per device per interface  (a MUST in Section 14.1)
> explicltly include retransmissions?  This should probably be stated earlier
> on in the section.
>
>
>
> BV> Yes, any transmission by the client. Note that section 14.1 doesn’t
> generally need to apply to retransmission timers because those would not
> trigger the rate limiting. The rate limiting is more to deal with “possible
> logic loops”.
>
>
>
> We can change 14.1’s first sentence to add “or retransmits” to the end to
> clarify that this applies to all DHCP transmissions.
>
>
>
> 3. The following addition to the spec in Section 15 seems likely to cause
> excess retransmissions:
>
>
>
>   A client is not expected to listen for a response during the entire
>    RT period and may turn off listening capabilities after a certain
>    time due to power consumption saving or other reasons.  Of course, a
>    client MUST listen for a Reconfigure if it has negotiated for its use
>    with the server.
>
>
>
> If this congestion avoidance is working, then the clients may need to
> retransmit mostly in cases where the round-trip time isn't very variable.
> So I'd be tempted to say "after a certain time" should be after the initial
> round-trip timeout, so as not to have too many near-misses.
>
>
>
> BV> OK, this was to address the LONG RTs for Solicit/Information-Request
> when no DHCPv6 server is present – as the RT period here can an hour
> (SOL_MAX_RT/INF_MAX_RT) or perhaps longer if the SOL_MAX_RT / INF_MAX_RT
> had previously been received by the client. Perhaps we should recommend
> that this be at least some minimum time, such as 60 seconds? (Not sure if
> there’s a good general system parameter to use, such as ipReasmTimeout?)
> Or, could add a new entry to the section 7 table (MAX_WAIT_TIME, 60 secs,
> Maximum required time to wait for a response) and then change the text to
> use it?
>
>
>
>    A client is not expected to listen for a response during the entire
>
>    RT period and may turn off listening capabilities after waiting at
>
>    least the shorter of RT and MAX_WAIT_TIME due to power
>
>    consumption saving or other reasons.  Of course, a client MUST
>
>    listen for a Reconfigure if it has negotiated for its use with the
>
>    server.
>
>
>
> There’s a lot of text in BCP 145, UDP Usage Guidelines, but there’s no
> direct recommendation (at least that I found).
>
>
>
> And, perhaps there is a good argument to make MAX_WAIT_TIME smaller (30
> seconds)?
>
>
>
> Not transport related, but should be fixed:
>
>
>
>  In Section 6.5, don't cite both RFC 3041 and RFC 4941 (about IPv6 privacy
> addresses), because RFC 4941 obsoletes RFC 30410.
>
>
>
> BV> Yes, this has been recommended by others and we will remove 3041.
>
>
>
> ---------------
>
>
>
> I expect there are some risks in the space of congestion avoidance when
> the up-to-32 transparent relays are in place, and I'd want to see (for
> future reference, not requesting a change here) some consideration about
> this before this spec moves from PS to Full Standard.
>
>
>
> BV> OK, we can ignore for now. However, it may just be appropriate to
> reduce the HOP_COUNT_LIMIT value (in 3315bis). I think a value of 8 would
> be far more reasonable and still be much more than anyone would ever need
> (and if it becomes an issue, then write an Internet-Draft to increase and
> address any congestion avoidance issues). I think that would also address
> your concern now, which is better than to do changes later (especially if
> not needed).
>
>
>
> All networks I’m aware of have only used 1 relay agent. I think RFC 6221
> (Lightweight DHCPv6 Relay Agent), in some deployments, might have 2.
> Setting limit to 8 would still provide plenty of headroom.
>
>
>
>
>
> ​
>
>
>