Hi Carl, > - The term “Network Service Model” in RFC 8199 is intended to cover both > "Customer Service Model” as well as “Service Delivery Model” as defined > in draft-ietf-opsawg-service-model-explained. At the time of the first > revision of what was > draft-bogdanovic-netmod-yang-model-classification > we discussed further splitting "Network Service Model” into smaller > components, but decided against it since we did not see a consensus on > what that split would look like. I believe the authors here is > suggesting such a further split.
I think that an "issue" with RFC 8199 is that is appears to imply that the "Network Service Module" (sic) it defines is used on a specific interface rather than simply being the classification of "all modules used north of this point". This our draft is doing slightly more than partitioning the classification. The last couple of rounds of edits to what became 8199 were working with Dean to slightly soften thee language used to make this more consistent. But see below... > There is one specific passage in this draft that I would suggest could > use rephrasing if the authors agree to the above: > > """ > As previously noted, [I-D.ietf-netmod-yang-model-classification] > provides a classification of YANG data models. It introduces the > term "Network Service YANG Module" to identify the type of model used > to "describe the configuration, state data, operations and > notifications of abstract representations of services implemented on > one or multiple network elements." These are service delivery models > as described in this document, that is, they are the models used on > the interface between the Service Orchestrator or OSS/BSS and the > Network Orchestrator as shown in Figure 3. > """ You suggest this could be rephrased, but don't suggest how:-) I just checked 8199 and I see that the quote we have is still accurate. I am wondering what it is specifically about this text that worries you. Again, this may come back to the use of a module on a functional interface. I read 8199 as saying that the "Network Service YANG Modules are used by the OSS/BSS in talking to the network elements (o perhaps Controllers?) to configure the network to deliver the service. Am I wrong? If I'm right in my reading we are not "splitting" the classification, but introducing a new class that lives further north (where the atmosphere is thinner and the temperature colder) > - And this gets to my second point of feedback. Figure 4. in the draft > seems to suggest that the "Service Orchestrator" is an entity separate > from the "Operations and Business Support Systems (OSS/BSS)". I want to jump into this paragraph at once just to say "no, no, no!" This figure (like most I draw in ASCII these days) displays functional components not physical entities. How you choose to implement is entirely up to you. It seems likely (to me) that the interface between customer and operator is externally exposed (but not necessarily realised using RESTconf). It does not seem obvious to me that the Service Orchestrator and the OSS/BSS are separate blobs, except to note that the OSS/BSS deployed today does not support the Customer Service YANG Modules and so the extent to which it provides "service orchestration" is limited. I might also claim that an OSS/BSS possibly operates on a single network where the orchestration of a service *might* involve the coordination of more than one network. > And also that > Customers (as defined) in Section 2 interface directly with that entity. > This is a very unusual construct, in the sense that: > o The common taxonomomy from e.g. TMForum would classify a service > orchestrator as a part of the OSS/BSS stack, since... > o The successful activation of a service includes many parts of the > OSS/BSS-stack including operational readiness (are there physical > ports available), billing management (is the customer allowed to > perform e.g. this resource expansion), and assurance (changed > services require new assurance parameters). This makes it hard > to separate out a Customer interface to service orchestration > only, separate from the OSS/BSS stack. I am not (overly) familiar with the TMF work, however, your text "TMForum would classify a service orchestrator as a part of the OSS/BSS stack" suggests the acceptance of service orchestration as "a thing". If you were writing code, you *might* write a separate module (even library) to handle service orchestration, and maintain that as a separate module from billing management, etc. That does not make them completely separate, but does result in them showing as separate functional components in the "OSS/BSS stack." > This an informational draft and as such is for general information, and > not necessarily intended to represent community consensus or > recommendation, just like 8119. I choose to disagree! 8199 had WG and IETF last call. It has community consensus. The intention of this draft is that it, too, will have IETF community consensus. But be aware that we are neither trying to force that consensus, nor dictate the terminology. What we are doing is trying to answer the (often repeated) question: "Where do L2SM and L3SM fit into the picture since they don't seem to be intended to talk to network devices or controllers?" > But I would suggest the document could be > improved by elaborating the point of the separation of the orchestrator > and the BSS/OSS and the resulting difference in module types. I could certainly add text around Figure 4 to say "...this illustrates a functional architecture and an implementation might not choose to make the distinctions shown such that separations and interfaces illustrated might fall within a single implementation." Would that help? Many thanks, Adrian _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
