Subject: [Tsv-art] Tsvart Last Call/telechat review of draft-ietf-dhc-rfc3315bis-10

From: Allison Mankin <[email-masked]>
Date: Wed, 24 Jan 2018 17:44:05 -0500

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 [email-masked] 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.

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

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

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.

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.

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.

---------------

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.

​

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 25 Jan 2018 17:01:51 +0000

Hi:

Thanks much for the review.

See the comments inline below (BV>).

-          Bernie

From: Allison Mankin [mailto:[email-masked]]
Sent: Wednesday, January 24, 2018 5:44 PM
To: [email-masked]
Cc: IETF Discussion <[email-masked]>; [email-masked]; [email-masked]
Subject: Tsvart Last Call/telechat review of draft-ietf-dhc-rfc3315bis-10

Reviewer: Allison Mankin

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 [email-masked]<mailto:[email-masked]> 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.

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:

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

 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.

​

---

From: Allison Mankin <[email-masked]>
Date: Thu, 25 Jan 2018 16:08:50 -0500

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)" <[email-masked]> wrote:

> *From:* Allison Mankin [mailto:[email-masked]]
> *Sent:* Wednesday, January 24, 2018 5:44 PM
> *To:* [email-masked]
> *Cc:* IETF Discussion <[email-masked]>; draft-ietf-dhc-rfc3315bis.all@
> ietf.org; [email-masked]
> *Subject:* Tsvart Last Call/telechat review of
> draft-ietf-dhc-rfc3315bis-10
>
>
>
> Reviewer: Allison Mankin
>
> 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
> 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
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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?
>
>
>
> There’s a lot of text in BCP 145, UDP Usage Guidelines, but there’s no
> direct recommendation (at least that I found).
>
>
>
> 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.
>
>
>
>
>
> ​
>
>
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 25 Jan 2018 21:20:02 +0000

Hi Allison:

The authors will discuss the relay issue and as the DHC WG is CC’d, if anyone there has issues with reducing the HOP_COUNT_LIMIT from 32 to 8, they can chime in.

FYI: Tomek Mrugalski and I have been putting together a Google sheet with all of the review and IESG comments (there are about 134 separate “issues”, including duplicates, from all of the reviews) and our intended actions. Some are duplicates, but there are a large number. It may take us a bit to work through everything.

Stay tuned … we expect to provide the -11 draft to all reviewers for a quick once over (compare against -10) before publishing.

-          Bernie

From: Allison Mankin [mailto:[email-masked]]
Sent: Thursday, January 25, 2018 4:09 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: [email-masked]; IETF Discussion <[email-masked]>; [email-masked]; [email-masked]; ajm <[email-masked]>
Subject: RE: Tsvart Last Call/telechat review of draft-ietf-dhc-rfc3315bis-10

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)" <[email-masked]<mailto:[email-masked]>> wrote:
Hi:

-          Bernie

From: Allison Mankin [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, January 24, 2018 5:44 PM
To: [email-masked]<mailto:[email-masked]>
Cc: IETF Discussion <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Tsvart Last Call/telechat review of draft-ietf-dhc-rfc3315bis-10

Reviewer: Allison Mankin

BV> OK, we can add.

With:

---------------

​