I would prefer to have all terms people find agreement on in a single document.
/js On Tue, Feb 14, 2017 at 09:54:10AM +0000, Tianran Zhou wrote: > 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 <adr...@olddog.co.uk> 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 ietf-bgp-l3...@2016-02-22.yang 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 ietf-l2...@2016-10-24.yang is a network service YANG > > module. > > > > > [I-D.ietf-bess-evpn-yang] > > > > > > This draft contains two modules: > > - ietf-ethernet-segm...@2016-07-08.yang > > - ietf-e...@2016-07-08.yang > > > > 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 > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > OPSAWG mailing list > ops...@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
