Re: [6tisch] draft-ietf-6tisch-msf-06 is published

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.chang@gmail.com>
> À: "Thomas Watteyne" <thomas.watteyne@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.watteyne@inria.fr | 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

>> [ http://www.thomaswatteyne.com/ | www.thomaswatteyne.com ]
>> ________________________________________

>>> De: "tengfei chang" < [ mailto:tengfei.chang@gmail.com | tengfei.chang@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