Reviewer: Jürgen Schönwälder
Thanks a bunch, Jürgen, for your review. It seems overall that we could add a "management" section in the requirements. This specification does not cover the management though.
Review result: Has Issues
>> As an outsider, I would also have preferred to see the message formats before reading the details how protocol entities have to use the message fields and react to messages received. But this may be personal preference. Overall, I found the text to be clear, except where noted below.
>> From an operational point of view, I wonder whether there is work planned to enable the network administrator to monitor registrations and to identify routers that run out of registration capacity or to detect high numbers of failing registrations (which could have technical reasons but could also be caused by malicious activity).
>> The text says network administrators should make sure there is sufficient registration capacity but without any way to monitor usage of registration capacity, this may be difficult to achieve in environments where the network administrator has not control over devices getting deployed.
PT> Added a requirement section as follows
<section anchor='Req7'
title="Requirements Related to Operations and Management">
<t> Section 3.8 of
<xref target="RFC1558">"Architectural Principles of the Internet"</xref>
recommends to : "Avoid options and parameters whenever possible.
Any options and parameters should be configured or negotiated
dynamically rather than manually".
This is especially true in LLNs where the number of devices may be large
and manual configuration is infeasible.
Capabilities for a dynamic configuration of LLN devices can also be
constrained by the network and power limitation.
</t><t>
A Network Administrator should be able to validate that the network
is operating within capacity, and that in particular a 6LBR does not
get overloaded with an excessive amount of registration, so he can take
actions such as adding a backbone link with additional 6LBRs and 6BBRs
to his network.
</t>
<t>
Related requirements are:
</t>
<t>
Req7.1: A management model SHOULD be provided providing access to the
6LBR and its capacity. It is recommended that the 6LBR be reachable over
a non-LLN link.
</t>
<t>
Req7.2: A management model SHOULD be provided providing access to the
6LR and its capacity to host additional NCE. This management model
SHOULD avoid polling individual 6LRs n a way that could disrupt the
operation of the LLN.
</t>
<t>
Req7.3: information on successful and failed registration SHOULD be
provided, including information such as the RUID of the 6LN, the
Registered Address, the Address of the 6LR and the duration of the
registration flow.
</t>
<t>
Req7.4: In case of a failed registration, information on the failure
including the identification of the node that rejected the registration
and the status in the EARO SHOULD be provided
</t>
</section> <!-- end section
"Requirements Related to Operations and Management" -->
******************
>> Section 2:
>> - What is the 'legacy 6LoWPAN ND specification'? I found out later that legacy is a defined term in Section 3. Perhaps it makes sense to first define the terminology, i.e., swapping sections 2 and 3.
PT> Done; I changed "legacy" to "RFC6775-only" per a comment by Carsten on this thread
*************************
>> - 'With this specification, a failed or useless registration can be detected...' - detected by whom? The entity registering or the
entity managing the registrations?
PT> Both; usually the entity taking the registration, but it can be a time out on the registering node as well. This section deals with the former so I changed the text to:
"
With this specification, a failed or useless registration can be detected
by a 6LR or a 6LBR for reasons other than address duplication.
"
********************
>>- There is advice that network administrators should deploy 6LR/6LBRs
matching the number and type of devices. Since it is usually
difficult to know how many registrations a network will require, is
there a way to find out when the 6LR/6LBRs run out of capacity or is
there a way to monitor the usage of the registration capacity?
PT > Not through this protocol. But I added requirements in the requirements section that lists them all and points at the drafts that cover them.
*************************
>>Section 3:
>> - The phrase 'to be a higher speed device speed' is odd; note that you are actually talking about a link and its datarate.
PT > Something went wrong with that sentence, thanks for spotting it. It now reads:
"
An IPv6 transit link that interconnects two or more Backbone Routers.
It is expected to be of high speed compared to the LLN in order to carry ...
"
*************************
>>Section 4:
>> - Note sure I understand the sentence that includes 'is be saturated'. I guess you mean:
>> If the registry in the 6LBR is saturated, then the LBR cannot decide whether a new address is a duplicate.
PT > I used your words : )
>> But perhaps I have not understood the situation really. I understand that once saturated, registration requests are denied. Perhaps all you wanted to say is this:
>> If the registry in the 6LBR is saturated, then the LBR replies to a EDAR message with a EDAC message that carries a Status code 9 indicating "6LBR Registry saturated",
PT> Both actually. The previous sentence indicates that the condition prevents a normal DAD operation.
*************************
>>Section 5:
>> - s/is a used as a/is used as a/
PT> fixed
*************************
>>Section 7:
>> - Is there a verb missing in the first sentence of 7.1.2?
PT> Unsure; I fixed to:
"
One alternate way for a 6LN to discover the router's capabilities is to
start by registering a Link Local address, placing the same address in
the Source and Target Address fields of the NS message, and setting
the "T" Flag.
"
Does that read better?
*************************
>> - s/in a registration flows/in a registration flow/
PT> fixed
*************************
>> Section 8:
>> - RFC 6775 is not really a 'draft'
PT> changed to "standard"
*************************
- s/requesting a node the/requesting node the/
PT> done
*************************
>> - I wonder to what extend the expectation that the underlying network provides secure unicast and multicast services and that there is a trust model in place that ensures that only the right devices act as 6LBR and 6BBR is wishful thinking. Should the document more clearly spell out how fragile things will be if this is not the case? Should the document provide concrete pointers how to satisfy these requirements? I know, this is a nasty question but deploying this technology without proper protection sounds like a real problem. Anyway, this is probably for the secdir reviewers to think about.
PT> Yes, SEC DIR recommended to add text in -12 that I just published (you reviewed -11) on that point exactly, see the last sentence of the security section.
*************************
>> Section 9:
>> - s/section Section/Section/
PT> done
*************************
>> - Should there be any discussion of the possibility to monitor movements? Should a device actually claim a different identity when moving?
PT> The WG did not discuss that point for all I know. The node is always free to move and form new addresses with different unique IDs now that we do not force to base it on EUI-64. But if a node needs to conserve its address then it needs the same unique ID in the ARO.
Thanks real much Juergen, this was a great review! The changes above, if you agree with them, will be published in -13 soon. Please let me know.
Take care;
Pascal
-----Original Message-----
From: Jürgen Schönwälder [mailto:j.schoenwaelder@xxxxxxxxxxxxxxxxxxxx]
Sent: mercredi 21 février 2018 19:07
To: ops-dir@xxxxxxxx
Cc: draft-ietf-6lo-rfc6775-update.all@xxxxxxxx; ietf@xxxxxxxx; 6lo@xxxxxxxx
Subject: Opsdir telechat review of draft-ietf-6lo-rfc6775-update-11
Reviewer: Jürgen Schönwälder
Review result: Has Issues
As an outsider, I would also have preferred to see the message formats before reading the details how protocol entities have to use the message fields and react to messages received. But this may be personal preference. Overall, I found the text to be clear, except where noted below.
>From an operational point of view, I wonder whether there is work
planned to enable the network administrator to monitor registrations and to identify routers that run out of registration capacity or to detect high numbers of failing registrations (which could have technical reasons but could also be caused by malicious activity).
The text says network administrators should make sure there is sufficient registration capacity but without any way to monitor usage of registration capacity, this may be difficult to achieve in environments where the network administrator has not control over devices getting deployed.
Section 2:
- What is the 'legacy 6LoWPAN ND specification'? I found out later
that legacy is a defined term in Section 3. Perhaps it makes sense
to first define the terminology, i.e., swapping sections 2 and 3.
- 'With this specification, a failed or useless registration can be
detected...' - detected by whom? The entity registering or the
entity managing the registrations?
- There is advice that network administrators should deploy 6LR/6LBRs
matching the number and type of devices. Since it is usually
difficult to know how many registrations a network will require, is
there a way to find out when the 6LR/6LBRs run out of capacity or is
there a way to monitor the usage of the registration capacity?
Section 3:
- The phrase 'to be a higher speed device speed' is odd; note that you
are actually talking about a link and its datarate.
Section 4:
- Note sure I understand the sentence that includes 'is be
saturated'. I guess you mean:
If the registry in the 6LBR is saturated, then the LBR
cannot decide whether a new address is a duplicate.
But perhaps I have not understood the situation really. I understand
that once saturated, registration requests are denied. Perhaps all
you wanted to say is this:
If the registry in the 6LBR is saturated, then the LBR
replies to a EDAR message with a EDAC message
that carries a Status code 9 indicating "6LBR Registry saturated",
Section 5:
- s/is a used as a/is used as a/
Section 7:
- Is there a verb missing in the first sentence of 7.1.2?
- s/in a registration flows/in a registration flow/
Section 8:
- RFC 6775 is not really a 'draft'
- s/requesting a node the/requesting node the/
- I wonder to what extend the expectation that the underlying network
provides secure unicast and multicast services and that there is a
trust model in place that ensures that only the right devices act as
6LBR and 6BBR is wishful thinking. Should the document more clearly
spell out how fragile things will be if this is not the case? Should
the document provide concrete pointers how to satisfy these
requirements? I know, this is a nasty question but deploying this
technology without proper protection sounds like a real problem.
Anyway, this is probably for the secdir reviewers to think about.
Section 9:
- s/section Section/Section/
- Should there be any discussion of the possibility to monitor
movements? Should a device actually claim a different identity when
moving?
