Re: [netmod] Question on draft-ietf-netmod-yang-model-classification

[Dean Bogdanovic <[e-mail]>]

Hi Adrian and Tianran,
> On Feb 14, 2017, at 5:23 AM, Adrian Farrel <[e-mail]> wrote:
> 
> 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.

As Carl mentioned, there are can be multiple network service classifications, example technical and business models, but we decided to leave it as single model. In early versions of private draft (draft-bogdanovic-netmod-yang-model-classification-00)
there were 3 different services models,

business service model was connected to OSS/BSS and then there was network service model (technical) and service component models.

After discussions and from our experiences talking to operators we decided  to collapse that into single classification name.

> 
> 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.
Authors of draft-ietf-netmod-yang-model-classification would be against, as we decided that way early in our work
> 
>> 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).

I agree with Adrian’s tweaks and will update the draft accordingly.
> 
>> 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?

As few years ago, would be willing to put something forward on this topic, but today the management architecture is in such a flux, that Adrian’s question needs an answer first.

Dean

> 
> Thanks for continuing to drive this issue.
> 
> Adrian
> 
>> -----Original Message-----
>> From: Tianran Zhou [mailto:[e-mail]]
>> Sent: 14 February 2017 09:54
>> To: Carl Moberg (camoberg); [e-mail]
>> Cc: [e-mail]; [e-mail];
>> [e-mail]; 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:[e-mail]] On Behalf Of Carl Moberg
>>> (camoberg)
>>> Sent: Thursday, February 09, 2017 12:48 AM
>>> To: [e-mail]
>>> Cc: [e-mail];
>>> [e-mail]; [e-mail];
>>> 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 <[e-mail]> 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 the network. And I would
>>> like to not go there :-)
>>> 
>>>>> 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, 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.
>>>> 
>>>> That is fine. They can classify it, and they can use your
>>>> classification system, but only if it can be understood, is
>>>> meaningful, and fits what they are trying to achieve :-)
>>>> 
>>>> Your text currently says
>>>>  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.
>>>> 
>>>> Your text and figures show "Network Service YANG Module" as being
>> something
>>> that the OSS/BSS talks (presumably toward a network orchestrator?). Thus
>>> the L3SM module does not fit here. And that is why we wrote
>>> draft-wu-opsawg-service-model-explained and included Figure 4 to augment
>>> your figure.
>>> 
>>> Figure 4 also seems like an _example_ of how one could structure the layers.
>>> Personally I have never seen an implementation of a clear split between
>>> "Network Service YANG Modules” and "Service YANG Modules”. That’s why we
>>> wanted to stay clear of that discussion until there is experience telling
>>> us that this is indeed best practice.
>>> 
>>>> And *finally*, Tianran is concerned that there may be confusion arising
>>> from whether the module we reference are "Network service modules",
>> "service
>>> delivery modules", "network configuration modules", "network element
>>> modules", or "device configuration modules". So many terms, but presumably
>>> these modules don't fit into all of the categories! The list is:
>>>> 
>>>> [I-D.dhjain-bess-bgp-l3vpn-yang]
>>> 
>>> “”"
>>>   There are two parts of the BGP L3VPN yang data model.  The first part
>>>   of the model defines VRF specific parameters for L3VPN by augmenting
>>>   the routing-instance container defined in the routing model [I-
>>>   D.ietf-netmod-routing-cfg] and the second part of the model defines
>>>   BGP specific parameters for the L3VPN by augmenting the base BGP data
>>>   model defined in [I-D.shaikh-idr-bgp-model].
>>> “””
>>> 
>>> and it’s importing ietf-routing, ietf-interfaces, ietf-interfaces
>>> augmenting /rt:routing/ and /if:interfaces/.
>>> 
>>> From draft-ietf-netmod-yang-model-classification:
>>> 
>>> “””
>>>   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 would say that [e-mail] is a network element YANG
>>> module.
>>> 
>>>> [I-D.ietf-bess-l2vpn-yang]
>>> 
>>> “””
>>>   In this version of the document, one single container, l2vpn, is
>>>   defined.  Within the l2vpn container, endpoint-a, endpoint-z and a
>>>   list of endpoints are defined. […]
>>> “”"
>>> 
>>> From draft-ietf-netmod-yang-model-classification:
>>> 
>>> “””
>>>   That is, a
>>>   service module does not expose the detailed configuration parameters
>>>   of all participating network elements and features, but describes an
>>>   abstract model that allows instances of the service to be decomposed
>>>   into instance data according to the Network Element YANG Modules of
>>>   the participating network elements.
>>> “””
>>> 
>>> I would say that [e-mail] is a network service YANG
>>> module.
>>> 
>>>> [I-D.ietf-bess-evpn-yang]
>>> 
>>> 
>>> This draft contains two modules:
>>> - [e-mail]
>>> - [e-mail]
>>> 
>>> Reading the first paragraph of section 3.1 “Overview”
>>> 
>>> “””
>>>      Two top level module, Ethernet-Segment and EVPN, are defined. The
>>>   Ethernet-Segment contains a list of interface to which any Ethernet-
>>>   Segment attributes are configured/applied.
>>> “””
>>> 
>>> …and understanding that the list of interfaces can be located on different
>>> network elements, makes me think that these two modules are both examples
>>> of network device YANG modules.
>>> 
>>>> I wonder what type of module you think these are.
>>>> 
>>>> Cheers,
>>>> Adrian
>>>> 
>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> netmod mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netmod
>