I woud send back either an RC_ERR_BUSY or RC_ERR, definitely NOT RC_SUCCESSS
________________________________________ Thomas Watteyne, PhD Sr Research Scientist & Innovator, Inria Sr Networking Design Eng, Analog Devices Founder & Advisor, Wattson Elements/Falco Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com ________________________________________ > De: "tengfei chang" <tengfei.ch...@gmail.com> > À: "Thomas Watteyne" <thomas.watte...@inria.fr> > Cc: "6tisch" <6tisch@ietf.org> > Envoyé: Mercredi 14 Août 2019 08:46:25 > Objet: Re: [6tisch] draft-ietf-6tisch-msf-06 is published > Hi Thomas, > Yes, you understood correctly. > There are two related part in RFC8480 mentioned this case: > Upon receiving the request, node B checks to see if the length of the > Candidate CellList is greater than or equal to NumCells. Node B's SF > verifies that all the cells in the Relocation CellList are scheduled > with node A and are associated with the options specified in the > CellOptions field. If either check fails, node B MUST send a 6P > Response to node A with return code RC_ERR_CELLLIST. If both checks > pass, node B's SF verifies which of the cells in the Candidate > CellList it can install in its schedule. How that selection is done > is specified in the SF and is out of scope for this document. That > verification for the Candidate CellList can succeed (NumCells cells > from the Candidate CellList can be used), fail (none of the cells > from the Candidate CellList can be used), or partially succeed (fewer > than NumCells cells from the Candidate CellList can be used). In all > cases, node B MUST send a 6P Response that includes a return code set > to RC_SUCCESS and that specifies the list of cells that will be > rescheduled following the CellOptions field. That list can contain > NumCells elements (succeed), 0 elements (fail), or between 0 and > NumCells elements (partially succeed). If N < NumCells cells appear > in the CellList, this means that the first N cells in the Relocation > CellList have been relocated and the remainder have not. > Here it clarified the return code for this case MUST be RC_SUCCESS. > I would say it may implies that the case should be the option 1 I mentioned > above. > Another part in concurrent 6P transaction section, it says: > If a > node does not have enough resources to handle concurrent 6P > Transactions from different neighbors, it MUST reply with a 6P > Response with return code RC_ERR_BUSY (as per Figure 38 in [ > https://tools.ietf.org/html/rfc8480#section-6.2.4 | Section 6.2.4 ] ). > I says > enough resources to handle concurrent 6P Transactions, > but the option 2 I mentioned doesn't need to be concurrent 6P transaction.. > Also the RC_BUSY doesn't sound the right return code name for this case. > So does the RC_BUSY is the return code for option 2 I mentioned? > Tengfei > On Wed, Aug 14, 2019 at 4:45 PM Thomas Watteyne < [ > mailto:thomas.watte...@inria.fr | thomas.watte...@inria.fr ] > wrote: >> Tengfei, >> Trying to understand you point about " handle Sixtop ADD Response with return >> code SUCCESS but 0 cells in cellList " >> If the response code is SUCCESS, IMO that means option 1. if option 2 is >> happening (I assume you mean "there is no memory for allocating more >> cells"), I >> would expect another return code, no? >> THomas >> ________________________________________ >> Thomas Watteyne, PhD >> Sr Research Scientist & Innovator, Inria >> Sr Networking Design Eng, Analog Devices >> Founder & Advisor, Wattson Elements/Falco >> Founder & co-lead, UC Berkeley OpenWSN >> Co-chair, IETF 6TiSCH >> [ http://www.thomaswatteyne.com/ | www.thomaswatteyne.com ] >> ________________________________________ >>> De: "tengfei chang" < [ mailto:tengfei.ch...@gmail.com | >>> tengfei.ch...@gmail.com >>> ] > >>> À: "6tisch" < [ mailto:6tisch@ietf.org | 6tisch@ietf.org ] > >>> Envoyé: Lundi 12 Août 2019 08:52:37 >>> Objet: [6tisch] draft-ietf-6tisch-msf-06 is published >>> Dear all, >>> The draft-ietf-6tisch-msf-06 is just published, it mainly resolved what we >>> discussed during the IETF meeting. >>> - add rules for celllist >>> - update the downstream cell adaptation strategy >>> Right now, there is one issue remained to be resolved and I am not sure >>> what is >>> the right solution. So I need suggestions and feedback from you: >>> - handle Sixtop ADD Response with return code SUCCESS but 0 cells in >>> cellList >>> There are two possible reason for this situation >>> 1. the proposed celllist doesn't meet the requirement from neighbor side >>> 2. there is schedule memory for adding more cells. >>> For the 1st reason, the node may try to send another 6P request later. >>> For the 2nd reason, the node may switch to another parent but it's layer >>> violated. >>> Any solutions for this case? >>> Tengfei >>> -- >>> Chang Tengfei, >>> Postdoctoral Research Engineer , Inria >>> _______________________________________________ >>> 6tisch mailing list >>> [ mailto:6tisch@ietf.org | 6tisch@ietf.org ] >>> [ https://www.ietf.org/mailman/listinfo/6tisch | >>> https://www.ietf.org/mailman/listinfo/6tisch ] > -- > Chang Tengfei, > Postdoctoral Research Engineer , Inria
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
