Re: [netmod] Question on draft-ietf-netmod-yang-model-classification
cation] is "service delivery module" not >> include >> the "customer service module". The [draft-ietf-l3sm-l3vpn-service-model] is >> actually the "customer service module". >> >> Here comes the question: >> 1. Whether it's necessary to further classify the "Network Service YANG >> Module"? >> 2. What's the well definition of "Network Service YANG Module", "customer >> service module", "service delivery module"? >> 3. What's the well position of the above terms in the management >> architecture? >> >> Good to see if we can solve the conflicts, these two I-Ds can complement each >> other. >> >> Best, >> Tianran >> >>> -Original Message- >>> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Carl Moberg >>> (camoberg) >>> Sent: Thursday, February 09, 2017 12:48 AM >>> To: adr...@olddog.co.uk >>> Cc: ops...@ietf.org; >>> draft-ietf-netmod-yang-model-classificat...@ietf.org; netmod@ietf.org; >>> Dean Bogdanovic >>> Subject: Re: [netmod] Question on >>> draft-ietf-netmod-yang-model-classification >>> >>> Team, >>> >>> Inline below. >>> >>>> On Feb 8, 2017, at 8:04 AM, Adrian Farrel wrote: >>>> >>>> Hi Dean, >>>> >>>> I've been processing your response and the continuing thread with you >>> and Tianran. >>>> >>>>>> We've been trying to ensure that >>>>>> draft-wu-opsawg-service-model-explained is consistent with the >>>>>> latest version of draft-ietf-netmod-yang-model-classification. In >>>>>> discussions with Tianran a question has come up. >>>>>> >>>>>> In section 2 you have a nice definition of Network Service YANG >>>>>> Modules and this definition maps nicely to our definition of "service >>> delivery models". >>>>>> Furthermore, your figure 1 shows Network Service YANG Modules on the >>>>>> interface between OSS/BSS and the various network services. >>>>>> >>>>>> We have further defined "customer service models" at a higher layer >>>>>> still. That is, on the interface to the customer. This (of course?) >>>>>> assumes that the OSS/BSS is not customer code :-) >>>>>> >>>>>> However, your discussion of Network Service YANG Modules in section >>>>>> 2.1 seems slightly at odds, although this may be just ambiguity. >>>>>> >>>>>> For example, when you say, "Network Service YANG Modules describe >>>>>> the characteristics of a service, as agreed upon with consumers of that >>> service," >>>>>> this is not the same as, "This model is used in the discussion >>>>>> between a customer and a service provide to describe the characteristics >>> of a service." >>>>>> That is, the former case could be arrived at after processing based >>>>>> on the latter case - processing that we have called "service >>>>>> orchestration" but might (of course) be what leads to the operator poking >>> the OSS/BSS. >>>>> >>>>> Adrian, I can see the ambiguity. The point of service module is to be >>>>> consumed by the customer and there can be some modifications of the >>>>> service module to adapt to the customer specifics. >>>> >>>> So far I agree with your email and therefore not with your document. The >>> OSS/BSS is not, IMHO, a tool used by the customer. >>>> >>>> Please see Figure 3 in draft-wu-opsawg-service-model-explained-05.txt >>> that shows the customer distinct from the OSS/BSS. >>> >>> IMHO figure 3 in the draft is what it says, an _example_ of a set of >>> relationships between the constituent parts of a provisioning/activation >>> system. >>> >>> In all real-world applications, customers are several layers above the >>> “service orchestrator” and adjacent systems. But the YANG model nevertheless >>> serves the purpose of describing the structure of the service for customer >>> (outside the SP) or other consuming parties (e.g. the OSS/BSS teams). >>> >>>>>> This might all be fine and good, but later in the same section you >>>>>
Re: [netmod] Question on draft-ietf-netmod-yang-model-classification
t;> this is >> based on the chair work on L3SM and L2SM WG and discussion with operators. >> But the document think the "Network Service YANG Module" defined in [draft- >> ietf-netmod-yang-model-classification] is "service delivery module" not >> include >> the "customer service module". The [draft-ietf-l3sm-l3vpn-service-model] is >> actually the "customer service module". >> >> Here comes the question: >> 1. Whether it's necessary to further classify the "Network Service YANG >> Module"? >> 2. What's the well definition of "Network Service YANG Module", "customer >> service module", "service delivery module"? >> 3. What's the well position of the above terms in the management >> architecture? >> >> Good to see if we can solve the conflicts, these two I-Ds can complement each >> other. >> >> Best, >> Tianran >> >>> -Original Message- >>> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Carl Moberg >>> (camoberg) >>> Sent: Thursday, February 09, 2017 12:48 AM >>> To: adr...@olddog.co.uk >>> Cc: ops...@ietf.org; >>> draft-ietf-netmod-yang-model-classificat...@ietf.org; netmod@ietf.org; >>> Dean Bogdanovic >>> Subject: Re: [netmod] Question on >>> draft-ietf-netmod-yang-model-classification >>> >>> Team, >>> >>> Inline below. >>> >>>> On Feb 8, 2017, at 8:04 AM, Adrian Farrel wrote: >>>> >>>> Hi Dean, >>>> >>>> I've been processing your response and the continuing thread with you >>> and Tianran. >>>> >>>>>> We've been trying to ensure that >>>>>> draft-wu-opsawg-service-model-explained is consistent with the >>>>>> latest version of draft-ietf-netmod-yang-model-classification. In >>>>>> discussions with Tianran a question has come up. >>>>>> >>>>>> In section 2 you have a nice definition of Network Service YANG >>>>>> Modules and this definition maps nicely to our definition of "service >>> delivery models". >>>>>> Furthermore, your figure 1 shows Network Service YANG Modules on the >>>>>> interface between OSS/BSS and the various network services. >>>>>> >>>>>> We have further defined "customer service models" at a higher layer >>>>>> still. That is, on the interface to the customer. This (of course?) >>>>>> assumes that the OSS/BSS is not customer code :-) >>>>>> >>>>>> However, your discussion of Network Service YANG Modules in section >>>>>> 2.1 seems slightly at odds, although this may be just ambiguity. >>>>>> >>>>>> For example, when you say, "Network Service YANG Modules describe >>>>>> the characteristics of a service, as agreed upon with consumers of that >>> service," >>>>>> this is not the same as, "This model is used in the discussion >>>>>> between a customer and a service provide to describe the characteristics >>> of a service." >>>>>> That is, the former case could be arrived at after processing based >>>>>> on the latter case - processing that we have called "service >>>>>> orchestration" but might (of course) be what leads to the operator poking >>> the OSS/BSS. >>>>> >>>>> Adrian, I can see the ambiguity. The point of service module is to be >>>>> consumed by the customer and there can be some modifications of the >>>>> service module to adapt to the customer specifics. >>>> >>>> So far I agree with your email and therefore not with your document. The >>> OSS/BSS is not, IMHO, a tool used by the customer. >>>> >>>> Please see Figure 3 in draft-wu-opsawg-service-model-explained-05.txt >>> that shows the customer distinct from the OSS/BSS. >>> >>> IMHO figure 3 in the draft is what it says, an _example_ of a set of >>> relationships between the constituent parts of a provisioning/activation >>> system. >>> >>> In all real-world applications, customers are several layers above the >>> “service orchestrator” and adjacent systems. But the YANG model nevertheless >>> serves the purpose of describing the struc
Re: [netmod] Question on draft-ietf-netmod-yang-model-classification
Hi Tianran, Nice summary. I think some of the confusion may be that draft-ietf-netmod-yang-model-classification shows "Network Service YANG Modules" on the interface between OSS/BSS and the network. But the "customer service model" is at a different place in the hierarchy as shown in Figure 4 of draft-wu-opsawg-service-model-explained. To attend to your specific questions: > 1. Whether it's necessary to further classify the "Network Service YANG > Module"? I'm not particularly interested in doing that except so far as is necessary to avoid conflict between the two I-Ds. In draft-wu-opsawg-service-model-explained we introduced "customer service module" and "service delivery module" because it seemed (to us) that there were two different groups of people using the term "service model" to describe very different modules. > 2. What's the well definition of "Network Service YANG Module", "customer > service module", "service delivery module"? Since draft-wu-opsawg-service-model-explained introduces the terms "customer service module" and "service delivery module" I am going to say that I am happy with the definitions in that document. I can say that "customer service module" is used consistently with the L3SM and L2SM work and so it is probably a stable definition. "Service delivery module" is a term we invented to match the definition in draft-wu-opsawg-service-model-explained: I don't think the term is used anywhere else, so maybe a better question is "is this a useful/meaningful term?" If the answer to Q1 is that draft-wu-opsawg-service-model-explained should not try to resolve any overlap with draft-ietf-netmod-yang-model-classification, then I think the definition of "Network Service YANG Module" in draft-ietf-netmod-yang-model-classification is fine (with the few tweaks Dean and I discussed on the list). > 3. What's the well position of the above terms in the management architecture? Ah, I like that question. But it makes me ask: where should I look for the definitive, state-of-the art management architecture? Thanks for continuing to drive this issue. Adrian > -Original Message- > From: Tianran Zhou [mailto:zhoutian...@huawei.com] > Sent: 14 February 2017 09:54 > To: Carl Moberg (camoberg); adr...@olddog.co.uk > Cc: ops...@ietf.org; draft-ietf-netmod-yang-model-classificat...@ietf.org; > netmod@ietf.org; Dean Bogdanovic > Subject: RE: Question on draft-ietf-netmod-yang-model-classification > > Hi, > > Based on the discussion, here I try to clean up the confusion of the two I-Ds. > > [draft-ietf-netmod-yang-model-classification] classifies the yang modules into > "Network Service YANG Module" and the "Network Element YANG Module". > And usually, it uses "service module" to imply the "Network Service YANG > Module", i.e., "Network" here only want to limit the scope to network related > modules. One example of "Network Service YANG Module" is [draft-ietf-l3sm- > l3vpn-service-model]. > The authors do not want to further classify the service module into more > layers, > until more operational practice comes. > > [draft-wu-opsawg-service-model-explained] further classifies the service > module > into "customer service module" and the "service delivery module". I think > this is > based on the chair work on L3SM and L2SM WG and discussion with operators. > But the document think the "Network Service YANG Module" defined in [draft- > ietf-netmod-yang-model-classification] is "service delivery module" not > include > the "customer service module". The [draft-ietf-l3sm-l3vpn-service-model] is > actually the "customer service module". > > Here comes the question: > 1. Whether it's necessary to further classify the "Network Service YANG > Module"? > 2. What's the well definition of "Network Service YANG Module", "customer > service module", "service delivery module"? > 3. What's the well position of the above terms in the management architecture? > > Good to see if we can solve the conflicts, these two I-Ds can complement each > other. > > Best, > Tianran > > > -Original Message- > > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Carl Moberg > > (camoberg) > > Sent: Thursday, February 09, 2017 12:48 AM > > To: adr...@olddog.co.uk > > Cc: ops...@ietf.org; > > draft-ietf-netmod-yang-model-classificat...@ietf.org; netmod@ietf.org; > > Dean Bogdanovic > > Subject: Re: [netmod] Question on > > dr
Re: [netmod] Question on draft-ietf-netmod-yang-model-classification
Hi, Based on the discussion, here I try to clean up the confusion of the two I-Ds. [draft-ietf-netmod-yang-model-classification] classifies the yang modules into "Network Service YANG Module" and the "Network Element YANG Module". And usually, it uses "service module" to imply the "Network Service YANG Module", i.e., "Network" here only want to limit the scope to network related modules. One example of "Network Service YANG Module" is [draft-ietf-l3sm-l3vpn-service-model]. The authors do not want to further classify the service module into more layers, until more operational practice comes. [draft-wu-opsawg-service-model-explained] further classifies the service module into "customer service module" and the "service delivery module". I think this is based on the chair work on L3SM and L2SM WG and discussion with operators. But the document think the "Network Service YANG Module" defined in [draft-ietf-netmod-yang-model-classification] is "service delivery module" not include the "customer service module". The [draft-ietf-l3sm-l3vpn-service-model] is actually the "customer service module". Here comes the question: 1. Whether it's necessary to further classify the "Network Service YANG Module"? 2. What's the well definition of "Network Service YANG Module", "customer service module", "service delivery module"? 3. What's the well position of the above terms in the management architecture? Good to see if we can solve the conflicts, these two I-Ds can complement each other. Best, Tianran > -Original Message- > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Carl Moberg > (camoberg) > Sent: Thursday, February 09, 2017 12:48 AM > To: adr...@olddog.co.uk > Cc: ops...@ietf.org; > draft-ietf-netmod-yang-model-classificat...@ietf.org; netmod@ietf.org; > Dean Bogdanovic > Subject: Re: [netmod] Question on > draft-ietf-netmod-yang-model-classification > > Team, > > Inline below. > > > On Feb 8, 2017, at 8:04 AM, Adrian Farrel wrote: > > > > Hi Dean, > > > > I've been processing your response and the continuing thread with you > and Tianran. > > > >>> We've been trying to ensure that > >>> draft-wu-opsawg-service-model-explained is consistent with the > >>> latest version of draft-ietf-netmod-yang-model-classification. In > >>> discussions with Tianran a question has come up. > >>> > >>> In section 2 you have a nice definition of Network Service YANG > >>> Modules and this definition maps nicely to our definition of "service > delivery models". > >>> Furthermore, your figure 1 shows Network Service YANG Modules on the > >>> interface between OSS/BSS and the various network services. > >>> > >>> We have further defined "customer service models" at a higher layer > >>> still. That is, on the interface to the customer. This (of course?) > >>> assumes that the OSS/BSS is not customer code :-) > >>> > >>> However, your discussion of Network Service YANG Modules in section > >>> 2.1 seems slightly at odds, although this may be just ambiguity. > >>> > >>> For example, when you say, "Network Service YANG Modules describe > >>> the characteristics of a service, as agreed upon with consumers of that > service," > >>> this is not the same as, "This model is used in the discussion > >>> between a customer and a service provide to describe the characteristics > of a service." > >>> That is, the former case could be arrived at after processing based > >>> on the latter case - processing that we have called "service > >>> orchestration" but might (of course) be what leads to the operator poking > the OSS/BSS. > >> > >> Adrian, I can see the ambiguity. The point of service module is to be > >> consumed by the customer and there can be some modifications of the > >> service module to adapt to the customer specifics. > > > > So far I agree with your email and therefore not with your document. The > OSS/BSS is not, IMHO, a tool used by the customer. > > > > Please see Figure 3 in draft-wu-opsawg-service-model-explained-05.txt > that shows the customer distinct from the OSS/BSS. > > IMHO figure 3 in the draft is what it says, an _example_ of a set of > relationships between the constituent parts of a provisioning/activation > system. > > In all real-world applications, customers are several layer
Re: [netmod] Question on draft-ietf-netmod-yang-model-classification
Team, Inline below. > On Feb 8, 2017, at 8:04 AM, Adrian Farrel wrote: > > Hi Dean, > > I've been processing your response and the continuing thread with you and > Tianran. > >>> We've been trying to ensure that draft-wu-opsawg-service-model-explained is >>> consistent with the latest version of >>> draft-ietf-netmod-yang-model-classification. In discussions with Tianran a >>> question has come up. >>> >>> In section 2 you have a nice definition of Network Service YANG Modules and >>> this definition maps nicely to our definition of "service delivery models". >>> Furthermore, your figure 1 shows Network Service YANG Modules on the >>> interface between OSS/BSS and the various network services. >>> >>> We have further defined "customer service models" at a higher layer still. >>> That >>> is, on the interface to the customer. This (of course?) assumes that the >>> OSS/BSS is not customer code :-) >>> >>> However, your discussion of Network Service YANG Modules in section 2.1 >>> seems slightly at odds, although this may be just ambiguity. >>> >>> For example, when you say, "Network Service YANG Modules describe the >>> characteristics of a service, as agreed upon with consumers of that >>> service," >>> this is not the same as, "This model is used in the discussion between a >>> customer and a service provide to describe the characteristics of a >>> service." >>> That is, the former case could be arrived at after processing based on the >>> latter case - processing that we have called "service orchestration" but >>> might >>> (of course) be what leads to the operator poking the OSS/BSS. >> >> Adrian, I can see the ambiguity. The point of service module is to be >> consumed by >> the customer and there can be some modifications of the service module to >> adapt to the customer specifics. > > So far I agree with your email and therefore not with your document. The > OSS/BSS is not, IMHO, a tool used by the customer. > > Please see Figure 3 in draft-wu-opsawg-service-model-explained-05.txt that > shows the customer distinct from the OSS/BSS. IMHO figure 3 in the draft is what it says, an _example_ of a set of relationships between the constituent parts of a provisioning/activation system. In all real-world applications, customers are several layers above the “service orchestrator” and adjacent systems. But the YANG model nevertheless serves the purpose of describing the structure of the service for customer (outside the SP) or other consuming parties (e.g. the OSS/BSS teams). >>> This might all be fine and good, but later in the same section you say >>> "Network >>> Service YANG Modules define service models to be consumed by external >>> systems. >>> These modules are commonly designed, developed and deployed by network >>> infrastructure teams." And there you introduce two terms that are previously >>> undefined and only server to add ambiguity. Specifically "external to >>> what?" I >>> could make and argument that the OSS is developed and deployed by network >>> infrastructure teams, ad also that the OSS is external to the network >>> itself. >> >> Agree that external systems are not defined and this text has to be >> clarified. The >> external systems can be OSS and BSS. > > If we relabelled our "Service Delivery Model" as "Network Service Model" > would that be consistent? > > That is, in any case, to say that the OSS/BSS does not talk directly to the > devices. I think that would help. And yes, the intent of “external” was to say “other than”, rather than “outside of the company” (or something like that). >>> And, in between these two quoted pieces of text, you have... >>> >>> As an example, the Network Service YANG Module defined in >>> [YANG-Data-Model-for-L3VPN-service-delivery] provides an abstract >>> model for Layer 3 IP VPN service configuration. >> >> My question is where do you see the L3SM model >> above or below OSS? > > Well, look at the figure in section 5 of > draft-ietf-l3sm-l3vpn-service-model-19.txt > > It is logically higher, but OSS/BSS are not "in the flow" as they are legacy > components in a softwarized world. > However, per our pictures, OSS/BSS should use the same set of models/modules > as used by the "service orchestrator”. This is a little different in different SPs. Many of them consider the RFS-style service definition as laid out in L3SM as something that is owned by the infratrstucture and ordered through the OSS/BSS layer (the order manager to be more precise). >> Because there are some nuances in the service module, but at the end we >> decided not to do sub classification > > Mutter, mutter. > In the document, you talk about "network service modules" not "service > modules" and only trim to "service module" in the text implying that you > always actually mean "network service module”. We always mean “network service models”, there are many “service models” out there that have little or nothing to do with
Re: [netmod] Question on draft-ietf-netmod-yang-model-classification
Hi Dean, I've been processing your response and the continuing thread with you and Tianran. > > We've been trying to ensure that draft-wu-opsawg-service-model-explained is > > consistent with the latest version of > > draft-ietf-netmod-yang-model-classification. In discussions with Tianran a > > question has come up. > > > > In section 2 you have a nice definition of Network Service YANG Modules and > > this definition maps nicely to our definition of "service delivery models". > > Furthermore, your figure 1 shows Network Service YANG Modules on the > > interface between OSS/BSS and the various network services. > > > > We have further defined "customer service models" at a higher layer still. > > That > > is, on the interface to the customer. This (of course?) assumes that the > > OSS/BSS is not customer code :-) > > > > However, your discussion of Network Service YANG Modules in section 2.1 > > seems slightly at odds, although this may be just ambiguity. > > > > For example, when you say, "Network Service YANG Modules describe the > > characteristics of a service, as agreed upon with consumers of that > > service," > > this is not the same as, "This model is used in the discussion between a > > customer and a service provide to describe the characteristics of a > > service." > > That is, the former case could be arrived at after processing based on the > > latter case - processing that we have called "service orchestration" but > > might > > (of course) be what leads to the operator poking the OSS/BSS. > > Adrian, I can see the ambiguity. The point of service module is to be > consumed by > the customer and there can be some modifications of the service module to > adapt to the customer specifics. So far I agree with your email and therefore not with your document. The OSS/BSS is not, IMHO, a tool used by the customer. Please see Figure 3 in draft-wu-opsawg-service-model-explained-05.txt that shows the customer distinct from the OSS/BSS. > > This might all be fine and good, but later in the same section you say > > "Network > > Service YANG Modules define service models to be consumed by external > > systems. > > These modules are commonly designed, developed and deployed by network > > infrastructure teams." And there you introduce two terms that are previously > > undefined and only server to add ambiguity. Specifically "external to > > what?" I > > could make and argument that the OSS is developed and deployed by network > > infrastructure teams, ad also that the OSS is external to the network > > itself. > > Agree that external systems are not defined and this text has to be > clarified. The > external systems can be OSS and BSS. If we relabelled our "Service Delivery Model" as "Network Service Model" would that be consistent? That is, in any case, to say that the OSS/BSS does not talk directly to the devices. > > And, in between these two quoted pieces of text, you have... > > > > As an example, the Network Service YANG Module defined in > > [YANG-Data-Model-for-L3VPN-service-delivery] provides an abstract > > model for Layer 3 IP VPN service configuration. > > My question is where do you see the L3SM model > above or below OSS? Well, look at the figure in section 5 of draft-ietf-l3sm-l3vpn-service-model-19.txt It is logically higher, but OSS/BSS are not "in the flow" as they are legacy components in a softwarized world. However, per our pictures, OSS/BSS should use the same set of models/modules as used by the "service orchestrator". > Because there are some nuances in the service module, but at the end we > decided not to do sub classification Mutter, mutter. In the document, you talk about "network service modules" not "service modules" and only trim to "service module" in the text implying that you always actually mean "network service module". > one is the business and one technical service. > > When i read the YANG-Data-Model-for-L3VPN-service-delivery, it looked to me > much more like a technical model, then the business model, as didn’t see SLA > definitions to track the business parameters of the service use. It is certainly not a business model and does not include SLAs. Other people have far more experience working on these things (TMF, MEF, ...) and it is not an IETF core competence. Our intention is that our module can be augmented or accompanied by other modules in order to create a business model, acknowledging that commercial details (even including SLAs) will vary from one operator to another, but that the core technical description of the service can be (and, it turns out, is) common across multiple providers. We even wrote text in Section 5 of draft-wu-opsawg-service-model-explained to help with this. > > Per my other email, this reference needs to be fixed. But I struggle to see > > the > > L3SM module as consistent with your figure. It may or may not be consistent > > with your text dependent on the interpretation. > > Sure,
Re: [netmod] Question on draft-ietf-netmod-yang-model-classification
> On Jan 19, 2017, at 4:25 PM, Adrian Farrel wrote: > > Hi, > > We've been trying to ensure that draft-wu-opsawg-service-model-explained is > consistent with the latest version of > draft-ietf-netmod-yang-model-classification. In discussions with Tianran a > question has come up. > > In section 2 you have a nice definition of Network Service YANG Modules and > this > definition maps nicely to our definition of "service delivery models". > Furthermore, your figure 1 shows Network Service YANG Modules on the interface > between OSS/BSS and the various network services. > > We have further defined "customer service models" at a higher layer still. > That > is, on the interface to the customer. This (of course?) assumes that the > OSS/BSS > is not customer code :-) > > However, your discussion of Network Service YANG Modules in section 2.1 seems > slightly at odds, although this may be just ambiguity. > > For example, when you say, "Network Service YANG Modules describe the > characteristics of a service, as agreed upon with consumers of that service," > this is not the same as, "This model is used in the discussion between a > customer and a service provide to describe the characteristics of a service." > That is, the former case could be arrived at after processing based on the > latter case - processing that we have called "service orchestration" but might > (of course) be what leads to the operator poking the OSS/BSS. Adrian, I can see the ambiguity. The point of service module is to be consumed by the customer and there can be some modifications of the service module to adapt to the customer specifics. > > This might all be fine and good, but later in the same section you say > "Network > Service YANG Modules define service models to be consumed by external systems. > These modules are commonly designed, developed and deployed by network > infrastructure teams." And there you introduce two terms that are previously > undefined and only server to add ambiguity. Specifically "external to what?" I > could make and argument that the OSS is developed and deployed by network > infrastructure teams, ad also that the OSS is external to the network itself. Agree that external systems are not defined and this text has to be clarified. The external systems can be OSS and BSS. > > And, in between these two quoted pieces of text, you have... > > As an example, the Network Service YANG Module defined in > [YANG-Data-Model-for-L3VPN-service-delivery] provides an abstract > model for Layer 3 IP VPN service configuration. My question is where do you see the L3SM model above or below OSS? Because there are some nuances in the service module, but at the end we decided not to do sub classification one is the business and one technical service. When i read the YANG-Data-Model-for-L3VPN-service-delivery, it looked to me much more like a technical model, then the business model, as didn’t see SLA definitions to track the business parameters of the service use. > > Per my other email, this reference needs to be fixed. But I struggle to see > the > L3SM module as consistent with your figure. It may or may not be consistent > with > your text dependent on the interpretation. Sure, we can fix that reference, but the authors of L3SM module should do their own module classification, as they are the only ones that know the intent of the module. > > In draft-wu-opsawg-service-model-explained Figure 4 we have tried to show how > we > (the authors) think L3SM fits into your classification. Here we place L3SM > further up the layering stack. > > [Apologies for not spotting this sooner. The citation > "YANG-Data-Model-for-L3VPN-service-delivery" includes the term "service > delivery" which I took to imply a different module.] > No worries and sorry for late reply Dean > Thanks, > Adrian > ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Question on draft-ietf-netmod-yang-model-classification
Hi Tianran, I agree, it is very confusing. It doesn't help (me) that folk are using the term "device model" when I can't find a definition of that term. Maybe this is intended to be a synonym for "Network Element YANG Modules" that is used in draft-wu-opsawg-service-model-explained and draft-ietf-netmod-yang-model-classification. In draft-wu-opsawg-service-model-explained we tried to bring the terminology into alignment by also using "Device Configuration Model" for this. draft-ietf-netmod-yang-model-classification is pretty clear. Network Element YANG Modules describe the characteristics of a network device as defined by the vendor of that device. The modules 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]. The module provides a coherent data model representation of the software environment consisting of the operating system and applications running on the device. The decomposition, ordering, and execution of changes to the operating system and application configuration is the task of the agent that implements the module. Note: "a network device". So, if a module contains information about multiple devices (because coordinated behavior is needed to enable a service) or about the network itself when facilitating the service, then the module is something bigger than the Network Element YANG Module as defined in draft-ietf-netmod-yang-model-classification. That's OK. It doesn't make the module wrong or evil. It doesn't mean the module has no value. It just means that the module needs a different name. In draft-wu-opsawg-service-model-explained we chose to call this type of module a "Network Configuration Model". I don't believe that these authors of draft-wu-opsawg-service-model-explained can be clearer on our definitions and motivations for listing the particular modules that are work-in-progress in particular categories. We could, however, stop mentioning such modules if that make everyone less uncomfortable. This would not substantially change the value of our document (which is about service models). Thanks, Adrian > -Original Message- > From: Tianran Zhou [mailto:zhoutian...@huawei.com] > Sent: 23 January 2017 09:33 > To: adr...@olddog.co.uk; netmod@ietf.org > Cc: ops...@ietf.org; draft-ietf-netmod-yang-model-classificat...@ietf.org > Subject: RE: [OPSAWG] Question on draft-ietf-netmod-yang-model-classification > > To add more comments: > > On the L2SM meeting, several people (4 or more) believed the 3 service delivery > model examples ([I-D.dhjain-bess-bgp-l3vpn-yang], [I-D.ietf-bess-l2vpn-yang] > and [I-D.ietf-bess-evpn-yang]) are actually device models. > > I think both of the two I-Ds ([draft-ietf-netmod-yang-model-classification] and > [draft-wu-opsawg-service-model-explained]) can check if those YANG models > are device models or service models. > > Regards, > Tianran > > > -Original Message- > > From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Adrian Farrel > > Sent: Friday, January 20, 2017 12:25 AM > > To: netmod@ietf.org > > Cc: ops...@ietf.org; > > draft-ietf-netmod-yang-model-classificat...@ietf.org > > Subject: [OPSAWG] Question on draft-ietf-netmod-yang-model-classification > > > > Hi, > > > > We've been trying to ensure that draft-wu-opsawg-service-model-explained > > is consistent with the latest version of > > draft-ietf-netmod-yang-model-classification. In discussions with Tianran > > a question has come up. > > > > In section 2 you have a nice definition of Network Service YANG Modules > > and this definition maps nicely to our definition of "service delivery > > models". > > Furthermore, your figure 1 shows Network Service YANG Modules on the > > interface between OSS/BSS and the various network services. > > > > We have further defined "customer service models" at a higher layer still. > > That is, on the interface to the customer. This (of course?) assumes that > > the OSS/BSS is not customer code :-) > > > > However, your discussion of Network Service YANG Modules in section 2.1 > > seems slightly at odds, although this may be just ambiguity. > > > > For example, when you say, "Network Service YANG Modules describe the > > characteristics of a service, as agreed upon with consumers of that service," > > this is not the same as, "This model is used in the discussion between a > > customer and a service provide to describe the characteristics of a service." > > That is, the former case could be arrived at after processing based on the > > latter case - processing that we have called "service orchestration" but > > might (of course) be what leads to the operator poking the OSS/BSS. > > > > This might all be fine and good, but later in the same section you say "Network > > Service YANG Modules define service models to be consumed by external > > systems. > > These mo
[netmod] Question on draft-ietf-netmod-yang-model-classification
Hi, We've been trying to ensure that draft-wu-opsawg-service-model-explained is consistent with the latest version of draft-ietf-netmod-yang-model-classification. In discussions with Tianran a question has come up. In section 2 you have a nice definition of Network Service YANG Modules and this definition maps nicely to our definition of "service delivery models". Furthermore, your figure 1 shows Network Service YANG Modules on the interface between OSS/BSS and the various network services. We have further defined "customer service models" at a higher layer still. That is, on the interface to the customer. This (of course?) assumes that the OSS/BSS is not customer code :-) However, your discussion of Network Service YANG Modules in section 2.1 seems slightly at odds, although this may be just ambiguity. For example, when you say, "Network Service YANG Modules describe the characteristics of a service, as agreed upon with consumers of that service," this is not the same as, "This model is used in the discussion between a customer and a service provide to describe the characteristics of a service." That is, the former case could be arrived at after processing based on the latter case - processing that we have called "service orchestration" but might (of course) be what leads to the operator poking the OSS/BSS. This might all be fine and good, but later in the same section you say "Network Service YANG Modules define service models to be consumed by external systems. These modules are commonly designed, developed and deployed by network infrastructure teams." And there you introduce two terms that are previously undefined and only server to add ambiguity. Specifically "external to what?" I could make and argument that the OSS is developed and deployed by network infrastructure teams, ad also that the OSS is external to the network itself. And, in between these two quoted pieces of text, you have... As an example, the Network Service YANG Module defined in [YANG-Data-Model-for-L3VPN-service-delivery] provides an abstract model for Layer 3 IP VPN service configuration. Per my other email, this reference needs to be fixed. But I struggle to see the L3SM module as consistent with your figure. It may or may not be consistent with your text dependent on the interpretation. In draft-wu-opsawg-service-model-explained Figure 4 we have tried to show how we (the authors) think L3SM fits into your classification. Here we place L3SM further up the layering stack. [Apologies for not spotting this sooner. The citation "YANG-Data-Model-for-L3VPN-service-delivery" includes the term "service delivery" which I took to imply a different module.] Thanks, Adrian ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
