Re: [netmod] [OPSAWG] Cross-post to Netmod for LC comments//FW: WG LC for Service Models Explained

["Adrian Farrel" <[e-mail]>]

Hi Carl,

I'm in the process of updating the document and wanted to let you know what changes are being made.

>>>  - 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.
> 
> Right, and the reason why we took the "all modules used north of this point” is
> that we have not seen any sign of convergence around abstractions into smaller
> components. In short: implementations of “YANG for services” is currently all
> over the map.
> 
>> 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)
> 
>  I think at the core of the feedback (and sorry that it took two rounds of email to
> make it shorter :-) is that in 8199 the Service Orchestrator is assumed to be an
> integral part of OSS/BSS. More below.

OK. This is much clearer to me now, and leads into the stuff below.

>>> - 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).
> 
>  This is perhaps also at the core of the feedback. I have never seen an
> implementation/architecture with a functionally distinct Service Orchestrator
> (outside of OSS/BSS) exposed directly to customers. There is usually at least
> something like an order manager (as part of the OSS/BSS) between the customer
> and the service orchestrator. Even in the instances of self-service portals (which
> are naturally located very close to the network) there is at least some notion of
> pricing and billing involved.

Funny that I find I agree and disagree :-)
You are completely right about the status quo. Also about the importance of commercial tools as part of the system.
On the other hand, we (well, I) don't want to inhibit developmental approaches. For example, a customer might (within some pre-established bounds) be allowed to request and modify services directly and have the commercial repercussions follow on.

All that said we converge below...

>> 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.
> 
> Well, a common pattern is to have the order manager put in orders for technical
> service activation from a service orchestrator. The uptake of YANG seems to be
> mostly in the interface between the order manager (an integral part of OSS/BSS)
> and the service orchestrator.
> 
>> 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.
> 
> Hmm, since the actual business is accounted for in the OSS/BSS (including rating,
> charging, billing) I’m not sure how a multi-network service orchestrator outside of
> an OSS/BSS context would work.
> 
>>> 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.”
> 
> Exactly right. The term “OSS/BSS” itself as I’m used to hearing it is a means of
> grouping a (huge) set of functions under a common label.
> 
>>> 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.
> 
> True. It was a heavy-handed attempt at pushing on the fact that we’re not
> writing standards here, but merely working to inform. But you’re absolutely right
> that WG work items reflect 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?”
> 
> Makes sense. And in my simplistic (8199-infused) mind, e.g. ietf-l2vpn-
> [e-mail] is a great example of a Network Service Module. So far so
> good ;-) Whether we can come up with further classification to robustly capture
> the "scope of and purpose of an IETF service model” is next.
> 
>>> 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?
> 
>  With the further elaboration above, would this make sense?

OK. We're working with that figure.

 
>           +---------------+
>           |               |
>           |   Customers   |
>           |               |
>           +---------------+
> 
>       - - - - - - - - - - - - - -
>      Customer Service YANG Modules
> 
>       +-------------------------------------------------------------+
>       |     Operations and Business Support System (OSS/BSS)        |
>       |              +--------------------------+                   |
>       |              |   Service Orchestrator   |                   |
>       |              +--------------------------+                   |
>       +-------------------------------------------------------------+
> 
>      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>      Network Service YANG Modules
> 
>     +------------+   +-------------+   +-------------+   +-------------+
>     |            |   |             |   |             |   |             |
>     |  - L2VPN   |   |   - L2VPN   |   |    EVPN     |   |    L3VPN    |
>     |  - VPWS    |   |   - VPLS    |   |             |   |             |
>     |            |   |             |   |             |   |             |
>     +------------+   +-------------+   +-------------+   +-------------+
> 
>      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>      Network Element YANG Modules
> 
>      +------------+  +------------+  +-------------+  +------------+
>      |            |  |            |  |             |  |            |
>      |    MPLS    |  |    BGP     |  | IPv4 / IPv6 |  |  Ethernet  |
>      |            |  |            |  |             |  |            |
>      +------------+  +------------+  +-------------+  +------------+
> 
>        L2VPN: Layer 2 Virtual Private Network
>        L3VPN: Layer 3 Virtual Private Network
>        VPWS: Virtual Private Wire Service
>        VPLS: Virtual Private LAN Service

Cheers,
Adrian