Adrian, I just want to clarify one issue on BSS. Order management is part of the BSS and when external customer is ordering a new service, it talks to the order management system (either through a sales person or directly via self ordering application). The BSS then sends request to the provisioning system to create the service, essentially the service orchestrator. So I would argue that BSS is exposed to the external consumers of the service, but those systems are developed by internal teams.
I will update the draft according to some of your comments, but will leave this for the moment in the draft and we can have a discussion on this at the WG session or offline before or after. Dean > On Feb 14, 2017, at 11:23 AM, Adrian Farrel <adr...@olddog.co.uk> 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. > > 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 >>> 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 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
