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

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

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]>; [e-mail]; [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]<mailto:[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.


​