Re: [6tisch] review of draft-ietf-6tisch-enrollment-enhanced-beacon

["Prof. Diego Dujovne" <[e-mail]>]

Pascal, Michael:
             Thanks for the comments. Answers below.
Regards,

                               Diego

Le lun. 25 mars 2019 à 05:47, Michael Richardson <[e-mail]> a
écrit :

>
> Thank you for this review!
>
> Pascal Thubert (pthubert) <[e-mail]> wrote:
>     > Page2 Introduction: there?s an EDNOTE: field. It could be useful but
>     > not necessary to make the proposed addition. Is the author willing
> to?
>     > Or should a coauthor help?
>
> } EDNOTE: Explain why broadcasts are rare, and why we need them. What the
> } Enhanced Beacon is, and what Information Elements are, and how the IETF
> has a
> } subtype for that area.  Explain what kind of things could be placed in
> } Information Elements, how big they could be, and how they could be
> } compressed.
>
> If the WG feels that this section needs to be filled in then I will work
> with
> Diego to fill it in.    Clearly less text is easier to review, but I think
> that non-6tisch reviewers will need some understanding of why we do what
> might be considered layer violations to pack all this L3 and routing
> information into a L2 object.
>
> I would prefer to write text like:
>        "[XYZ] explains how the availability of the broadcast is limited.
>        [ABC] details how the Enhanced Beacon is already used to do
> schedule synchronization"
>
> - One good reference for the low availability of broadcast nodes is Malisa
Vucinic et al. paper
"Broadcasting strategies in 6TiSCH networks" which mentions:
"State‐of‐the‐art approaches(2–4) address the problem by assigning
additional bandwidth; this comes with extra maintenance and energy cost.5
Using the Trickle timer6 to schedule EBs is not feasible in 6TiSCH as new
motes have no means of soliciting its reset without being synchronized with
the network."
- I think the details on the Enhanced beacon can be obtained both from
RFC8180
and from the IEEE802.15.4 standard.

Comments welcome.


> I would dearly like help from the WG on this text. Now that the
> architecture
> is more stable, perhaps they are just normative architecture document
> references?
>
>
>     > Suggestion to also refer to https://tools.ietf.org/html/
>     > draft-ietf-6tisch-architecture for terminology
>
> Done.
>
>     > ?
>
>     >    At layer 3, [RFC2461] defines a mechanism by
>
>     > ?
>
>     > Please use RFC 4861
>
> done.
>
>
>
>     > Section 1.3
>     > There?s a XXX leftover. What is the intention?
>
> No idea, removed.
>
>
>     >    proxy priority the proxy prority value contains a number from 0 to
>     >       0x7f.  Lower numbers are considered to be a higher
> preference.  A
>     >       priority of 0x7f indicates that the announcer should never be
>     >       considered as a viable enrollment proxy.  Lower value indicates
>     >       willing to act as a Join Proxy as described in
>     >       [I-D.ietf-6tisch-minimal-security].  Only unenrolled pledges
> look
>     >       at this value.
>
>
>     > ?
>
>     > Maybe indicate first that the field indicates the willingness to act
> as
>     > join proxy? Also, a typo (prority).
>
> Fixed.
>
>     > P and R bits definition; though it is quite obvious, the description
>     > does not say that ?R? is the RA bit and that ?P? is the Proxy Address
>     > bit. Maybe use the term flag, like in? the ?P? flag?.
>
> Okay.
>
>     >    join-proxy lower-64 if the P bit is set, then 64 bits (8 bytes) of
>     >       address are present.  The Link Layer address of the Join Proxy
> is
>     >       fe80 (as for any Link Layer address), and the bits given in
> this
>     >       field.
>
>     > ?
>
>     > I think you mean Link-Local not link layer? What about:
>
> Thank you, good catch.
>
>
>     >    join-proxy Interface ID if the P bit is set, then 64 bits (8
> bytes)
>     > of
>     >    address are present. This field provides the suffix of the
>     > Link_Local
>     >    address of the Join Proxy. The associated prefix is well-known as
>     >    fe80::/64.
>     > ?
>
>
>     >    In a 6tisch network, where RPL is u
>
>     > ?
>     > Missing reference to RFC 6550
>
> added.
>
>
>     > ?
>     > 2.1.  Protocol Example
>     >    Here will be three examples of processing.
>     > ?
>     > Do you intend to fill that section?
>
> At this point, I have no example packets, so I will remove that section.
> I have posted -02 with these changes.
> What lacks now is only a decision on how much text to put in the intro to
> explain broadcasts.
>
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>


-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125