[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf
Subject: RE: Tsvart Last Call/telechat review of draft-ietf-dhc-rfc3315bis-10
From: "Bernie Volz (volz)" <volz () cisco ! com>
Date: 2018-01-25 21:20:02
Message-ID: 33649dcec893424a8146ca5850bd6a55 () XCH-ALN-003 ! cisco ! com
[Download RAW message or body]
[Attachment #2 (text/plain)]
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:allison.mankin@gmail.com]
Sent: Thursday, January 25, 2018 4:09 PM
To: Bernie Volz (volz) <volz@cisco.com>
Cc: dhcwg@ietf.org; IETF Discussion <ietf@ietf.org>; \
draft-ietf-dhc-rfc3315bis.all@ietf.org; tsv-art@ietf.org; ajm \
<allison.mankin@gmail.com>
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)" \
<volz@cisco.com<mailto:volz@cisco.com>> wrote: Hi:
Thanks much for the review.
See the comments inline below (BV>).
- Bernie
From: Allison Mankin \
[mailto:allison.mankin@gmail.com<mailto:allison.mankin@gmail.com>]
Sent: Wednesday, January 24, 2018 5:44 PM
To: tsv-art@ietf.org<mailto:tsv-art@ietf.org>
Cc: IETF Discussion <ietf@ietf.org<mailto:ietf@ietf.org>>; \
draft-ietf-dhc-rfc3315bis.all@ietf.org<mailto:draft-ietf-dhc-rfc3315bis.all@ietf.org>; \
dhcwg@ietf.org<mailto:dhcwg@ietf.org>
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 tsv-art@ietf.org<mailto:tsv-art@ietf.org> 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.
[Attachment #3 (text/html)]
<html xmlns:v="urn:schemas-microsoft-com:vml" \
xmlns:o="urn:schemas-microsoft-com:office:office" \
xmlns:w="urn:schemas-microsoft-com:office:word" \
xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" \
xmlns="http://www.w3.org/TR/REC-html40"> <head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
p.m8567426213618545551msolistparagraph, li.m8567426213618545551msolistparagraph, \
div.m8567426213618545551msolistparagraph \
{mso-style-name:m_8567426213618545551msolistparagraph; mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:2144301126;
mso-list-type:hybrid;
mso-list-template-ids:1545347862 -1640712960 67698691 67698693 67698689 67698691 \
67698693 67698689 67698691 67698693;} @list l0:level1
{mso-level-start-at:32;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New",serif;}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New",serif;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New",serif;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Hi \
Allison:<o:p></o:p></span></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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.<o:p></o:p></span></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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.<o:p></o:p></span></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Stay \
tuned … we expect to provide the -11 draft to all reviewers for a quick once over \
(compare against -10) before publishing.<o:p></o:p></span></p> <p \
class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><![if \
!supportLists]><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><span \
style="mso-list:Ignore">-<span style="font:7.0pt "Times New \
Roman""> \
</span></span></span><![endif]><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Bernie<o:p></o:p></span></p>
<p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Allison Mankin \
[mailto:allison.mankin@gmail.com] <br>
<b>Sent:</b> Thursday, January 25, 2018 4:09 PM<br>
<b>To:</b> Bernie Volz (volz) <volz@cisco.com><br>
<b>Cc:</b> dhcwg@ietf.org; IETF Discussion <ietf@ietf.org>; \
draft-ietf-dhc-rfc3315bis.all@ietf.org; tsv-art@ietf.org; ajm \
<allison.mankin@gmail.com><br> <b>Subject:</b> RE: Tsvart Last Call/telechat \
review of draft-ietf-dhc-rfc3315bis-10<o:p></o:p></span></p> <p \
class="MsoNormal"><o:p> </o:p></p> <p>Bernie,<o:p></o:p></p>
<p>Thank you for the very responsive reply. I just went through it carefully and I \
like all of your suggestions for handling my comments.<o:p></o:p></p> <p>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. <o:p></o:p></p>
<p>Best,<o:p></o:p></p>
<p>Allison<o:p></o:p></p>
<div>
<p class="MsoNormal">On Jan 25, 2018 12:01 PM, "Bernie Volz (volz)" <<a \
href="mailto:volz@cisco.com">volz@cisco.com</a>> wrote:<o:p></o:p></p> <blockquote \
style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in \
6.0pt;margin-left:4.8pt;margin-right:0in"> <div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Hi:</span><o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Thanks \
much for the review.</span><o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">See \
the comments inline below (BV>).</span><o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="m8567426213618545551msolistparagraph"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">-</span><span \
style="font-size:7.0pt;color:#1F497D">
</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Bernie</span><o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Allison Mankin \
[mailto:<a href="mailto:allison.mankin@gmail.com" \
target="_blank">allison.mankin@gmail.com</a>] <br>
<b>Sent:</b> Wednesday, January 24, 2018 5:44 PM<br>
<b>To:</b> <a href="mailto:tsv-art@ietf.org" target="_blank">tsv-art@ietf.org</a><br>
<b>Cc:</b> IETF Discussion <<a href="mailto:ietf@ietf.org" \
target="_blank">ietf@ietf.org</a>>; <a \
href="mailto:draft-ietf-dhc-rfc3315bis.all@ietf.org" \
target="_blank">draft-ietf-dhc-rfc3315bis.all@ietf.org</a>; <a \
href="mailto:dhcwg@ietf.org" target="_blank">dhcwg@ietf.org</a><br> <b>Subject:</b> \
Tsvart Last Call/telechat review of \
draft-ietf-dhc-rfc3315bis-10</span><o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> \
<div> <div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif">Reviewer: Allison \
Mankin</span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif">Reviewer Result: Ready with \
Issues</span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif"> </span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif">I've reviewed this document as part \
of TSV-ART's ongoing effort to review key<br> IETF documents. These comments were \
written primarily for the transport area<br> directors, but are copied to the \
document's authors for their information and<br> to allow them to address any issues \
raised. When done at the time of IETF Last<br> Call, the authors should \
consider this review together with any other last-call<br> comments they receive. \
Please always CC <a href="mailto:tsv-art@ietf.org" target="_blank"> \
tsv-art@ietf.org</a> if you reply to or<br> forward this \
review.</span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif"> </span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif">The draft brings together and \
updates multiple RFCs in order to provide a cleaned-up version of the DHCPv6 \
specification.</span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif"> </span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif">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.</span><o:p></o:p></p> \
</div> <div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif"> </span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif">The following \
transport-related comments should be considered for fixing before \
publication</span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif"> </span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif">1. In Section 5, which defines that \
the transport is UDP, add a normative reference to BCP 145, UDP Usage \
Guidelines.</span><o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">BV> \
OK, we can add.</span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif"> </span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif">2. There are several small issues \
about retransmissions: </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif"> </span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif">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</span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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)."</span><o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif">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</span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">BV> \
OK, we will rework the text in 18.3.11. Perhaps replace:</span><o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:10.0pt;font-family:"Courier \
New",serif;color:black"> If the server does not receive a Renew, \
Rebind, or Information-</span><o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:10.0pt;font-family:"Courier \
New",serif;color:black"> request message from the client in \
REC_TIMEOUT milliseconds, the</span><o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:10.0pt;font-family:"Courier \
New",serif;color:black"> server retransmits the Reconfigure message, \
doubles the REC_TIMEOUT</span><o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:10.0pt;font-family:"Courier \
New",serif;color:black"> value and waits again. The server \
continues this process until</span><o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:10.0pt;font-family:"Courier \
New",serif;color:black"> REC_MAX_RC unsuccessful attempts have been \
made, at which point the</span><o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:10.0pt;font-family:"Courier \
New",serif;color:black"> server SHOULD abort the reconfigure process \
for that client.</span><o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">With:</span><o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in"> <span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif">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. </span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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".</span><o:p></o:p></p> \
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">We \
can change 14.1's first sentence to add "or retransmits" to the end to clarify that \
this applies to all DHCP transmissions.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif">3. The following addition to the \
spec in Section 15 seems likely to cause excess \
retransmissions:</span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif"> </span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif"> A client is not expected to \
listen for a response during the entire<br> RT period and may turn off \
listening capabilities after a certain<br> time due to power consumption \
saving or other reasons. Of course, a<br> client MUST listen for a \
Reconfigure if it has negotiated for its use<br> with the \
server.</span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif"> </span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif">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. </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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?</span><o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> \
A client is not expected to listen for a response during the \
entire</span><o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> \
RT period and may turn off listening capabilities after waiting \
at</span><o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> \
least the shorter of RT and MAX_WAIT_TIME due to power</span><o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> \
consumption saving or other reasons. Of course, a client \
MUST</span><o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> \
listen for a Reconfigure if it has negotiated for its use with \
the</span><o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> \
server.</span><o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">There's \
a lot of text in BCP 145, UDP Usage Guidelines, but there's no direct recommendation \
(at least that I found).</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">And, \
perhaps there is a good argument to make MAX_WAIT_TIME smaller (30 \
seconds)?</span><o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif">Not transport related, but should be \
fixed: </span><o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif"> </span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif"> In Section 6.5, don't cite \
both RFC 3041 and RFC 4941 (about IPv6 privacy addresses), because RFC 4941 obsoletes \
RFC 30410.</span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">BV> \
Yes, this has been recommended by others and we will remove \
3041.</span><o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif">---------------</span><o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif"> </span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif">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.</span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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).</span><o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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.</span><o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif"></span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
style="font-family:"Arial",sans-serif"> </span><o:p></o:p></p> </div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic