Re: [netmod] yang model classification

Yali,

> On Apr 23, 2016, at 4:12 AM, zhangyali (D) <zhangyali369@huawei.com> wrote:
> 
> Hi Carl,
> 
> Thanks for your suggestion.(I also think the IPSec yang model is network element model).
> I think the main criteria to distinguish the service model and network element model is the perspective when define the model, namely, the model will be network service model when it describe the whole network service standing on the whole situation, or else, it will be a network element model. A simple example, when I describe a VPN service, if the model describes which two endpoints need be connected together, it is service model. And if the model describes the external connectivity of each device, it will be network element service. Does this method make sense?

I think it does make sense, yes.

> Best,
> Yali
> 
> -----邮件原件-----
> 发件人: Carl Moberg (camoberg) [mailto:camoberg@cisco.com] 
> 发送时间: 2016年4月22日 16:04
> 收件人: zhangyali (D)
> 抄送: netmod@ietf.org
> 主题: Re: [netmod] yang model classification
> 
> 
> --
> Carl Moberg
> Technology Director, CVG
> camoberg@cisco.com
> 
>> On Apr 22, 2016, at 4:43 AM, zhangyali (D) <zhangyali369@huawei.com> wrote:
>> 
>> Hi Carl,
>> 
>> Indeed, there is unclear functional partitioning between orchestrator and controller. So let's go back to the division of network element yang model and service yang model.
>> 
>> In my view, element yang model should be the detailed configuration for one device, such as, mtu, hop-limit,etc. But service model should be a largescale description, such as, the endpoints in the VPN. But sometimes, many configurations yang model include many devices' configuration or do not distinguish which devices are configured. So could you give me some more specific method to classify them? Maybe the draft [draft-tran-ipsecme-yang-01] is a good example.
> 
> The method to classify models along the suggested abstraction layers are defined in sections 2.1 and 2.2. The intent here is of course to be clear enough in those descriptions for people to be able to use them (i.e. classify models). If you think the content of those sections are not clear enough or plain wrong, I’d be more than happy to take that feedback.
> 
> I am not an expert in IPSec, but glancing through draft-tran-ipsecme-yang-01 I see many references to “the system”, as in:
> 
> “””
> The IPSEC Global Statistics container is used to maintain information related to all the IPSEC tunnels established in the system.
> “”"
> 
> 
> From section 2.2. in the classification model:
> 
> “””
> Network Element YANG Data Models describe the configuration, state data and operations of a network device as defined by the vendor of that device.  The models are commonly structured around features of the device, e.g. interface configuration [RFC7223], OSPF configuration [I-D.ietf-ospf-yang], and firewall rules definitions [I-D.ietf-netmod-acl-model].
> “””
> 
> I would then suggest that the modules in draft-tran-ipsecme-yang represent Network Element YANG Data Models.
> 
>> Best,
>> Yali
>> 
>> -----邮件原件-----
>> 发件人: Carl Moberg (camoberg) [mailto:camoberg@cisco.com]
>> 发送时间: 2016年4月21日 16:41
>> 收件人: zhangyali (D)
>> 抄送: netmod@ietf.org
>> 主题: Re: [netmod] yang model classification
>> 
>>> On Apr 21, 2016, at 10:30 AM, zhangyali (D) <zhangyali369@huawei.com> wrote:
>>> 
>>> Hi Carl,
>>> 
>>> Thanks for your answers very much. From your explanation, the main view is that do not distinguish the difference between network level and service level model, which all called "network service model", right?
>>> If so, the question is that how these "same layer" model could be used in the layered architecture, such as, there are orchestrator layer, controller layer and device layer? In my understanding, the NBI of orchestrator should not include any technology details which should exist in the NBI of controller. The orchestrator will complete the mapping from NBI of orchestrator to NBI of controller.
>> 
>> The view of this varies wildly across standards bodies, open source projects, vendors and many other entities involved. I.e. most orchestrators do leak technology details and NBIs of controllers contain abstractions above the network level.
>> 
>>> Let's take L2VPN as a example. In the NBI of orchestrator, the yang model just need express necessary information of L2VPN, such as, sites information and topology between sites. For the NBI of controller, the yang model may be some technology solutions, such as, VPLS, VPWS, etc. The orchestrator will choose one or some solutions depends on users' requirement. Then the controller will complete the network element configuration (using network element yang model ) according to technology solutions chosen by orchestrator.
>> 
>> That is absolutely one way of looking (and perhaps even implementing) it, among several others. In this case, and under the suggested classification in the document, both the controller and orchestrator models would be examples of Network Service YANG Data Models with different abstraction levels.
>> 
>>> Though I am not sure if the process is suitable, the service model and network model are difference which are used in different places. Any comments?
>> 
>> Above.
>> 
>>> 
>>> Best,
>>> Yali
>>> 
>>> -----邮件原件-----
>>> 发件人: Carl Moberg (camoberg) [mailto:camoberg@cisco.com]
>>> 发送时间: 2016年4月21日 15:47
>>> 收件人: zhangyali (D)
>>> 抄送: netmod@ietf.org
>>> 主题: Re: [netmod] yang model classification
>>> 
>>> Yali,
>>> 
>>>> On Apr 21, 2016, at 6:03 AM, zhangyali (D) <zhangyali369@huawei.com> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> I noticed that there is a draft intents to classify the various yang model, it is really a meaningful work. Many points are consistent with my understanding, whereas, there are some questions unclear need to inquire.
>>>> 
>>>> 1.       Why VPLS and VPWS are all service model, which is at the same level with L3VPN? In my understanding, L3VPN is a typical service model which hides the underlay network, but both VPLS and VPWS is specific technology solutions. Maybe a uniform L2VPN which abstracts service information from all layer2 technologies more like service model.
>>> 
>>> Section 2.1 goes to some length to describe that there are various types of Network Service YANG Data Models at various levels of abstractions. This means that both generic models (e.g. a technology agnostic L3 VPN model) and more implementation-oriented models (e.g. VPLS) would be classified as Network Service YANG Data Models without being at the exact same level of abstraction.
>>> 
>>>> 2.       What is the layer of technology solutions, such as, VxLAN, GRE, VPLS, etc?
>>> 
>>> If you are talking about VxLAN, GRE, VPLS configuration and operational parameters residing on a device, then it’s Network Element YANG Data models. If you’re talking about VxLAN, GRE, VPLS configuration and operational parameters as part of an "abstract model that allows instances o the service to be decomposed into instance data according to the Network Element data models of the participating network elements”, then it would be classified as a Network Service YANG Data Models. 
>>> 
>>>> 3.       In TMN M.3010, network model also a particular layer, should specific yang model cover this layer?
>>> 
>>> I have done some reading on M.3010 and believe we are well aligned in the draft. The network model would be classified ad as Network Service YANG Data Model.
>>> 
>>>> Best Regards,
>>>> Yali
>>>> 
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> 
>> 
> 