Re: [6tisch] MSF Shepherd review

[Yasuyuki Tanaka <[e-mail]>]

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