[Iot-directorate] Iotdir last call review of draft-ietf-6lo-backbone-router-13

Dominique Barthel via Datatracker <noreply@ietf.org> Thu, 30 January 2020 17:51 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: iot-directorate@ietf.org
Delivered-To: iot-directorate@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE131200B8; Thu, 30 Jan 2020 09:51:23 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Dominique Barthel via Datatracker <noreply@ietf.org>
To: <iot-directorate@ietf.org>
Cc: last-call@ietf.org, draft-ietf-6lo-backbone-router.all@ietf.org, 6lo@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.116.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Dominique Barthel <dominique.barthel@orange.com>
Message-ID: <158040668306.10190.15300577530854340486@ietfa.amsl.com>
Date: Thu, 30 Jan 2020 09:51:23 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-directorate/KOevRWbaAb8zBLbZTxLi-PUo2eM>
Subject: [Iot-directorate] Iotdir last call review of draft-ietf-6lo-backbone-router-13
X-BeenThere: iot-directorate@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Mailing list for the IoT Directorate Members <iot-directorate.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iot-directorate>, <mailto:iot-directorate-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iot-directorate/>
List-Post: <mailto:iot-directorate@ietf.org>
List-Help: <mailto:iot-directorate-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iot-directorate>, <mailto:iot-directorate-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jan 2020 17:51:23 -0000

Reviewer: Dominique Barthel
Review result: Ready with Nits

Thanks to the authors for this work.
I think this document is ready, with a few nits as described below.
I found it clear, including comprehensive introduction and reference sections.
Here are a few comments/questions, followed by a list of merely editorial nits.

# Comments/Questions:
Picture 1., which gives a global view of the architecture we are talking about,
should be referenced as soon as end of Intro (specifically, together with “This
specification defines the 6BBR as a Routing Registrar …”.

3. Overview:
Picture 1 shows one 6BBR per LLN. Can an LLN operate with multiple 6BBRs, to
avoid single point of failure?

“The combined Binding Tables of all the 6BBRs on a backbone form a distributed
database of 6LNs that reside in the LLNs or on the IPv6 Backbone.” From the
definition of 6LN and from Figure 1., it had not occurred to me that a 6LN
could reside on the Backbone. Can you clear out this doubt?

“The proxy-ND operation can co-exist with IPv6 ND over the Backbone.”
I seems to me that IPv6 ND will happen on the Backbone no matter what the 6BBR
does. Do you mean “The proxy-ND operation of the 6BBR can co-exist with the
6BBR bridging IPv6 ND between the Backbone and the LLN.”?

“The 6BBR may co-exist with a proprietary snooping or …“. My understanding of
the 6BBR is that is is a box containing a set of functions. Which function of
the 6BBR is specifically being referenced here?

3.2 Access Link
Figure 2 has two arrows pointing to nowhere. What is the information being
conveyed by this representation? multicast? Another arrow has the (multicast)
annotation but does not have the same graphical representation.

3.3 Route-Over Mesh
I suggest to add a picture showing the LLN mesh structure, with 6LNs, 6LRs and
a 6LBR. This would ease the reading of the text. I’m sure you can rip one such
picture off of another draft. BTW, can there be multiple 6LBRs for one LLN,
much like multiple DAG roots for RPL. If yes, this needs to be mentionned, and
maybe doarn in the picture.

Figure 3. Same comment about arrows pointing to nowhere (a 3 arrows bunch, in
this picture, as opposed to 2, in the previous picture).

“Addresses in a LLN … must be registered … “. Is the use of lowercase “must”
intended? “Over the LLN, Binding Table management is as follows:” Sorry to
sound stupid, but the list of actions does not include the initial
registration. Likewise, the transitions between the Tentative, Reachable or
Stale states are not described fully, left to the reader to imagine. The tone
of voice of the Binding Table management is narrative. Why is RFC2119 language
not used? After reading section 9, it occurred to me that this description
might just be a preview of section 9. If true, please state this explicitely
and add a forward reference.

“If this registration is”. Not sure what “this” refers to. Was this piece of
text moved around?

“Global including Unique Local addresses”
Why “including”? Aren’t they disjoint ranges?

How does Section 9 “Creating and Maintaining a Binding” articulate with Section
3.4 “The Binding Table”? Is 3.4 just a preview (hence the narrative style)? In
which case, a forward reference from 3.4 to 9 would be useful.

“An NS(DAD) with no EARO or with an EARO that indicates a duplicate If the
Registration Lifetime is of a long duration, …” Cut&Paste error?

# Nits:
- “In practice, IPv6 addresses very rarely conflict because of the entropy of
the 64-bit Interface IDs, not because address duplications are detected and
resolved.” -> “In practice, the fact that IPv6 addresses very rarely conflict
is mostly attributable to the entropy of the 64-bit Interface IDs, not to the
address duplicate detection and resolution mechanisms”. - inconsistent use of
“broadcasted” versus “broadcast” - 1. Intro : “that provide proxy services” ->
“provides” - 2.2 Bridging proxy : “6BR” -> “6BBR” - 3 Overview: “Figure 1
illustrates backbone link” -> “Figure 1 illustrates a backbone link” - 3
Overview: “In the case, the co-existing function” -> “Any such co-existing
function” - 3 Overview: “Registering Node” is a term defined in RFC8505.
However, “registering node” is also found in this document, without
capitalization. Please check if this is intentional. - 3 Overview: “.. MAY also
be used with a 6LBR, if one is present, and the 6BBR.” -> “between a 6LBR, if
one is present, and the 6BBR.” - 3.2 “The 6BBRs applies” -> “6BBR” - 3.2 “in
that example” -> “in this example” - 3.3 “The 6LBR (acting as Registering Node)
proxies the registration to the 6BBR, using [RFC8505] to register the addresses
the 6LN (Registered Node) on its behalf to the 6BBR”. -> “the addresses of the
6LN” -> “its” is ambiguous. I believe that, grammatically, "it" refers to the
subject, which is “the 6LBR” in this sentence. Better avoid any ambiguity by
rewriting, probably cutting the sentence into several ones. - 3.3 “As a
non-normative example of a Route-Over Mesh, the 6TiSCH architecture suggests …
, and is … ”. Ambiguous sentence. Break it in two. -> “a 6LBR that serves the
LLN. The latter is either …”. - 3.4 “a LLN”-> “an LLN” ? - 3.4 “Conflicting
registrations are solved by the 6BBRs transparently to the Registering Nodes.”
-> “6BBRs, transparently” - 3.6 “The router can then determine the freshest
EARO in case of a conflicting NA(EARO) messages,” -. “in case of conflicting
NA(EARO) messages,” - 5. “This specification enables an address to be
registered to more than one 6BBR.” -> “allows for an address to be registered
at more than on 6BBR”. - 5. “a 6LBR MUST be capable to maintain a state”->
“capable of maintaining” - 8. “It acts as a Layer-2 Bridge for all types
unicast packets” -> “all types of unicast packets” - 8. “the 6BBR MUST either
answer directly to the NS(Lookup) message or” -> “the 6BBR MUST either answer
the NS(Lookup) message directly or” - 8. “it is eventually be discovered“ ->
“it is eventually discovered“ - 9. “pointing on the registering node” ->
“pointing to the registering node” - 9. “A Bridging Proxy MAY register Link
Local addresses to the 6BBR and proxy ND for those addresses over the
backbone.”. -> “register at the 6BBR“ or “register by the 6BBR”. -> “for these
addresses” - 9. “the current DAD operation continues as it was” -> “continues
unaltered” ? - 9.2 “in order to a allow for a parallel registration to arrive
to this node” -> “to allow” -> “to arrive at” - 9.2 “that is not as fresh as
this“ -> “that is not as fresh as this Binding“? - 9.3 “the 6BBR MUST attempts
a NUD procedure” ->  “attempt” - 10 “routing registrar” -> “Routing Registrar”
- 11 Security Considerations: “either by means of physical or IP security for
the Backbone Link or MAC-layer security.” bad grammatical construct. - 11
Security Considerations: “A possible attack …  can easily … take over.” From
the quoted text, it looks that the attack described succeeds. From the next
sentence in the paragraph, it looks that the attack does not succeed. Can you
rephrase or elaborate? For example “One could think that a possible attack
would be …. But …” - 12 Protocol Constants: “relatively long value” is used
twice, even though the recommended value is very different. I guess you mean
   SHOULD be configured to a value that is long relative to the address
   lifetime. For example, in LLNs with …, a good value is …”.
- Appendix B: “The term LLN is used … , meeting the requirements listed in … “.
I guess you mean something slightly different. Using the term “LLN” cannot by
itself meet the technical requirements of App B.3 of RFC8505. - Appendix B:
“Each LLN in the subnet is attached at an IPv6 Backbone Router (6BBR).” ->
“attached to an IPv6 Backbone Router (6BBR)”, or “attached to the Backbone
through a 6BBR”. - Appendix B: “In this way,” -> “This way, “ - Appendix B:
“The IPv6 ND operation is minimized as the number of 6LNs grows in the LLN.” ND
where? On the Backbone, the number of ND operations still grows with the number
of 6LNs in the LLNs, I beleive. What does “minimized” exactly means, btw? In
absolute numbers? In relative numbers?