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
   Section 6.2.4 <https://tools.ietf.org/html/rfc8480#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 <thomas.watteyne@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
>
> www.thomaswatteyne.com
> ________________________________________
>
> ------------------------------
>
> *De: *"tengfei chang" <tengfei.chang@gmail.com>
> *À: *"6tisch" <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
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria