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

["Pascal Thubert (pthubert)" <[e-mail]>]

Perfect that way!!!!

Many thanks Dominique I'll go through that next.

Have a great week end 😊

Pascal

> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: vendredi 31 janvier 2020 18:19
> To: Pascal Thubert (pthubert) <[e-mail]>; [e-mail]
> Cc: [e-mail]
> Subject: Re: [6lo] Iotdir last call review of draft-ietf-6lo-backbone-router-13
> 
> 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.