Subject: Re: [6tisch] 6top Data Model vs 6top API

From: Jonathan Simon <[email-masked]>
Date: Tue, 3 Dec 2013 11:09:10 -0800

While I think 3 is the cleanest, I think there is an advantage in 1 that it ensures that you've clearly articulated all the necessary 15.4 hooks, but as long as the RFC calls out which L2 PIBs are set to what, I think it will work.
-- 
Jonathan Simon, Ph. D
Director of Systems Engineering
Linear Technology, Dust Networks product group
30695 Huntwood Ave
Hayward, CA 94544-7021
(510) 400-2936
(510) 489-3799 FAX
[email-masked]

**LINEAR TECHNOLOGY CORPORATION** 
*****Internet Email Confidentiality Notice***** 
 This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail, or by telephone at (510) 400-2936, and destroy the original transmission and its attachments without reading or saving in any manner. Thank you. 

On Nov 22, 2013, at 7:24 AM, Qin Wang wrote:

> Xavi,
> 
> There is one thing I'm not very sure. In our discussion, we often use "management layer" or "management entity" as something to process the management message and interact with 6top, or 15.4 as you mentioned above. But, where is the "management layer" or "management entity" in the protocol stack? Is it in the 6top scope, or out of 6top scope?
> 
> Thanks
> Qin
> 
> 
> 
> On Fri, Nov 22, 2013 at 11:02 AM, Xavier Vilajosana Guillen <[email-masked]> wrote:
> Hi Qin,
> 
> I see more 3) the RFC defines the general YANG Model and how to access 6top API and how to map it to 15.4e TSCH related attributes. Other attributes from 15.4 should be accessed by the management layer directly without interfering with 6top (unless they are related to TSCH).
> 
> do you see anything strange on that approach?
> X
> 
> 
> 
> On Thu, Nov 21, 2013 at 4:00 PM, Qin Wang <[email-masked]> wrote:
> Thomas, 
> 
> Your understanding on 1) is exactly what I mean. 
> 
> I agree with Xavi that Data Model should include 6top MIB and all of attributes in L2 PIB defined in 15.4 and 15.4e TSCH, and 6top API only CRUD those related to TSCH and 6top MIB. 
> 
> In another word, it means the data expressed in YANG will include all of the data in 6top MIB and in L2 PIB. Then, the problem is what should be the RFC in YANG model. I guess there are several approaches.
> (1) RFC includes 6top API and SET/GET of 15.4. And the management entity maps the RFC to 6top API and SET/GET of 15.4 directly.
> (2) RFC are general CRUD regardless the operated data belonging to 6topMIB, 15.4ePIB, or 15.4PIB. And the management entity is responsible to translate the CRUD to 6top API or 15.4SET/GET accordingly.
> (3) RFC are general SET/GET, and CREATE/READ/UPDATE/DELETE is the value of a variable. And the management entity is responsible to translate to 6top API or 15.4SET/GET accordingly.
>  
> Just thought. 
> 
> +1 on having a talk about YANG.
> 
> Thanks
> Qin
>  
> 
> 
> On Thu, Nov 21, 2013 at 1:52 PM, Xavier Vilajosana Guillen <[email-masked]> wrote:
> Hi all,
> 
> looking 1) from another perspective. As we want 6top to be able to operate and be an interface for network management protocols, we have to ask ourselves if having a 6top layer that only offers configuration options to TSCH MAC layer MIB is useful and complete. I think that most of the problem will fall into the YANG Model data representation, i.e. Should this model cover all MIB attributes on L2? 
> 
> Related to that, how this is done on other stacks and protocol suites? Zigbee? ISA100.11a?, etc.. I assume that the management layer is able to configure everything on L2 no? 
> 
> My opinion on that is that at Data Model level we should address all MIB elements. At API/interface level only those related to TSCH and 6top MIB as implementers will bypass other calls to the corresponding L2 interfaces not related to TSCH.
> 
> Besides, +1 on having a tutorial/overview about YANG. Any expert?
> 
>  
> 
> 
> On Wed, Nov 20, 2013 at 8:38 PM, Thomas Watteyne <[email-masked]> wrote:
> Qin,
> 
> I believe you are asking the hardest question there is. I personally have little experience with YANG, so please don't hesitate to refute/correct anything.
> 
> (1) Should upper layer be allowed to access MAC layer PIB directly? 
> 
> What exactly do you mean by "accessing". I see a node as having resources on which you can perform CRUD operations (Create, Read, Update, Delete). If we are talking about the ability to Create/Update/Delete, we obviously need to ensure that changing a particular attribute does not interfere with the operation of 6top.
> 
> That being said, the divide you propose is probably the right one: separating 15.4 and 15.4e-specific PIB elements.
> 
> Does this mean you would replace call to e.g. the security GET/SET commands by "raw" access to the 15.4 PIB?
> 
> (2) What is the coverage of 6top data model, what is the relationship between 6top data model and 6top API?
> 
> AFAIK, YANG (http://tools.ietf.org/html/rfc6020) allows you to define state data, configuration data, and remote procedure calls. I'm copy-pasting the definitions from RFC6020:
> 
> configuration data:
>    The set of writable data that is required to transform
>    a system from its initial default state into its current
>    state.
> 
> state data:
>    The additional data on a system that is not configuration
>    data such as read-only status information and collected
>    statistics.
> 
> RPC:
>    Remote Procedure Call
> 
> The goal of this exercise is to express the 6top interface in YANG. This means finding the subset of functionality that are best described as "data", and some that are best described as "rpc".
> 
> From talking to Mehmet Ersue (co-chair NETCONF) in Vancouver, people have a tendency to overload the RPC. His recommendation is, if you can express some functionality as data, don't use rpc.
> 
> For our case, it looks like most of the functionality we are looking for lends itself well to simple CRUD operations (add link, remove neighbor, update tie source neighbor), so I would imagine the YANG model would contain mostly data elements.
> 
> As highlighted by Xavi a couple of calls ago, we (certainly I) don't feel comfortable enough with YANG yet. Any YANG aficionados who could extend a helping hand?
> 
> (3) Is it suitable to use Yang model to express such kind of data model and how?
> 
> Hmm. I believe I went a bit overboard in the previous answer, which also covers this question.
> 
> Thomas
> 
> On Wed, Nov 20, 2013 at 6:26 AM, Qin Wang <[email-masked]> wrote:
> Hi all,
> 
> In the current version of 6top draft http://www.ietf.org/internet-drafts/draft-wang-6tisch-6top-00.txt, we define 6top API with a set of commands, by which upper layer can access 6top MIB, IEEE802.15.4e TSCH PIB, and some but not all of IEEE802.15.4 PIB. You can find more detail in the attached file, which is prepared for the coming Friday Call.
> 
> Here are my questions: 
> (1) Should upper layer be allowed to access MAC layer PIB directly? 
> (2) What is the coverage of 6top data model, what is the relationship between 6top data model and 6top API?
> (3) Is it suitable to use Yang model to express such kind of data model and how?
> 
> I think possible answers to the first two questions are:
> (1) Allow upper layer to access PIB defined in IEEE802.15.4-2011 directly, but not allow upper layer to access the PIB added by TSCH in IEEE802.15.4e-2012.
> (2) 6top data model will cover 6top MIB and all of the attributes defined by both IEEE802.15.4-2011 and IEEE802.15.4e TSCH, but 6top API only provides commands for upper layer to access 6top MIB and the attributes added by TSCH.
> 
> What do you think? Any comment and suggestion is welcome.
> 
> Thanks
> Qin 
> 
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
> 
> 
> 
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
> 
> 
> 
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
> 
> 
> 
> 
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch