Subject: Re: [6tisch] Last Call: <draft-ietf-6tisch-minimal-17.txt> (Minimal 6TiSCH Configuration) to Best Current Practice

From: Ralph Droms <[email-masked]>
Date: Mon, 30 Jan 2017 11:56:25 -0500

I've reviewed draft-ietf-6tisch-minimal-19.  Thank you to the authors and the WG for considering the input from my earlier reviews and careful revision of the document to address that input.

In general, I think the document is now almost ready for publication.  The major points from my review of -17 have been addressed.

I do have a few minor points for the authors and WG to consider:

Does the WG have consensus that IPv6 address selection, prefix advertisement, and the details of ND need not be addressed in this document?

I don't see a default value for EB_PERIOD defined anywhere.  Is such a definition needed?

Section 5.2 requires implementation of RPL non-storing mode and recommends implementation of storing mode.  How does a node know whether RPL is being used in non-storing or storing mode?

- Ralph

---

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Tue, 31 Jan 2017 08:21:59 +0100

Dear Ralph,

thanks for your comments. Let me answer inline some of your questions:

2017-01-30 17:56 GMT+01:00 Ralph Droms <[email-masked]>:

> I've reviewed draft-ietf-6tisch-minimal-19.  Thank you to the authors and
> the WG for considering the input from my earlier reviews and careful
> revision of the document to address that input.
>
> In general, I think the document is now almost ready for publication.  The
> major points from my review of -17 have been addressed.
>
> Does the WG have consensus that IPv6 address selection, prefix
> advertisement, and the details of ND need not be addressed in this
> document?
>

> The EB_PERIOD determines the join time and impacts energy consumption. The
value is a trade-off of this two elements according to the network
administrator, as shorter the EB period more energy is used but sooner the
nodes join the network. This number does not affect different vendor nodes
aiming to join the same network (in terms of inter-operability). For us
this is more a network policy, IMHO defining a default value would not fit
most of the cases.

> Section 5.2 requires implementation of RPL non-storing mode and recommends
> implementation of storing mode.  How does a node know whether RPL is being
> used in non-storing or storing mode?
>
> This is detected by the MOP field in the DIO. When a DIO is received the
MOP is checked. According to RF6550

   Mode of Operation (MOP): The Mode of Operation (MOP) field identifies
         the mode of operation of the RPL Instance as administratively
         provisioned at and distributed by the DODAG root.  All nodes
         who join the DODAG must be able to honor the MOP in order to
         fully participate as a router, or else they must only join as a

> - Ralph

regards,
Xavi
-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
(+34) 646 633 681
[email-masked] <[email-masked]>
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain

---

From: Ralph Droms <[email-masked]>
Date: Tue, 31 Jan 2017 07:04:20 -0500

> On Jan 31, 2017, at 2:21 AM, Xavi Vilajosana Guillen <[email-masked]> wrote:
> 
> Dear Ralph,
> 
> The EB_PERIOD determines the join time and impacts energy consumption. The value is a trade-off of this two elements according to the network administrator, as shorter the EB period more energy is used but sooner the nodes join the network. This number does not affect different vendor nodes aiming to join the same network (in terms of inter-operability). For us this is more a network policy, IMHO defining a default value would not fit most of the cases. 

Is it necessary for all devices in a network to use the same value EB_PERIOD? 

If so, how is that value communicated or configured in all devices?

Could the document recommend a value?

> This is detected by the MOP field in the DIO. When a DIO is received the MOP is checked. According to RF6550
> 

Ah, ok, thanks.

- Ralph

> 
>  
>> - Ralph
>> 
> 
> 
> regards,
> Xavi
> -- 
> Dr. Xavier Vilajosana
> Wireless Networks Lab
> Internet Interdisciplinary Institute (IN3)
> Professor
> (+34) 646 633 681
> [email-masked]
> http://xvilajosana.org
> http://wine.rdi.uoc.edu