Re: [6tisch] MSF Shepherd review

[Tengfei Chang]

Thanks Pascal, just integrated your suggestions to the latest version.

On Sat, Dec 7, 2019 at 12:00 AM Pascal Thubert (pthubert) <
pthub...@cisco.com> wrote:

> Very good Tengfei
>
> This addresses my comments.
>
> Note that the uppercase NOT is not a valid BCP14 term by itself. I’d
> reword to say that the distribution of traffic over multiple parents is a
> routing decision that is out of scope for MSF...
>
>
> Regards,
>
> Pascal
>
> Le 6 déc. 2019 à 12:01, Tengfei Chang  a écrit :
>
> 
> I will add the following text at the intro part of MSF draft:
>
>
>
>
>
>
> *MSF works closely with RPL, specifically the routing
> parent defined in .
>   This specification only describes how MSF works with one routing parent,
> which is phrased as "selected parent". The activity of MSF
> towards to single routing parent is called as a "MSF session".
> Though the performance of MSF is evaluated only when the "selected
> parent" represents node's preferred parent, there should be no restrictions
> to go multiple MSF sessions, one per parent. In case that
> traffic goes into multiple parents, MSF is NOT in charge of deciding how
> many traffic to assign or to which parent. This should be
> decided by either upper layer or some other entity in charge of traffic
> distributing.*
>
> Then replace the sentence in the draft from "preferred parent" to
> "selected parent".
>
> What are your comments on this, Pascal, Yatch?
>
> On Sat, Nov 30, 2019 at 12:31 AM Pascal Thubert (pthubert) <
> pthub...@cisco.com> wrote:
>
>> Hello Yatch
>>
>>
>>
>> > Le 29 nov. 2019 à 22:48, Yasuyuki Tanaka  a
>> écrit :
>> >
>> > Thank you, Pascal for your comment.
>> >
>> >> On 11/29/2019 9:34 PM, Pascal Thubert (pthubert) wrote:
>> >> RPL underneath is designed to operate with multiple parents, and for a
>> good reason.
>> >
>> > I understand that point.
>> >
>> > My point is, rephrasing the word alone couldn't be enough.
>> >
>> >> Bandwidth allocation doesn’t care what traffic that is or it’s
>> direction. It cares about the amount of traffic that needs to circulate
>> over the hop.
>> >
>> > In general, yes. According to the current text of MSF, the direction is
>> relevant. For a upward neighbor, MSF allocates one negotiated TX cell just
>> after recognizing it. For a downward neighbor, it doesn't.
>> >
>> > On parent switch, the number of negotiated cells is carried over to a
>> new parent. But what if a node has one parents at some point, then it
>> selects an additional parent to handle some portion of traffic? How many
>> negotiated cells should be scheduled with the new (additional) parent? MSF
>> would have no idea.
>> >
>> > To me, this seems a totally new thing to MSF.
>> >
>>
>> Not that new just the logical continuation.
>>
>> If a child has 2 parents a and b these are independent links, each with a
>> number of cells. If it loses one parent a then the traffic on that link is
>> rerouted. The cells on that link have to be moved to other parents which
>> can include b.
>>
>> The existing cells to the parent b are not touched. If some traffic is
>> rerouted to parent b then new cells are allocated there.
>>
>>
>> > Again, having multiple MSF instances could be a solution, which doesn't
>> need the rephrasing.
>>
>> For me instance is related to RPL I do not want to run multiple instances
>> of RPL with one preferred parent each.
>>
>> What I want is to run what the draft describes but several times in
>> parallel once per active parent.
>>
>> That’s what I called session. RPL says that a node can run separate
>> instances like ship in the night and then describes the operw of one
>> instance. Similarly MSF can run multiple sessions one per link as ship in
>> the night. pretty much the draft needs to do is say that in introduction
>> and then say that the rest of the draft describes one session with one
>> parent.
>>
>> >> And it is possible to run an MSF session at L2 with each of them
>> totally independently.
>> >
>> > What do you mean by "MSF session"? If you have multiple MSF instances
>> with different SFIDs or values for the Metadata field, they can be
>> associated with different RPL DODAGsm and they will work independently.
>> >
>>
>> The draft describes a session between a parent and a child. They start
>> the session, allocate resources in unison and when the session is broken
>> they release the resources on each side. This happens within a L2 link.
>> Sessions can live independently on different L2 links.
>>
>>
>>
>> > On 11/29/2019 9:40 PM, Prof. Diego Dujovne wrote:
>> > > Would it be then a neighbour instead of a parent? (Assuming the
>> > > neighbour has joined the network)
>> >
>> > I don't think so.
>> >
>>
>> As Yatch said the draft describes a child handling both sides so the link
>> is directional, there’s a master and a slave.
>>
>> This may become a problem for east west traffic with PDAO. But there’s
>> still a direction so it’s doable 

Re: [6tisch] MSF Shepherd review

[Tengfei Chang]

Hi Yatch,

The session is distinguished by the parent, there is no such case that two
MSF sessions have a 'common parent'.
MSF session to parent is 1 to 1 mapping relationship.
MSF session should be ends as long as a neighbor is un-selected as parent.

In the text, I agree we only details how MSF deal with one parent.
I think Pascal agree with this but just don't want to limit MSF to just one
parent, which is clarified in the paragraph I wrote above.

Tengfei



On Fri, Dec 6, 2019 at 9:43 PM Yasuyuki Tanaka 
wrote:

> Hi Tengfei,
>
> How do we distinguish multiple MSF sessions?
> What if two MSF sessions have a same "selected parent", and then one of
> them selects another selected parent? How many negotiated cells should
> be taken over to the new selected parent?
>
> These are not covered by the current text, and I think they are out of
> the scope of MSF.
>
> > This specification only describes how MSF works with one routing parent,
> which is phrased as "selected parent".
>
> So, yes, I believe we should have this case only in the text. If we
> mention some other possibilities without concrete ideas to implement,
> they would just confuse future readers.
>
> I think, Pascal has a different opinion.
>
> Best,
> Yatch
>


-- 
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] MSF Shepherd review

[Yasuyuki Tanaka]

Hi Tengfei,

How do we distinguish multiple MSF sessions?
What if two MSF sessions have a same "selected parent", and then one of 
them selects another selected parent? How many negotiated cells should 
be taken over to the new selected parent?


These are not covered by the current text, and I think they are out of 
the scope of MSF.



This specification only describes how MSF works with one routing parent, which is phrased 
as "selected parent".


So, yes, I believe we should have this case only in the text. If we 
mention some other possibilities without concrete ideas to implement, 
they would just confuse future readers.


I think, Pascal has a different opinion.

Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] MSF Shepherd review

[Tengfei Chang]

I will add the following text at the intro part of MSF draft:






*MSF works closely with RPL, specifically the routing
parent defined in .
This specification only describes how MSF works with one routing parent,
which is phrased as "selected parent".The activity of MSF
towards to single routing parent is called as a "MSF session".
Though the performance of MSF is evaluated only when the "selected
parent" represents node's preferred parent, there should be no restrictions
to go multiple MSF sessions, one per parent.In case that
traffic goes into multiple parents, MSF is NOT in charge of deciding how
many traffic to assign or to which parent.This should be
decided by either upper layer or some other entity in charge of traffic
distributing.*

Then replace the sentence in the draft from "preferred parent" to "selected
parent".

What are your comments on this, Pascal, Yatch?

On Sat, Nov 30, 2019 at 12:31 AM Pascal Thubert (pthubert) <
pthub...@cisco.com> wrote:

> Hello Yatch
>
>
>
> > Le 29 nov. 2019 à 22:48, Yasuyuki Tanaka  a
> écrit :
> >
> > Thank you, Pascal for your comment.
> >
> >> On 11/29/2019 9:34 PM, Pascal Thubert (pthubert) wrote:
> >> RPL underneath is designed to operate with multiple parents, and for a
> good reason.
> >
> > I understand that point.
> >
> > My point is, rephrasing the word alone couldn't be enough.
> >
> >> Bandwidth allocation doesn’t care what traffic that is or it’s
> direction. It cares about the amount of traffic that needs to circulate
> over the hop.
> >
> > In general, yes. According to the current text of MSF, the direction is
> relevant. For a upward neighbor, MSF allocates one negotiated TX cell just
> after recognizing it. For a downward neighbor, it doesn't.
> >
> > On parent switch, the number of negotiated cells is carried over to a
> new parent. But what if a node has one parents at some point, then it
> selects an additional parent to handle some portion of traffic? How many
> negotiated cells should be scheduled with the new (additional) parent? MSF
> would have no idea.
> >
> > To me, this seems a totally new thing to MSF.
> >
>
> Not that new just the logical continuation.
>
> If a child has 2 parents a and b these are independent links, each with a
> number of cells. If it loses one parent a then the traffic on that link is
> rerouted. The cells on that link have to be moved to other parents which
> can include b.
>
> The existing cells to the parent b are not touched. If some traffic is
> rerouted to parent b then new cells are allocated there.
>
>
> > Again, having multiple MSF instances could be a solution, which doesn't
> need the rephrasing.
>
> For me instance is related to RPL I do not want to run multiple instances
> of RPL with one preferred parent each.
>
> What I want is to run what the draft describes but several times in
> parallel once per active parent.
>
> That’s what I called session. RPL says that a node can run separate
> instances like ship in the night and then describes the operw of one
> instance. Similarly MSF can run multiple sessions one per link as ship in
> the night. pretty much the draft needs to do is say that in introduction
> and then say that the rest of the draft describes one session with one
> parent.
>
> >> And it is possible to run an MSF session at L2 with each of them
> totally independently.
> >
> > What do you mean by "MSF session"? If you have multiple MSF instances
> with different SFIDs or values for the Metadata field, they can be
> associated with different RPL DODAGsm and they will work independently.
> >
>
> The draft describes a session between a parent and a child. They start the
> session, allocate resources in unison and when the session is broken they
> release the resources on each side. This happens within a L2 link. Sessions
> can live independently on different L2 links.
>
>
>
> > On 11/29/2019 9:40 PM, Prof. Diego Dujovne wrote:
> > > Would it be then a neighbour instead of a parent? (Assuming the
> > > neighbour has joined the network)
> >
> > I don't think so.
> >
>
> As Yatch said the draft describes a child handling both sides so the link
> is directional, there’s a master and a slave.
>
> This may become a problem for east west traffic with PDAO. But there’s
> still a direction so it’s doable just need to agree that the parent is
> towards the destination.
>
> All the best,
>
> Pascal
>
>
> > Best,
> > Yatch
> >
> > ___
> > 6tisch mailing list
> > 6tisch@ietf.org
> > https://www.ietf.org/mailman/listinfo/6tisch
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——
___
6tisch mailing list

Re: [6tisch] MSF Shepherd review

[Pascal Thubert (pthubert)]

Hello Yatch



> Le 29 nov. 2019 à 22:48, Yasuyuki Tanaka  a écrit :
> 
> Thank you, Pascal for your comment.
> 
>> On 11/29/2019 9:34 PM, Pascal Thubert (pthubert) wrote:
>> RPL underneath is designed to operate with multiple parents, and for a good 
>> reason.
> 
> I understand that point.
> 
> My point is, rephrasing the word alone couldn't be enough.
> 
>> Bandwidth allocation doesn’t care what traffic that is or it’s direction. It 
>> cares about the amount of traffic that needs to circulate over the hop.
> 
> In general, yes. According to the current text of MSF, the direction is 
> relevant. For a upward neighbor, MSF allocates one negotiated TX cell just 
> after recognizing it. For a downward neighbor, it doesn't.
> 
> On parent switch, the number of negotiated cells is carried over to a new 
> parent. But what if a node has one parents at some point, then it selects an 
> additional parent to handle some portion of traffic? How many negotiated 
> cells should be scheduled with the new (additional) parent? MSF would have no 
> idea.
> 
> To me, this seems a totally new thing to MSF.
> 

Not that new just the logical continuation. 

If a child has 2 parents a and b these are independent links, each with a 
number of cells. If it loses one parent a then the traffic on that link is 
rerouted. The cells on that link have to be moved to other parents which can 
include b. 

The existing cells to the parent b are not touched. If some traffic is rerouted 
to parent b then new cells are allocated there.


> Again, having multiple MSF instances could be a solution, which doesn't need 
> the rephrasing.

For me instance is related to RPL I do not want to run multiple instances of 
RPL with one preferred parent each.

What I want is to run what the draft describes but several times in parallel 
once per active parent.

That’s what I called session. RPL says that a node can run separate instances 
like ship in the night and then describes the operw of one instance. Similarly 
MSF can run multiple sessions one per link as ship in the night. pretty much 
the draft needs to do is say that in introduction and then say that the rest of 
the draft describes one session with one parent. 

>> And it is possible to run an MSF session at L2 with each of them totally 
>> independently.
> 
> What do you mean by "MSF session"? If you have multiple MSF instances with 
> different SFIDs or values for the Metadata field, they can be associated with 
> different RPL DODAGsm and they will work independently.
> 

The draft describes a session between a parent and a child. They start the 
session, allocate resources in unison and when the session is broken they 
release the resources on each side. This happens within a L2 link. Sessions can 
live independently on different L2 links.



> On 11/29/2019 9:40 PM, Prof. Diego Dujovne wrote:
> > Would it be then a neighbour instead of a parent? (Assuming the
> > neighbour has joined the network)
> 
> I don't think so.
> 

As Yatch said the draft describes a child handling both sides so the link is 
directional, there’s a master and a slave. 

This may become a problem for east west traffic with PDAO. But there’s still a 
direction so it’s doable just need to agree that the parent is towards the 
destination.

All the best,

Pascal 


> Best,
> Yatch
> 
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] MSF Shepherd review

[Yasuyuki Tanaka]

Thank you, Pascal for your comment.

On 11/29/2019 9:34 PM, Pascal Thubert (pthubert) wrote:

RPL underneath is designed to operate with multiple parents, and for a good 
reason.


I understand that point.

My point is, rephrasing the word alone couldn't be enough.


Bandwidth allocation doesn’t care what traffic that is or it’s direction. It 
cares about the amount of traffic that needs to circulate over the hop.


In general, yes. According to the current text of MSF, the direction is 
relevant. For a upward neighbor, MSF allocates one negotiated TX cell 
just after recognizing it. For a downward neighbor, it doesn't.


On parent switch, the number of negotiated cells is carried over to a 
new parent. But what if a node has one parents at some point, then it 
selects an additional parent to handle some portion of traffic? How many 
negotiated cells should be scheduled with the new (additional) parent? 
MSF would have no idea.


To me, this seems a totally new thing to MSF.

Again, having multiple MSF instances could be a solution, which doesn't 
need the rephrasing.



And it is possible to run an MSF session at L2 with each of them totally 
independently.


What do you mean by "MSF session"? If you have multiple MSF instances 
with different SFIDs or values for the Metadata field, they can be 
associated with different RPL DODAGsm and they will work independently.


On 11/29/2019 9:40 PM, Prof. Diego Dujovne wrote:
> Would it be then a neighbour instead of a parent? (Assuming the
> neighbour has joined the network)

I don't think so.

Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] MSF Shepherd review

[Pascal Thubert (pthubert)]

Spot on Yatch

MSF manages the bandwidth over one L2 hop based on the packets that L3 places 
on that hop. 

Bandwidth allocation doesn’t care what traffic that is or it’s direction. It 
cares about the amount of traffic that needs to circulate over the hop.

The sense of direction came from the design decision that the child makes the 
request in both directions. That’s your design and that’s fine with me.

 But the child can have multiple L2 Links to different parents. Even if they 
use the same radio it is still as many links that live independent lives. And 
it is possible to run an MSF session at L2 with each of them totally 
independently.

Whether you already tested it is another topic. We do not need to test it 
immediately to progress the draft. But a draft that supports only one parent is 
not acceptable because it degrades the routing functionality too much. RPL 
underneath is designed to operate with multiple parents, and for a good reason. 

Regards,

Pascal

> Le 29 nov. 2019 à 20:41, Yasuyuki Tanaka  a écrit :
> 
> Hi Pascal,
> 
> pascal> My problem is that there’s only one preferred parent, but a
> pascal> node may use several parents for data traffic. This is why we
> pascal> build dodags in the first place.
> pascal>
> pascal> I believe that the node may allocate cells with all of those
> pascal> “selected parents” if it likes. The use of “preferred parent”
> pascal> in that text would prevent this.
> 
> I feel this scenario is outside of the scope of the *minimal*
> scheduling function. If I remember correctly, such a case hasn't been
> discussed nor evaluated with implementations.
> 
> The latest MSF spec may be able to be applied to the multiple parents
> case without any modification, or may not. We don't know because we'd
> not taken it into account. Regarding the multiple DODAGs case, a
> possible solution is having a separate MSF instance per DODAG, using a
> different SFID. Another idea is using the Metadata field to associate
> a 6P transaction with a DODAG.
> 
> In any case, I prefer having "the preferred parent" in the text,
> although "parent" sounds like a L3 term. L2 doesn't maintain
> parent-child relationships.
> 
> My two cents.
> 
> Best,
> Yatch
> 
> 
>> On 11/29/2019 4:23 PM, Pascal Thubert (pthubert) wrote:
>> Please do not call him preferred parent that’s something specific in RPL, 
>> the best parent for forwarding up the dodag.
>> Why not just say “the parent “ explaining that the 6P protocol can be used 
>> in parallel with multiple parents?
>> Regards,
>> Pascal
 Le 29 nov. 2019 à 16:19, Tengfei Chang  a écrit :
>>> 
>>> 
>>> Hi Pascal,
>>> 
>>> For the preferred parent issue:
>>> 
>>> When running MSF, the node is deal with one parent at a time out of the 
>>> parent set, which we called preferred parent.
>>> It doesn't mean there is only one parent for each nodes.
>>> The node may change its preferred parent to other parent, which responded 
>>> in the switching_parent section in MSF.
>>> 
>>> For the sentence:
>>> 
>>>It is recommended to set MAX_NUMCELLS value at least 4x of the
>>>maximum link traffic load of the network with unit of packets per
>>>slotframe.
>>> 
>>> 
>>> The following example helps to understand the meaning:
>>> 
>>>For example, a 2 packets/slotframe traffic load results an average
>>>4 cells scheduled, using the value of double number of scheduled
>>>cells (which is 8) as MAX_NUM_CELLS gives a good resolution on
>>>cell usage calculation.
>>> 
>>> Any recommendation on the rephrasing?
>>> 
>>> Tengfei
>>> 
>>> 
>>> 
 On Wed, Nov 27, 2019 at 10:07 PM Pascal Thubert (pthubert) 
 mailto:pthub...@cisco.com>> wrote:
>>> 
>>>Hello Tengfei
>>> 
>>> 
>>>Please see below
>>> 
Le 27 nov. 2019 à 21:44, Tengfei Chang >>>> a écrit :
 

Thanks a lot for the reviewing, I responded inline:
 
On Mon, Nov 25, 2019 at 6:42 PM Pascal Thubert (pthubert)
mailto:pthub...@cisco.com>> wrote:
 
Dear all
 
__ __
 
Please find some comments below: 
 
__ __
 
__ __
 
__ __
 
__ __
 
Please migrate to XML2RFC v3. This will save time in the future.
 
 
TC: got it! Will used in version 9.
>>> 
>>>:)
 

 
__ __
 
__ __
 
__ __
 

 
   However, an implementor MAY implement MSF without
implementing
 
   Minimal 6TiSCH Configuration. 
 
__ __
 
__ __
 
This is not helpful without explanations. What is the
tradeoff? How does the  network operates in that case?
 
 
TC: Yes, the sentence is misleading. What we try to say is MSF
can work with other specifications 

Re: [6tisch] MSF Shepherd review

[Yasuyuki Tanaka]

Hi Pascal,

pascal> My problem is that there’s only one preferred parent, but a
pascal> node may use several parents for data traffic. This is why we
pascal> build dodags in the first place.
pascal>
pascal> I believe that the node may allocate cells with all of those
pascal> “selected parents” if it likes. The use of “preferred parent”
pascal> in that text would prevent this.

I feel this scenario is outside of the scope of the *minimal*
scheduling function. If I remember correctly, such a case hasn't been
discussed nor evaluated with implementations.

The latest MSF spec may be able to be applied to the multiple parents
case without any modification, or may not. We don't know because we'd
not taken it into account. Regarding the multiple DODAGs case, a
possible solution is having a separate MSF instance per DODAG, using a
different SFID. Another idea is using the Metadata field to associate
a 6P transaction with a DODAG.

In any case, I prefer having "the preferred parent" in the text,
although "parent" sounds like a L3 term. L2 doesn't maintain
parent-child relationships.

My two cents.

Best,
Yatch


On 11/29/2019 4:23 PM, Pascal Thubert (pthubert) wrote:
Please do not call him preferred parent that’s something specific in 
RPL, the best parent for forwarding up the dodag.


Why not just say “the parent “ explaining that the 6P protocol can be 
used in parallel with multiple parents?



Regards,

Pascal


Le 29 nov. 2019 à 16:19, Tengfei Chang  a écrit :


Hi Pascal,

For the preferred parent issue:

When running MSF, the node is deal with one parent at a time out of 
the parent set, which we called preferred parent.

It doesn't mean there is only one parent for each nodes.
The node may change its preferred parent to other parent, which 
responded in the switching_parent section in MSF.


For the sentence:

It is recommended to set MAX_NUMCELLS value at least 4x of the
maximum link traffic load of the network with unit of packets per
slotframe.


The following example helps to understand the meaning:

For example, a 2 packets/slotframe traffic load results an average
4 cells scheduled, using the value of double number of scheduled
cells (which is 8) as MAX_NUM_CELLS gives a good resolution on
cell usage calculation.

Any recommendation on the rephrasing?

Tengfei



On Wed, Nov 27, 2019 at 10:07 PM Pascal Thubert (pthubert) 
mailto:pthub...@cisco.com>> wrote:


Hello Tengfei


Please see below


Le 27 nov. 2019 à 21:44, Tengfei Chang mailto:tengfei.ch...@gmail.com>> a écrit :


Thanks a lot for the reviewing, I responded inline:

On Mon, Nov 25, 2019 at 6:42 PM Pascal Thubert (pthubert)
mailto:pthub...@cisco.com>> wrote:

Dear all

__ __

Please find some comments below: 

__ __

__ __

__ __

__ __

Please migrate to XML2RFC v3. This will save time in the future.


TC: got it! Will used in version 9.


:)




__ __

__ __

__ __



   However, an implementor MAY implement MSF without
implementing

   Minimal 6TiSCH Configuration. 

__ __

__ __

This is not helpful without explanations. What is the
tradeoff? How does the  network operates in that case?


TC: Yes, the sentence is misleading. What we try to say is MSF
can work with other specifications protocols, rather then minimal
6TiSCH configuration, as long as the protocols gives a way to
communicate the EB and DIO among the network.


Those words in the draft will make me a happy shepherd...




__ __

__ __

__ __

__ __

For example, a Trickle Timer defined in

[RFC6550  ] MAY be applied on 
DIOs. However, this behavior is

implementation-specific which is out of the scope of MSF.

__ __

__ __

This is not for this spec to define. RPL already mandates
trickle. Suggestion:

__ __

For example, the Trickle operation defined in [RFC6206]

is applied on DIO Messages [RFC6550  
]. This behavior is

out of the scope of MSF.

__

TC: agreed!

__

__ __

__ __

__ __

__ __

MSF RECOMMENDS the use of 3 slotframes. 

__ __

Discussion on slotframes and cells comes without an
introduction to TSCH. 

I’d suggest you add a few words on RFC 7554 appendix A and
6TiSCH architecture section 4.3.5. to introduce those
concepts.

They should probably be normative references.


TC: I added the following text at beginning of section 2:
            In a TSCH network, time is sliced up into time slots.
            The time slots are 

Re: [6tisch] MSF Shepherd review

[Pascal Thubert (pthubert)]

Well my text was a proposal for rephrasing :)


Regards,

Pascal

Le 29 nov. 2019 à 16:19, Tengfei Chang  a écrit :


Hi Pascal,

For the preferred parent issue:

When running MSF, the node is deal with one parent at a time out of the parent 
set, which we called preferred parent.
It doesn't mean there is only one parent for each nodes.
The node may change its preferred parent to other parent, which responded in 
the switching_parent section in MSF.

For the sentence:

It is recommended to set MAX_NUMCELLS value at least 4x of the maximum link 
traffic load of the network with unit of packets per slotframe.

The following example helps to understand the meaning:

For example, a 2 packets/slotframe traffic load results an average 4 cells 
scheduled, using the value of double number of scheduled cells (which is 8) as 
MAX_NUM_CELLS gives a good resolution on cell usage calculation.

Any recommendation on the rephrasing?

Tengfei



On Wed, Nov 27, 2019 at 10:07 PM Pascal Thubert (pthubert) 
mailto:pthub...@cisco.com>> wrote:
Hello Tengfei


Please see below

Le 27 nov. 2019 à 21:44, Tengfei Chang 
mailto:tengfei.ch...@gmail.com>> a écrit :


Thanks a lot for the reviewing, I responded inline:

On Mon, Nov 25, 2019 at 6:42 PM Pascal Thubert (pthubert) 
mailto:pthub...@cisco.com>> wrote:
Dear all

Please find some comments below:




Please migrate to XML2RFC v3. This will save time in the future.

TC: got it! Will used in version 9.

:)



   However, an implementor MAY implement MSF without implementing

   Minimal 6TiSCH Configuration.


This is not helpful without explanations. What is the tradeoff? How does the  
network operates in that case?

TC: Yes, the sentence is misleading. What we try to say is MSF can work with 
other specifications protocols, rather then minimal 6TiSCH configuration, as 
long as the protocols gives a way to communicate the EB and DIO among the 
network.


Those words in the draft will make me a happy shepherd...





For example, a Trickle Timer defined in

[RFC6550] MAY be applied on DIOs. However, 
this behavior is

implementation-specific which is out of the scope of MSF.



This is not for this spec to define. RPL already mandates trickle. Suggestion:


For example, the Trickle operation defined in [RFC6206]

is applied on DIO Messages [RFC6550]. This 
behavior is

out of the scope of MSF.



TC: agreed!





MSF RECOMMENDS the use of 3 slotframes.

Discussion on slotframes and cells comes without an introduction to TSCH.
I’d suggest you add a few words on RFC 7554 appendix A and 6TiSCH architecture 
section 4.3.5. to introduce those concepts.
They should probably be normative references.

TC: I added the following text at beginning of section 2:
In a TSCH network, time is sliced up into time slots.
The time slots are grouped as one of more slotframes which repeat 
over time.
The TSCH schedule instructs a node what to do at each time slots, 
such as transmit, receive or sleep .
In case of a slot to transmit or receive, a channel is assigned to 
the time slot.
The tuple (slot, channel) is indicated as a cell of TSCH schedule.
MSF is one of the policies defining how to manage the TSCH schedule.

Excellent




Section 4 has numerous SHOULD. Trouble is, when SHOULD is used, the author 
SHOULD explain the alternate, what if the SHOULD is not followed.
Sometimes it’s quite obvious, like when using random in 4.2. But SHOULD use 
minimal is less obvious. Please consider adding text after the SHOULDs.

TC: agreed!  I have resolved this SHOULD issues in a new version. either the 
unnecessaries are removed or alternative explanation is added

I’ll review once you published




   field it contains, the presence and contents of the IE defined in

   
[I-D.richardson-6tisch-join-enhanced-beacon],
 or the key used to

   authenticate it.

The reference is now draft-ietf.. I agree that it should be normative; no 
worries the draft is already submitted for publication.
More important: Please move the reference to 6tisch-dtsecurity-zerotouch-join 
to informational. This is a DOWNREF today and your draft may be stuck in 
MISSREF in the future.

TC: I have updated  richardson-6tisch-join-enhanced-beacon to  
ietf-6tisch-enrollment-enhanced-beacon.
I didn't get it how "move the reference to 6tisch-dtsecurity-zerotouch-join to 
informational" is done in the draft?


Sorry I was unclear. The draft is currently listed as a normative reference. 
This means that MSF will be held forever in miss ref at the RFC editor. Please 
move the link to the reference in the informational references section.




   After selected a preferred parent, the joined node MUST generate a 6P

Grammar: “After selecting” or “once it has selected” sound better.

TC: the latter 

Re: [6tisch] MSF Shepherd review

[Tengfei Chang]

Hi Pascal,

For the preferred parent issue:

When running MSF, the node is deal with one parent at a time out of the
parent set, which we called preferred parent.
It doesn't mean there is only one parent for each nodes.
The node may change its preferred parent to other parent, which responded
in the switching_parent section in MSF.

For the sentence:

It is recommended to set MAX_NUMCELLS value at least 4x of the maximum link
traffic load of the network with unit of packets per slotframe.


The following example helps to understand the meaning:

For example, a 2 packets/slotframe traffic load results an average 4 cells
scheduled, using the value of double number of scheduled cells (which is 8)
as MAX_NUM_CELLS gives a good resolution on cell usage calculation.

Any recommendation on the rephrasing?

Tengfei



On Wed, Nov 27, 2019 at 10:07 PM Pascal Thubert (pthubert) <
pthub...@cisco.com> wrote:

> Hello Tengfei
>
>
> Please see below
>
> Le 27 nov. 2019 à 21:44, Tengfei Chang  a écrit :
>
> 
> Thanks a lot for the reviewing, I responded inline:
>
> On Mon, Nov 25, 2019 at 6:42 PM Pascal Thubert (pthubert) <
> pthub...@cisco.com> wrote:
>
>> Dear all
>>
>>
>>
>> Please find some comments below:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Please migrate to XML2RFC v3. This will save time in the future.
>>
>
> TC: got it! Will used in version 9.
>
>
> :)
>
>
>>
>>
>>
>>
>>
>>However, an implementor MAY implement MSF without implementing
>>
>>Minimal 6TiSCH Configuration.
>>
>>
>>
>>
>>
>> This is not helpful without explanations. What is the tradeoff? How does
>> the  network operates in that case?
>>
>
> TC: Yes, the sentence is misleading. What we try to say is MSF can work
> with other specifications protocols, rather then minimal 6TiSCH
> configuration, as long as the protocols gives a way to communicate the EB
> and DIO among the network.
>
>
>
> Those words in the draft will make me a happy shepherd...
>
>
>>
>>
>>
>>
>>
>>
>>
>> For example, a Trickle Timer defined in
>>
>> [RFC6550 ] MAY be applied on DIOs. 
>> However, this behavior is
>>
>> implementation-specific which is out of the scope of MSF.
>>
>>
>>
>>
>>
>> This is not for this spec to define. RPL already mandates trickle.
>> Suggestion:
>>
>>
>>
>> For example, the Trickle operation defined in [RFC6206]
>>
>> is applied on DIO Messages [RFC6550 ]. 
>> This behavior is
>>
>> out of the scope of MSF.
>>
>>
>>
>> TC: agreed!
>
>>
>>
>>
>>
>>
>>
>>
>>
>> MSF RECOMMENDS the use of 3 slotframes.
>>
>>
>>
>> Discussion on slotframes and cells comes without an introduction to TSCH..
>>
>> I’d suggest you add a few words on RFC 7554 appendix A and 6TiSCH
>> architecture section 4.3.5. to introduce those concepts.
>>
>> They should probably be normative references.
>>
>
> TC: I added the following text at beginning of section 2:
> In a TSCH network, time is sliced up into time slots.
> The time slots are grouped as one of more slotframes which
> repeat over time.
> The TSCH schedule instructs a node what to do at each time
> slots, such as transmit, receive or sleep .
> In case of a slot to transmit or receive, a channel is
> assigned to the time slot.
> The tuple (slot, channel) is indicated as a cell of TSCH
> schedule.
> MSF is one of the policies defining how to manage the TSCH
> schedule.
>
>
> Excellent
>
>
>>
>>
>>
>>
>>
>>
>>
>> Section 4 has numerous SHOULD. Trouble is, when SHOULD is used, the
>> author SHOULD explain the alternate, what if the SHOULD is not followed.
>>
>> Sometimes it’s quite obvious, like when using random in 4.2. But SHOULD
>> use minimal is less obvious. Please consider adding text after the SHOULDs.
>>
>
> TC: agreed!  I have resolved this SHOULD issues in a new version. either
> the unnecessaries are removed or alternative explanation is added
>
>
> I’ll review once you published
>
>
>>
>>
>>
>>
>>
>>field it contains, the presence and contents of the IE defined in
>>
>>[I-D.richardson-6tisch-join-enhanced-beacon 
>> ],
>>  or the key used to
>>
>>authenticate it.
>>
>>
>>
>> The reference is now draft-ietf.. I agree that it should be normative; no
>> worries the draft is already submitted for publication.
>>
>> More important: Please move the reference to
>> 6tisch-dtsecurity-zerotouch-join to informational. This is a DOWNREF today
>> and your draft may be stuck in MISSREF in the future.
>>
>
> TC: I have updated  *richardson-6tisch-join-enhanced-beacon* to
> * ietf-6tisch-enrollment-enhanced-beacon.*
> I didn't get it how "*move the reference to
> 6tisch-dtsecurity-zerotouch-join to informational*" is done in the draft?
>
>
> Sorry I was unclear. The draft is currently listed as a normative
> reference. This means that MSF will be held forever in miss ref at the 

Re: [6tisch] MSF Shepherd review

[Pascal Thubert (pthubert)]

Hello Tengfei


Please see below

Le 27 nov. 2019 à 21:44, Tengfei Chang  a écrit :


Thanks a lot for the reviewing, I responded inline:

On Mon, Nov 25, 2019 at 6:42 PM Pascal Thubert (pthubert) 
mailto:pthub...@cisco.com>> wrote:
Dear all

Please find some comments below:




Please migrate to XML2RFC v3. This will save time in the future.

TC: got it! Will used in version 9.

:)



   However, an implementor MAY implement MSF without implementing

   Minimal 6TiSCH Configuration.


This is not helpful without explanations. What is the tradeoff? How does the  
network operates in that case?

TC: Yes, the sentence is misleading. What we try to say is MSF can work with 
other specifications protocols, rather then minimal 6TiSCH configuration, as 
long as the protocols gives a way to communicate the EB and DIO among the 
network.


Those words in the draft will make me a happy shepherd...





For example, a Trickle Timer defined in

[RFC6550] MAY be applied on DIOs. However, 
this behavior is

implementation-specific which is out of the scope of MSF.



This is not for this spec to define. RPL already mandates trickle. Suggestion:


For example, the Trickle operation defined in [RFC6206]

is applied on DIO Messages [RFC6550]. This 
behavior is

out of the scope of MSF.



TC: agreed!





MSF RECOMMENDS the use of 3 slotframes.

Discussion on slotframes and cells comes without an introduction to TSCH.
I’d suggest you add a few words on RFC 7554 appendix A and 6TiSCH architecture 
section 4.3.5. to introduce those concepts.
They should probably be normative references.

TC: I added the following text at beginning of section 2:
In a TSCH network, time is sliced up into time slots.
The time slots are grouped as one of more slotframes which repeat 
over time.
The TSCH schedule instructs a node what to do at each time slots, 
such as transmit, receive or sleep .
In case of a slot to transmit or receive, a channel is assigned to 
the time slot.
The tuple (slot, channel) is indicated as a cell of TSCH schedule.
MSF is one of the policies defining how to manage the TSCH schedule.

Excellent




Section 4 has numerous SHOULD. Trouble is, when SHOULD is used, the author 
SHOULD explain the alternate, what if the SHOULD is not followed.
Sometimes it’s quite obvious, like when using random in 4.2. But SHOULD use 
minimal is less obvious. Please consider adding text after the SHOULDs.

TC: agreed!  I have resolved this SHOULD issues in a new version. either the 
unnecessaries are removed or alternative explanation is added

I’ll review once you published




   field it contains, the presence and contents of the IE defined in

   
[I-D.richardson-6tisch-join-enhanced-beacon],
 or the key used to

   authenticate it.

The reference is now draft-ietf.. I agree that it should be normative; no 
worries the draft is already submitted for publication.
More important: Please move the reference to 6tisch-dtsecurity-zerotouch-join 
to informational. This is a DOWNREF today and your draft may be stuck in 
MISSREF in the future.

TC: I have updated  richardson-6tisch-join-enhanced-beacon to  
ietf-6tisch-enrollment-enhanced-beacon.
I didn't get it how "move the reference to 6tisch-dtsecurity-zerotouch-join to 
informational" is done in the draft?


Sorry I was unclear. The draft is currently listed as a normative reference. 
This means that MSF will be held forever in miss ref at the RFC editor. Please 
move the link to the reference in the informational references section.




   After selected a preferred parent, the joined node MUST generate a 6P

Grammar: “After selecting” or “once it has selected” sound better.

TC: the latter sounds better! Thanks!



Section Section 
8

The  already generates the word “section”. If you write it too, it 
becomes duplicated as above.

TC: agreed!




For a node, this translates into

   monitoring the current usage of the cells it has to its preferred

   parent:


This is disturbing. MSF should not be used only with preferred parents. The 
whole game of doing a DODAG is to have and possibly use multiple parents.
A node can for instance send a NSM DAO with multiple transit options to the 
root. Also, it could be good to clarify that the child manages both directions.
Proposal:


For a node, this translates into

   monitoring the current usage of the cells it has to the parents it uses

   at this point of time for sending and receiving traffic:

Later there a numerous references to “preferred parent” => I’d suggest you use 
just “selected parent” or “active parent” or  something in that vein.
TC: I think "preferred parent" is same with "selected parent".  it indicates 
one preferred 

Re: [6tisch] MSF Shepherd review

[Tengfei Chang]

Thanks a lot for the reviewing, I responded inline:

On Mon, Nov 25, 2019 at 6:42 PM Pascal Thubert (pthubert) <
pthub...@cisco.com> wrote:

> Dear all
>
>
>
> Please find some comments below:
>
>
>
>
>
>
>
>
>
> Please migrate to XML2RFC v3. This will save time in the future.
>

TC: got it! Will used in version 9.

>
>
>
>
>
>
>However, an implementor MAY implement MSF without implementing
>
>Minimal 6TiSCH Configuration.
>
>
>
>
>
> This is not helpful without explanations. What is the tradeoff? How does
> the  network operates in that case?
>

TC: Yes, the sentence is misleading. What we try to say is MSF can work
with other specifications protocols, rather then minimal 6TiSCH
configuration, as long as the protocols gives a way to communicate the EB
and DIO among the network.


>
>
>
>
>
>
>
>
> For example, a Trickle Timer defined in
>
> [RFC6550 ] MAY be applied on DIOs. 
> However, this behavior is
>
> implementation-specific which is out of the scope of MSF.
>
>
>
>
>
> This is not for this spec to define. RPL already mandates trickle.
> Suggestion:
>
>
>
> For example, the Trickle operation defined in [RFC6206]
>
> is applied on DIO Messages [RFC6550 ]. 
> This behavior is
>
> out of the scope of MSF.
>
>
>
> TC: agreed!

>
>
>
>
>
>
>
>
> MSF RECOMMENDS the use of 3 slotframes.
>
>
>
> Discussion on slotframes and cells comes without an introduction to TSCH.
>
> I’d suggest you add a few words on RFC 7554 appendix A and 6TiSCH
> architecture section 4.3.5. to introduce those concepts.
>
> They should probably be normative references.
>

TC: I added the following text at beginning of section 2:
In a TSCH network, time is sliced up into time slots.
The time slots are grouped as one of more slotframes which
repeat over time.
The TSCH schedule instructs a node what to do at each time
slots, such as transmit, receive or sleep .
In case of a slot to transmit or receive, a channel is assigned
to the time slot.
The tuple (slot, channel) is indicated as a cell of TSCH
schedule.
MSF is one of the policies defining how to manage the TSCH
schedule.

>
>
>
>
>
>
>
>
> Section 4 has numerous SHOULD. Trouble is, when SHOULD is used, the author
> SHOULD explain the alternate, what if the SHOULD is not followed.
>
> Sometimes it’s quite obvious, like when using random in 4.2. But SHOULD
> use minimal is less obvious. Please consider adding text after the SHOULDs.
>

TC: agreed!  I have resolved this SHOULD issues in a new version. either
the unnecessaries are removed or alternative explanation is added

>
>
>
>
>
>
>field it contains, the presence and contents of the IE defined in
>
>[I-D.richardson-6tisch-join-enhanced-beacon 
> ],
>  or the key used to
>
>authenticate it.
>
>
>
> The reference is now draft-ietf.. I agree that it should be normative; no
> worries the draft is already submitted for publication.
>
> More important: Please move the reference to
> 6tisch-dtsecurity-zerotouch-join to informational. This is a DOWNREF today
> and your draft may be stuck in MISSREF in the future.
>

TC: I have updated  *richardson-6tisch-join-enhanced-beacon* to
* ietf-6tisch-enrollment-enhanced-beacon.*
I didn't get it how "*move the reference to
6tisch-dtsecurity-zerotouch-join to informational*" is done in the draft?


>
>
>
>
>
>After selected a preferred parent, the joined node MUST generate a 6P
>
>
>
> Grammar: “After selecting” or “once it has selected” sound better.
>
>
>
TC: the latter sounds better! Thanks!

>
>
>
>
> Section Section 8 
> 
>
>
>
> The  already generates the word “section”.. If you write it too, it
> becomes duplicated as above.
>

TC: agreed!

>
>
>
>
>
>
> For a node, this translates into
>
>monitoring the current usage of the cells it has to its preferred
>
>parent:
>
>
>
> This is disturbing. MSF should not be used only with preferred parents.
> The whole game of doing a DODAG is to have and possibly use multiple
> parents.
>
> A node can for instance send a NSM DAO with multiple transit options to
> the root. Also, it could be good to clarify that the child manages both
> directions.
>
> Proposal:
>
>
>
> For a node, this translates into
>
>monitoring the current usage of the cells it has to the parents it uses
>
>at this point of time for sending and receiving traffic:
>
>
>
> Later there a numerous references to “preferred parent” => I’d suggest you
> use just “selected parent” or “active parent” or  something in that vein.
>
TC: I think "preferred parent" is same with "selected parent".  it
indicates one preferred parent out of multiple. Isn't it right?

>
>

>
>
>
> Cell installed at initial
>
>
>
> Not sure this is correct. Maybe “at init