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

[<[e-mail]>]

Hello Pascal,

Attached is a text file with my nits.
I hope you can sort out the line ending issue.
It displays cleanly on my side.
Best regards

Dominique

Le 31/01/20 17:55, « Pascal Thubert (pthubert) » <[e-mail]> a
écrit :

>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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6lo


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.