Yali, > On Apr 23, 2016, at 4:12 AM, zhangyali (D) <[email protected]> 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:[email protected]] > 发送时间: 2016年4月22日 16:04 > 收件人: zhangyali (D) > 抄送: [email protected] > 主题: Re: [netmod] yang model classification > > > -- > Carl Moberg > Technology Director, CVG > [email protected] > >> On Apr 22, 2016, at 4:43 AM, zhangyali (D) <[email protected]> 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:[email protected]] >> 发送时间: 2016年4月21日 16:41 >> 收件人: zhangyali (D) >> 抄送: [email protected] >> 主题: Re: [netmod] yang model classification >> >>> On Apr 21, 2016, at 10:30 AM, zhangyali (D) <[email protected]> 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:[email protected]] >>> 发送时间: 2016年4月21日 15:47 >>> 收件人: zhangyali (D) >>> 抄送: [email protected] >>> 主题: Re: [netmod] yang model classification >>> >>> Yali, >>> >>>> On Apr 21, 2016, at 6:03 AM, zhangyali (D) <[email protected]> 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/netmod >>> >> > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
