Hello Dominique:
Many thanks for your great review! Let's see below:
> # 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 …”.
Good point! the intro text now looks like:
"
This specification defines the 6BBR as a Routing Registrar [RFC8505]
that provide proxy services for IPv6 Neighbor Discovery. As
represented in Figure 1, Backbone Routers federate multiple LLNs over
a Backbone Link to form a MultiLink Subnet (MLSN). Backbone Routers
placed along the LLN edge of the Backbone handle IPv6 Neighbor
Discovery, and forward packets on behalf of registered nodes.
"
> 3. Overview:
> Picture 1 shows one 6BBR per LLN. Can an LLN operate with multiple 6BBRs,
> to avoid single point of failure?
Sure; I reused an image that illustrates RPL DODAGs but that was a bad idea.
What about this (sorry if your font is not fixed size): ?
|
+-----+ +-----+ +-----+ IPv6
(default) | | (Optional) | | | | Node
Router | | 6LBR | | | | or
+-----+ +-----+ +-----+ 6LN
| Backbone side | |
----+-------+-----------------+---+-------------+----+-----
| | |
+------+ +------+ +------+
| 6BBR | | 6BBR | | 6BBR |
| | | | | |
+------+ +------+ +------+
o Wireless side o o o o o o
o o o o o o o o o o o o o o o o o o o o
o o o o o o o o o o o o o o o o o o o
o o o o o o o o o LLN o o o o o o o o o
o o o o o o o o o o o o o o
o o o
>
> “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?
Actually a 6LN is a L3 construct and as such can be attached to any network including Wi-Fi or Ethernet.
e.g., you could have a device that sleeps and needs a 6BBR acting as sleeping proxy.
There might be a need for additional text when we really work on a 6LN sitting in the backbone, e.g., to insist that the 6LN does not listen to multicast NS so it ignores DAD and Lookup, which are handled by the 6BBR.
Suggestion is to turn the last block of the intro as:
"
A 6LoWPAN node (6LN) registers all its IPv6 Addresses using an
NS(EARO) as specified in [RFC8505] to the 6BBR. The 6BBR is also a
Border Router that performs IPv6 Neighbor Discovery (IPv6 ND)
operations on its Backbone interface on behalf of the 6LNs that have
registered addresses on its LLN interfaces without the need of a
broadcast over the wireless medium. A 6LN that resides on the
backbone does not register to the SNMA groups associated to its
Registered Addresses and defers to the 6BBR to answer or preferably
forward to it as unicast the corresponding multicast packets.
"
> “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.”?
I agree ND will be there. I meant that there can be normal nodes doing ND and 6BBR proxying ND on a same backbone.
Proposed clarification:
"
The operation of IPv6 ND and of proxy-ND are not mutually exclusive
on the Backbone, meaning that nodes attached to the Backbone and
using IPv6 ND can transparently interact with 6LNs that rely on a
6BBR to proxy ND for them, whether the 6LNs are reachable over a LLN
or directly attached to the Backbone.
"
>
> “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?
Clarifying to
"
The [RFC8505] registration mechanism used to learn addresses to be
proxied for may co-exist in a 6BBR with a proprietary snooping or the
traditional bridging functionality of an Access Point, in order to
support legacy LLN nodes that do not support this specification.
"
Works ?
> 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.
True and True.
The RS(multicast) is intercepted by the AP, so it will never be really multicast over the wireless.
The multiple arrows effectively denote a real multicast.
Let le add text to explain that prior to the picture
"
The RS sent initially by the 6LN(STA) is a transmitted as a multicast but
since it is intercepted by the 6BBR, it is never effectively broadcasted.
The multiple arrows associated to the ND messages on the backbone denote a
real Layer-2 broadcast.
"
> 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.
OK let me add pictures for both cases
"
The simplest topology from the Layer-3 perspective occurs when the
wireless network appears as a single hop hub-and-spoke network as
shown in Figure 2. The Layer-2 operation may effectively be hub-and-
spoke (e.g., Wi-Fi) or Mesh-Under, with a Layer-2 protocol handling
the complex topology.
|
+-----+ +-----+ +-----+ IPv6
(default) | | (Optional) | | | | Node
Router | | 6LBR | | | | or
+-----+ +-----+ +-----+ 6LN
| Backbone side | |
----+-------+-----------------+---+-------------+----+-----
| | |
+------+ +------+ +------+
| 6BBR | | 6BBR | | 6BBR |
| 6LR | | 6LR | | 6LR |
+------+ +------+ +------+
(6LN) (6LN) (6LN) (6LN) (6LN) (6LN) (6LN) (6LN)
Figure 2: Access Link Use case
"
And
"
3.3. Route-Over Mesh
A more complex Multi-Link Subnet topology occurs when the wireless
network appears as a Layer-3 Mesh network as shown in Figure 4. A
so-called Route-Over routing protocol exposes routes between 6LRs
towards both 6LRs and 6LNs, and a 6LBR acts as Root of the Layer-3
Mesh network and proxy-registers the LLN addresses to the 6BBR.
|
+-----+ +-----+ +-----+ IPv6
(default) | | (Optional) | | | | Node
Router | | 6LBR | | | | or
+-----+ +-----+ +-----+ 6LN
| Backbone side | |
----+-------+-----------------+---+-------------+----+-----
| | |
+------+ +------+ +------+
| 6BBR | | 6BBR | | 6BBR |
+------+ +------+ +------+
| | |
+------+ +------+ +------+
| 6LBR | | 6LBR | | 6LBR |
+------+ +------+ +------+
(6LN) (6LR) (6LN) (6LR) (6LN) (6LR) (6LR) (6LR)(6LN)
(6LN)(6LR) (6LR) (6LN) (6LN) (6LR)(6LN) (6LR) (6LR) (6LR) (6LN)
(6LR)(6LR) (6LR) (6LR) (6LR)(6LN) (6LR) (6LR)(6LR)
(6LR) (6LR) (6LR) (6LR) (6LN)(6LR) (6LR) (6LR) (6LR) (6LR)
(6LN) (6LN)(6LN) (6LN) (6LN) (6LN) (6LN) (6LN) (6LN) (6LN)
Figure 4: Route-Over Mesh Use case"
> Figure 3. Same comment about arrows pointing to nowhere (a 3 arrows bunch,
> in this picture, as opposed to 2, in the previous picture).
>
Added same text
Please let me know if we are OK so far; I'll continue next week.
In the meantime, could you please resend the nits in a format that is not concatenated, if you still have that?
As below it is unreadable : (
Many thanks again!
pascal
> 3.4
> “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.
>
> 5
> “If this registration is”. Not sure what “this” refers to. Was this piece of text
> moved around?
>
> 7.
> “Global including Unique Local addresses”
> Why “including”? Aren’t they disjoint ranges?
>
> 9.
> 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.
>
> 9.2
> “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 “STALE_DURATION
> 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?
>
>
> _______________________________________________
> 6lo mailing list
> 6lo@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/6lo
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
