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

From: Tianran Zhou <[email-masked]>
Date: Tue, 1 Aug 2017 08:45:27 +0000

Hi NETMOD WG,

This is a cross post for the ongoing WGLC in OPSAWG. 

Service Models Explained
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/

Please send your comments by August 18, 2017. If you do not feel this  document should advance, please state your reasons why.

Regards,
Tianran, OPSAWG co-chair

-----Original Message-----
From: OPSAWG [mailto:[email-masked]] On Behalf Of Tianran Zhou
Sent: Friday, July 28, 2017 11:06 AM
To: [email-masked]
Cc: [email-masked]
Subject: [OPSAWG] WG LC for Service Models Explained

Dear OPSAWG,

This is a notice to start a three-week OPSAWG WG last call for the document:

Service Models Explained
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/

Please read the above draft and send any issues, comments, or corrections to this mailing list.
Please indicate your support or concerns by Friday August 18, 2017.

Authors: 
Although this is an informational document, please indicate with an email on the mailing list explicitly whether you are aware or you are not aware of any IPRs related to the drafts.

Thanks,
Tianran, as co-chair

_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Carl Moberg (camoberg)" <[email-masked]>
Date: Tue, 1 Aug 2017 10:31:02 +0000

Tianran, OPSAWG,

 Now that RFC8199 is published, I have two (somewhat associated) points of
 high-level feedback on draft-ietf-opsawg-service-model-explained:

  - 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.

    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.
"""

 - 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)". 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.

 This an informational draft and as such is for general information, and not
 necessarily intended to represent community consensus or recommendation, just
 like 8119. 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.

--
Carl Moberg
[email-masked]

> On Aug 1, 2017, at 10:45 AM, Tianran Zhou <[email-masked]> wrote:
> 
> Hi NETMOD WG,
> 
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 2 Aug 2017 01:37:16 +0000

Hi Carl,

Thank you for the comments. It's a valuable feedback from the author of the associated RFC. 
Although informational, as a working group action, I hope the document can represent the community consensus.

Cheers,
Tianran

> From: Carl Moberg (camoberg) [mailto:[email-masked]]
> Sent: Tuesday, August 01, 2017 6:31 PM
> To: Tianran Zhou
> Cc: [email-masked]; [email-masked]
> Subject: Re: [netmod] Cross-post to Netmod for LC comments//FW: WG LC for
> Service Models Explained
> 
> Tianran, OPSAWG,
> 
>  Now that RFC8199 is published, I have two (somewhat associated) points
> of  high-level feedback on draft-ietf-opsawg-service-model-explained:
> 
>     revision of what was
> draft-bogdanovic-netmod-yang-model-classification
>  This an informational draft and as such is for general information, and
> not  necessarily intended to represent community consensus or
> recommendation, just  like 8119. 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.
> 
> --
> Carl Moberg
> [email-masked]
> 
> > Please send your comments by August 18, 2017. If you do not feel this
> document should advance, please state your reasons why.
> >
> > Regards,
> > Tianran, OPSAWG co-chair
> >
> > Although this is an informational document, please indicate with an email
> on the mailing list explicitly whether you are aware or you are not aware
> of any IPRs related to the drafts.
> >
> >
> > Thanks,
> > Tianran, as co-chair
> >

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 2 Aug 2017 11:28:47 +0100

Hi Carl,

>     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...

>    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
>       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."

> 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

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

---

From: "Carl Moberg (camoberg)" <[email-masked]>
Date: Wed, 2 Aug 2017 11:35:51 +0000

Adrian,

> On Aug 2, 2017, at 12:28 PM, Adrian Farrel <[email-masked]> wrote:
> 
> Hi Carl,
> 

 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.

> 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.

> 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.

> 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 an…

 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.

> 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.

> 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.

> 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. [email-masked] 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.

> 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 inte…

 With the further elaboration above, would this make sense?

          +---------------+
          |               |
          |   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