Would it be then a neighbour instead of a parent? (Assuming the neighbour
has joined the network)
Regards,
Diego
El vie., 29 de noviembre de 2019 17:34, Pascal Thubert (pthubert) <
[email protected]> escribió:
> 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 <[email protected]> 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 <[email protected]> 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) <
> [email protected] <mailto:[email protected]>> wrote:
> >>>
> >>> Hello Tengfei
> >>>
> >>>
> >>> Please see below
> >>>
> >>>> Le 27 nov. 2019 à 21:44, Tengfei Chang <[email protected]
> >>>> <mailto:[email protected]>> a écrit :
> >>>>
> >>>>
> >>>> Thanks a lot for the reviewing, I responded inline:
> >>>>
> >>>> On Mon, Nov 25, 2019 at 6:42 PM Pascal Thubert (pthubert)
> >>>> <[email protected] <mailto:[email protected]>> 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 <https://tools.ietf.org/html/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 <
> https://tools.ietf.org/html/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 <xref
> >>>> target="RFC7554"/>.
> >>>> 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 <
> https://tools.ietf.org/html/draft-ietf-6tisch-msf-08#ref-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 <
> https://tools.ietf.org/html/draft-ietf-6tisch-msf-08#section-8>____
> >>>>
> >>>> __ __
> >>>>
> >>>> The <xref …> 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?
> >>>
> >>> My problem is that there’s only one preferred parent, but a node
> >>> may use several parents for data traffic. This is why we build
> >>> dodags in the first place.
> >>>
> >>> I believe that the node may allocate cells with all of those
> >>> “selected parents” if it likes. The use of “preferred parent” in
> >>> that text would prevent this.
> >>>
> >>> Please make sure your text does not limit to one parent...
> >>>>
> >>>> ____
> >>>>
> >>>> __ __
> >>>>
> >>>> __ __
> >>>>
> >>>> Cell installed at initial____
> >>>>
> >>>> __ __
> >>>>
> >>>> Not sure this is correct. Maybe “at init time”
> >>>>
> >>>>
> >>>> TC: Applied!
> >>>>
> >>>> ____
> >>>>
> >>>> __ __
> >>>>
> >>>> __ __
> >>>>
> >>>> __ __
> >>>>
> >>>> __ __
> >>>>
> >>>> It is recommended to set MAX_NUMCELLS value at____
> >>>>
> >>>> least 4 times than the maximum link traffic load of the
> >>>> network in____
> >>>>
> >>>> packets per slotframe.____
> >>>>
> >>>> __ __
> >>>>
> >>>> __ __
> >>>>
> >>>> This does not parse. Can you please rephrase?
> >>>>
> >>>>
> >>>> TC: it's rephrased as "*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*."
> >>>
> >>> I still have a hard time
> >>>
> >>> Do you mean “4 times the maximum number of used cells in a slot
> >>> frame in recent history” ?
> >>>>
> >>>> ____
> >>>>
> >>>> __ __
> >>>>
> >>>> __ __
> >>>>
> >>>> __ __
> >>>>
> >>>> __ __
> >>>>
> >>>> Section 8 does not try to avoid collisions with autocells.
> >>>> But it’s easy to compute the slot offset of autocells for
> >>>> self and parent and avoids those. Why not do that?
> >>>>
> >>>>
> >>>> TC: agreed! Will apply in the next version.
> >>>>
> >>>> ____
> >>>>
> >>>> __ __
> >>>>
> >>>> __ __
> >>>>
> >>>> __ __
> >>>>
> >>>> Section 16 will require more attention, either now or during
> >>>> secdir review, probably both. You should start now. Think,
> >>>> say, what if an attacker claims many cells to all its
> >>>> neighbors? Can it attack someone’s autocells to block him?
> >>>>
> >>>>
> >>>> TC: That's a good question! It may have a chance to do so. We
> >>>> need discuss internally on this section.
> >>>> Thanks for belling ahead!
> >>>
> >>> Speaking from experience with secdir. Better be prepared they will
> >>> be coming for you ; )
> >>>
> >>> Take care
> >>>
> >>> Pascal
> >>>>
> >>>> ____
> >>>>
> >>>> __ __
> >>>>
> >>>> __ __
> >>>>
> >>>> __ __
> >>>>
> >>>> Voila!____
> >>>>
> >>>> __ __
> >>>>
> >>>> Pascal as shepherd.____
> >>>>
> >>>> __ __
> >>>>
> >>>> __ __
> >>>>
> >>>> __ __
> >>>>
> >>>> __ __
> >>>>
> >>>> __ __
> >>>>
> >>>> __ __
> >>>>
> >>>> _______________________________________________
> >>>> 6tisch mailing list
> >>>> [email protected] <mailto:[email protected]>
> >>>> https://www.ietf.org/mailman/listinfo/6tisch
> >>>>
> >>>>
> >>>>
> >>>> -- ——————————————————————————————————————
> >>>>
> >>>> Dr. Tengfei, Chang
> >>>> Postdoctoral Research Engineer, Inria
> >>>>
> >>>> www.tchang.org/ <http://www.tchang.org/>
> >>>> ——————————————————————————————————————
> >>>
> >>>
> >>>
> >>> --
> >>> ——————————————————————————————————————
> >>>
> >>> Dr. Tengfei, Chang
> >>> Postdoctoral Research Engineer, Inria
> >>>
> >>> www.tchang.org/ <http://www.tchang.org/>
> >>> ——————————————————————————————————————
> >> _______________________________________________
> >> 6tisch mailing list
> >> [email protected]
> >> https://www.ietf.org/mailman/listinfo/6tisch
> _______________________________________________
> 6tisch mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/6tisch
>
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
