Subject: [OPSAWG] Fwd: AD Review of draft-ietf-opsawg-service-model-explained

From: Warren Kumari <[email-masked]>
Date: Tue, 5 Sep 2017 08:15:48 -0400

Apologies, I forgot to CC the WG.

I'll also be asking Benoit to give it the once over, as he is much
more familiar with this topic.
W

---------- Forwarded message ----------
From: Warren Kumari <[email-masked]>
Date: Mon, Sep 4, 2017 at 8:43 PM
Subject: AD Review of draft-ietf-opsawg-service-model-explained
To: [email-masked]

Hi there,

First off, thanks for a really well written document -- this is one of
the cleanest AD reviews I've done.
I do have some very minor grammar nits.
I'd prefer a new version with these addressed, but they are all
sufficiently minor that I'm also OK starting the LC as is. Please let
me know which you'd prefer.

1: While unfortunate, I think many will not understand the q.v. in the
Service definition in Section 2. Terms and Concepts. Perhaps break it
out, or more clearly point where more info is to be found.

2: Section 6.3.  Customer Service Model Work
"The most advanced presents the L3VPN service..."  - I'd suggest
"Currently the most advanced presents the L3VPN service..." -- there
may be another, more advanced one soon...

The reset of the nits are in [O]riginal, [P]roposed, [R]emark / Reason
/ Rational / <something else that starts with R> format.

Section Abstract
This document describes service models as used within the IETF, and
[O] IETF, and
[P] IETF and
[R] grammar

Section 1. Introduction.

 Within the context of Software Defined Networking (SDN) [RFC7149]
   [RFC7426] YANG data models may be used on the interface between a
[O] [RFC7426] YANG data models
[P] [RFC7426], YANG data models
[R] grammar

Ultimately they could be used in online, software-driven dynamic
   systems, and eventually as part of an SDN system.
[O] systems, and
[P] systems and
[R] grammar

 Equally, this document clarifies what a service model is
   not, and dispels some common misconceptions.
[O] not, and
[P] not and
[R] grammar - I think.

Section 2.  Terms and Concepts

   An example of where such details are relevant to the customer
         are when they describe the behavior or interactions on the
[O] are when
[P] is when
[R] subject/verb agreement ("An example [...] is [...]")

   The distinction between a customer service model and a service
   delivery model needs to be repeatedly clarified.  A customer service

[O] repeatedly clarified.
[R] This seems like an odd thing to say. Maybe, "needs to be
emphasized" or "bears repeating" instead?

Section 4.  Service Models in an SDN Context

 That is, there should be an independence between the
   behavior and functions that a customer requests and the technology
   that the network operator has available to deliver the service.  The
[O] That is, there should be an independence between the behavior and
functions that a customer requests and the technology that the network
operator has available to deliver the service.
[P] That is, the behavior and functions that a customer requests
should be independent of the technology that the network operator has
available to deliver the service.
[R] readability. Not sure if P is much better.

Section 5. Possible Causes of Confusion

 SLAs are also linked to commercial terms
      with penalties and so forth, and so are also not good topics for
[O] and so are also not good
[P] and thus SLAs are also not good
[R] grammar/clarity

Section 6.1. Comparison With Network Service Models
  These are
   service delivery models as described in this document, that is, they

[O] document, that is, they
[P] document; that is, they
[R] grammar

   are the models used on the interface between the Service Orchestrator
   or OSS/BSS and the Network Orchestrator as shown in Figure 3.

   Figure 1 of [RFC8199] can be modified to make this more clear and to
   add an additional example of a Network Service YANG model as shown in
   Figure 4.  This figure illustrates a functional architecture and an

[O] architecture and an
[P] architecture, and an
[R] grammar

Section 6.2. Service Delivery and Network Element Model Work

These models focus on how the network operator configures
   the network through protocols and devices to deliver a service.  Some
   of these models are classified as service delivery models while

[O] models while
[P] models, while
[R] grammar

6.4.  The MEF Architecture

This does not invalidate either approach, but only

[O] approach, but
[P] approach;
[R] grammar (or "either approach, it only" ?)

7.2.  Relationship to Policy

 As with commercial terms and SLAs discussed in Section 5 it is

[O] Section 5 it is
[P] Section 5, it is
[R] grammar

7.3.  Operator-Specific Features

They also understood
   that should an individual network operator want to describe
   additional features (operator-specific features) they could do so by

[O] that should an individual network operator want to describe
additional features (operator-specific features)

[P] that, should an individual network operator want to describe
additional features (operator-specific features),
[R] grammar

7.4.  Supporting Multiple Services

[O] It is an implementation and deployment choice whether all service

   models are processed by a single Service Orchestrator that can
   coordinate between the different services, or whether each service
   model is handled by a specialized Service Orchestrator able to
   provide tuned behavior for a specific service.
[P] Whether each service model is handled by a specialized Service
Orchestrator able to provide tuned behavior for a specific service or
whether all service models are handled by a single Service
Orchestrator is an implementation and deployment choice.
[R] readability

Section 8.  Security Considerations

Therefore it is important that the protocol interface used to
   exchange service request information between customer and network
   operator is subject to authorization, authentication, and encryption.
   Equally, all external intefaces, such as any of those between the

[O] intefaces
[P] interfaces
[R] spelling

W

--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 5 Sep 2017 13:45:20 +0100

Warren, thanks.
Updating now.
A

> -----Original Message-----
> From: OPSAWG [mailto:[email-masked]] On Behalf Of Warren Kumari
> Sent: 05 September 2017 13:16
> To: [email-masked]
> Subject: [OPSAWG] Fwd: AD Review of draft-ietf-opsawg-service-model-
> explained
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 5 Sep 2017 15:31:47 +0100

Hi again...

> out, or more clearly point where more info is to be found.

Yeah, my mistake for writing in a language that has been dead for 2000 years :-)

Added proper pointer.

> may be another, more advanced one soon...

:-)

Meant "most advanced through the IETF process." But anyway...

OLD
   Several initiatives within the IETF are developing customer service
   models.  The most advanced presents the L3VPN service as described by
   a network operator to a customer.  The L3SM is described as in
   Figure 5 which is reproduced from [RFC8049].  As can be seen, the
   L3SM is a customer service model as described in this document.
NEW
   Several initiatives within the IETF are developing customer service
   models.  The L3SM presents the L3VPN service as described by
   a network operator to a customer.  Figure 5, which is reproduced
   from [RFC8049], shows that the L3SM is a customer service
   model as described in this document.  
END  

> This document describes service models as used within the IETF, and

Debateable and left to RFC Ed for house style.

> [P] [RFC7426], YANG data models

You're just moving my commas from one place to another.

But, yes.

>    systems, and eventually as part of an SDN system.

See?
But leaving this one to RFC Ed as well.

>    not, and dispels some common misconceptions.

Ditto

> [R] subject/verb agreement ("An example [...] is [...]")

Yes.  I feel bad about this one.

> emphasized" or "bears repeating" instead?

Was my bitterness showing through?

s/repeatedly clarified/clarified/

> [R] readability. Not sure if P is much better.

OLD
    That is, there should be an independence between the
    behavior and functions that a customer requests and the technology
    that the network operator has available to deliver the service. 
NEW
    That is, the technology that the network operator has available to
    deliver the service should not influence the behavior and functions that
    a customer requests.
END

> [P] and thus SLAs are also not good

OK

> [P] document; that is, they

OK

>    Figure 4.  This figure illustrates a functional architecture and an 

Yes. Now you want to put a comma in for exactly the construction you wanted to
remove them from before :-)

Here I agree with you.

>    of these models are classified as service delivery models while

OK

> [R] grammar (or "either approach, it only" ?)

OLD
    This does not invalidate either approach, but only observes that they are
    different.
NEW
    This does not invalidate either approach: it only observes that they are
    different approaches.
END

>  As with commercial terms and SLAs discussed in Section 5 it is

OK

> additional features (operator-specific features),

OK

> Orchestrator is an implementation and deployment choice.

Good

>    Equally, all external intefaces, such as any of those between the

OK

Posted.
Thanks,
Adrian

---

From: Warren Kumari <[email-masked]>
Date: Tue, 5 Sep 2017 17:16:50 -0400

> Meant "most advanced through the IETF process." But anyway...

Ah, I *so* didn't get that...

> You're just moving my commas from one place to another.

Yes, yes I am. You gotta met me have *some* fun!

> Yes.  I feel bad about this one.

https://imgflip.com/i/1vcf6j

:-P

> remove them from before :-)

https://media3.giphy.com/media/bA5EUCvMgDBkc/200_s.gif

>>    Equally, all external intefaces, such as any of those between the

Thank you very much.
W

---

From: Benoit Claise <[email-masked]>
Date: Wed, 13 Sep 2017 18:51:40 +0200

Dear all,

Warren asked me to review this document part of the AD review.
I know we're in last call right now: Whether the comments are part of AD 
review or IETF LC comment doesn't matter at this point in time.
Here is my feedback.

Figure 3: Network configuration model is a brand new term that is only mentioned in the figure, and not explained.
In the same figure, could the "Device Configuration Model" be renamed to RFC 8199 "Network Element YANG module"
(this is what you did in figure 4 anyway)

- section 6.2 "service delivery and network element model work"

    Some
    of these models are classified as service delivery models, while
    others have details that are related to specific element
    configuration and so are classed as network element models (also
    called device models).

Next to each model description, that would help the audience to clarify what the correct term is: customer service model, service delivery model, network service YANG modules [RFC8199]

- In RFC 8199, we made a distinction between model and YANG modules. This is why we defined the terms "Network Service YANG_modules_" and "Network Element YANG_modules_" and not models.
You should follow this convention. After all, from the abstract, this document focuses on YANG.
Ex: should "model" be replaced by "YANG module"?

- section 6.4 "The MEF architecture".
Do we want to mention that MEF currently focuses on the customer service model?

- I'm glad you cleverly avoided the term "intend"

Regards, Benoit

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 20 Sep 2017 13:08:33 +0100

Hey Benoit,
 
Thanks for the review.
 
> in the figure, and not explained.
 
OMG! That is a good catch.
 
> In the same figure, could the "Device Configuration Model" be renamed to RFC 8199 
> "Network Element YANG module" (this is what you did in figure 4 anyway)
 
I believe we are separating the "device configuration model" that is used to talk to an NE, and a "network configuration model" used to talk to a controller that is responsible for a set of NEs. I think the correct thing is to add exactly that statement (i.e., a definition of the terms alongside figure 3).  Then the mapping of these terms should show up alongside Figure 4.
 
But, you know what?
Looking at this made me go back to Figure 1 of RFC8199 again. And finally I understood it. That is probably a bit sad.
I had been misled (no blame associated) by the OSS/BSS box in the figure because that is an entity not a module. That made me read the horizontal lines as interfaces (over which the named module types are used) and the boxes as functional units that consume the modules.
Now, that  is a *horrible* misreading, but there we go! And RFC8199 has already been published, so adding clarification so that fools like me are not confused is not possible.
 
I believe the intention is to  only show modules and not things that consume or use modules.
So I wonder whether we should make some clarification in our Figure 4. Possibly it should look like...
 
     - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     Operations Support and Business Support YANG Modules
 
     +-----------------------+     +-----------------------+
     |                       |     |                       |
     |    Customer Service   |     |         Other         |            
     |      YANG Modules     |     |  Operations Support   |
     |                       |     |          and          |
     |  +------+   +------+  |     |    Business Support   |
     |  |      |   |      |  |     |      YANG Modules     |
     |  | L2SM |   | L3SM |  |     |                       |
     |  |      |   |      |  |     |                       |
     |  +------+   +------+  |     |                       |
     |                       |     |                       |
     +-----------------------+     +-----------------------+
 
     - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     Network Service YANG Modules
 
    +------------+   +-------------+   +-------------+   +-------------+
    |            |   |             |   |             |   |             |
    |  - L2VPN   |   |   - L2VPN   |   |    EVPN     |   |    L3VPN    |
    |  - VPWS    |   |   - VPLS    |   |             |   |             |
    |            |   |             |   |             |   |             |
    +------------+   +-------------+   +-------------+   +-------------+
 
     - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     Network Element YANG Modules
 
     +------------+  +------------+  +-------------+  +------------+
     |            |  |            |  |             |  |            |
     |    MPLS    |  |    BGP     |  | IPv4 / IPv6 |  |  Ethernet  |
     |            |  |            |  |             |  |            |
     +------------+  +------------+  +-------------+  +------------+
 
The text in that section becomes...
 
           <t>As previously noted, <xref target="RFC8199" /> provides a classification
           of YANG data modules.  It introduces the term "Network Service YANG Module" to
           identify the type of module used to "describe the configuration, state data,
           operations and notifications of abstract representations of services implemented
           on one or multiple network elements."  These modules are used to construct the 
           service delivery models as described in this document; that is, they are the 
           modules used on the interface between the Service Orchestrator or OSS/BSS and
           the Network Orchestrator as shown in <xref target="svc_arch" />.</t>
 
           <t>Figure 1 of <xref target="RFC8199" /> can be modified to make this more clear
           and to add an additional example of a Network Service YANG module as shown in
           <xref target="modfig" />.  As can be seen, the highest classification of modules
           collects those that are used to deliver operations support and business support.
           These might be consumed by an Operations Support System (OSS) or a Business Support
           System (BSS), and a Service Orchestrator may form part of an OSS/BSS or may be a
           separate component.  This highest layer in the figure is divided into the Customer
           Service Modules that are used to describe services to a customer as discussed in
           this document, and other modules that describe further OSS/BSS function such as
           billing and SLAs.</t>
 
> Next to each model description, that would help the audience to clarify what the correct term is:
> customer service model, service delivery model, network service YANG modules [RFC8199]
 
I agree, but we have made a conscious decision to not do that *in*this*document*. None of the models in 6.2 is a customer service model (so that part is easy), but beyond that we could not get coherent advice from the authors of the listed documents. Most were pretty certain that their work was "mainly network element model" although some thought that they were dealing with "network wide configuration" and a few thought they were "delivering services".
 
While it would be good to get more clarity on this, it looks like we are trying to retrofit an architecture on an organically evolved set of modules and perhaps we shouldn't push too hard. What is important in this document is to get the "Customer Service Model" piece more clearly explained.
 
> In RFC 8199, we made a distinction between model and YANG modules. This is why we defined
> the terms "Network Service YANG modules" and "Network Element YANG modules" and not models.
 
The definition imported from 7950 by 8199 looks like a reasonable distinction and we will attempt to apply it here. I hope I am not importing too much thought from SMI but isn't a "model" built from one or modules? A model is used to "model" some larger entity or function, while a module is used to describe a component of an entity or a granular function.
 
Probably just some cleanup needed through this document. I'll have a go.
 
> Do we want to mention that MEF currently focuses on the customer service model?
 
We could do this, but...
Not so happy to use "currently" in an archival document.
Also not comfortable about asserting in an IETF document what another body is doing.
And not convince that the MANO architecture is focused in the way you describe.
 
So I prefer no change for this.
 
> - I'm glad you cleverly avoided the term "intend"
 
That was intentional :-)
 
Thanks,
Adrian

---

From: Benoit Claise <[email-masked]>
Date: Wed, 27 Sep 2017 10:55:26 +0200

Hi Adrian,
> I believe we are separating the "device configuration model" that is 
> used to talk to an NE, and a "network configuration model" used to 
> talk to a controller that is responsible for a set of NEs. I think the 
> correct thing is to add exactly that statement (i.e., a definition of 
> the terms alongside figure 3).Then the mapping of these terms should 
> show up alongside Figure 4.
>
ok.
>
> But, you know what?
>
> Looking at this made me go back to Figure 1 of RFC8199 again. And 
> finally I understood it. That is probably a bit sad.
>
> I had been misled (no blame associated) by the OSS/BSS box in the 
> figure because that is an entity not a module. That made me read the 
> horizontal lines as interfaces (over which the named module types are 
> used) and the boxes as functional units that consume the modules.
>
> Now, thatis a *horrible* misreading, but there we go! And RFC8199 has 
> already been published, so adding clarification so that fools like me 
> are not confused is not possible.
>
> +-----------------------++-----------------------+
>
> ||||
>
> |Customer Service||Other|
>
> |YANG Modules||Operations Support|
>
> |||and|
>
> |+------++------+||Business Support|
>
> |||||||YANG Modules|
>
> || L2SM || L3SM ||||
>
> ||||||||
>
> |+------++------+|||
>
> ||||
>
> +-----------------------++-----------------------+
>
> +------------++-------------++-------------++-------------+
>
> ||||||||
>
> |- L2VPN| |- L2VPN||EVPN||L3VPN|
>
> |- VPWS||- VPLS|||||
>
> ||||||||
>
> +------------++-------------++-------------++-------------+
>
> +------------++------------++-------------++------------+
>
> ||||||||
>
> |MPLS||BGP|| IPv4 / IPv6 ||Ethernet|
>
> ||||||||
>
> +------------++------------++-------------++------------+
>
> of YANG data modules.It introduces the term "Network Service YANG 
> Module" to
>
> on one or multiple network elements."These modules are used to 
> construct the
>
> <xref target="modfig" />.As can be seen, the highest classification of 
> modules
>
> separate component.This highest layer in the figure is divided into 
> the Customer
>
Fine with me.
> > customer service model, service delivery model, network service YANG 
I understand the difficulty and the conscious decision.
This is however the first question readers will ask themselves, and the 
conclusion that the experts could find the answer is not a good sign. 
Anyway, let's move on.
>
> I agree, but we have made a conscious decision to not do that 
> *in*this*document*. None of the models in 6.2 is a customer service 
> model (so that part is easy), but beyond that we could not get 
> coherent advice from the authors of the listed documents. Most were 
> pretty certain that their work was "mainly network element model" 
> although some thought that they were dealing with "network wide 
> configuration" and a few thought they were "delivering services".
>

> While it would be good to get more clarity on this, it looks like we 
> are trying to retrofit an architecture on an organically evolved set 
> of modules and perhaps we shouldn't push too hard. What is important 
> in this document is to get the "Customer Service Model" piece more 
> clearly explained.
>
> The definition imported from 7950 by 8199 looks like a reasonable 
> distinction and we will attempt to apply it here. I hope I am not 
> importing too much thought from SMI but isn't a "model" built from one 
> or modules? A model is used to "model" some larger entity or function, 
> while a module is used to describe a component of an entity or a 
> granular function.
>
Fair enough.

Regards, Benoit