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
