[netmod] 答复: yang model classification

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.

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
> 