Subject: Re: [OPSAWG] WG LC for Service Models Explained

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

Dan, thanks!

> Comment #1 - The current abstract could be simmered down to:
> 
> The IETF has produced a number of data modules in the  YANG modelling
> language.  The majority of these modules are used to construct data models
> to model devices or monolithic functions.
> 
> A small number of YANG modules have been defined to model services (for
> example, the Layer Three Virtual Private Network Service Model produced by
> the L3SM working group and documented in RFC 8049).
> 
> This document describes the role of an IETF service model, and where a
> service model might fit into a Software Defined Networking architecture.
> Note that service models do not make any assumption of how a service is
> engineered and delivered to the customer; details of how network protocols
> and devices are engineered to deliver a service are captured in other models
> that are not exposed through the Customer-Provider Interface.

OK. Appreciate reducing the Abstract. Most changes good. Some "not far enough".
But I would like to keep the mention of config and operational status.

So...

   The IETF has produced a number of data modules in the YANG modelling
   language.  The majority of these are used to construct data models to
   model devices or monolithic functions and they allow access for 
   configuration and to read operational status.

   A small number of YANG modules have been defined to model services
   (for example, the Layer Three Virtual Private Network Service Model
   documented in RFC 8049).

   This document describes the role of an IETF service model, and shows
   where a service model fits into a Software Defined Networking architecture.
   Note that service models do not make any assumption of how a service is
   engineered and delivered for a customer; details of how network protocols
   and devices are engineered to deliver a service are captured in other models
   that are not exposed through the Customer-Provider Interface.

> Comment #2 - A mix of "modelling" and "modeling" usage in the document.
> British or American is fine, but maybe not both.

Oh, yes. Fixing.

> Comment #3 - Section 1. Introduction, second paragraph, last sentence:
> ""There may also be a hierarchy of such components with super-controllers,
> domain controllers, and device controllers all exchanging information and
> instructions using YANG models"
> 
> The only reference to "super-controller" I found (using a popular search
> engine) was an accessory for the Nintendo Entertainment System video game
> console. Maybe the authors might want to use the term "super controller".

Isn't the Super Controller a character in Guardians of the Galaxy?

> Comment #4 - Section 1. Introduction, third paragraph, last sentence:
> "Ultimately they could be used in online, software-driven dynamic systems."
> 
> Why not use the term "software defined networks" or "SDN systems", instead
> of "online, software-driven dynamic systems". You use the term "software
> defined networks" in the abstract and earlier in the introductory text, and
> again in section 4.

Yes. Actually we should say both since "online, software-driven dynamic systems"
is only a step on the path to SDN. Hence...

   Such models may be used in manual and even paper-driven
   service request processes with a gradual transition to IT-based
   mechanisms.  Ultimately they could be used in online, software-driven
   dynamic systems, and eventually as part of an SDN system.

> Comment #5 - Section 3. Using Service Models, third paragraph, last
> sentence:
> 
> "However, co-located software components might use an API, while systems
> with more direct human interactions might use web pages or even paper
> forms."
> 
> Indeed RFC6241 and RFC8040 are data-model/schema-driven APIs. Should the
> sentence read ("internal API" or "private API"), as in:
> 
> "However, co-located software components might use an internal API, while
> systems with more direct human interactions might use web pages or even
> paper forms."

O tempera, o mores.

Once upon a time there were APIs and remote APIs (which weren't really APIs at
all but rather a communications library accessed via an API and delivering
remotely via another API). But language is a living medium :-)

I don't object to "internal API".

> Comment #6 - The document uses capitalised and non-capitalised instances of
> "Control Plane".

Ack

> Comment #9 - Section 9. Manageability Considerations
> 
> You use the term "Service Orchestration" in this section but I found no
> reference, or previous definition, in the document.

Figure 3 introduces the "Service Orchestrator". Do you think we should add more
text to explain its function?

> Overall, really minor NITs. Good job with the document.

Thanks.
All nits are good nits.

Adrian

---

From: <[email-masked]>
Date: Wed, 2 Aug 2017 14:34:15 +0300

Thanks Adrian, all good. 

BR, Dan. 

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: 02 August 2017 13:29
To: [email-masked]; [email-masked]
Subject: RE: [OPSAWG] WG LC for Service Models Explained

Dan, thanks!

> language.  The majority of these modules are used to construct data 
> models to model devices or monolithic functions.
> 
> produced by the L3SM working group and documented in RFC 8049).
> 
> Note that service models do not make any assumption of how a service 
> is engineered and delivered to the customer; details of how network 
> protocols and devices are engineered to deliver a service are captured 
> in other models that are not exposed through the Customer-Provider
Interface.

OK. Appreciate reducing the Abstract. Most changes good. Some "not far
enough".
But I would like to keep the mention of config and operational status.

So...

   This document describes the role of an IETF service model, and shows
   where a service model fits into a Software Defined Networking
architecture.
   Note that service models do not make any assumption of how a service is
   engineered and delivered for a customer; details of how network protocols
   and devices are engineered to deliver a service are captured in other
models
   that are not exposed through the Customer-Provider Interface.

Oh, yes. Fixing.

> ""There may also be a hierarchy of such components with 
> super-controllers, domain controllers, and device controllers all 
> exchanging information and instructions using YANG models"
> 
> engine) was an accessory for the Nintendo Entertainment System video 
> game console. Maybe the authors might want to use the term "super
controller".

> Why not use the term "software defined networks" or "SDN systems", 
> instead of "online, software-driven dynamic systems". You use the term 
> "software defined networks" in the abstract and earlier in the 
> introductory text, and again in section 4.

Yes. Actually we should say both since "online, software-driven dynamic
systems"
is only a step on the path to SDN. Hence...

> "However, co-located software components might use an API, while 
> systems with more direct human interactions might use web pages or 
> even paper forms."
> 
> Indeed RFC6241 and RFC8040 are data-model/schema-driven APIs. Should 
> the sentence read ("internal API" or "private API"), as in:
> 
> "However, co-located software components might use an internal API, 
> while systems with more direct human interactions might use web pages 
> or even paper forms."

O tempera, o mores.

Once upon a time there were APIs and remote APIs (which weren't really APIs
at all but rather a communications library accessed via an API and
delivering remotely via another API). But language is a living medium :-)

> Comment #6 - The document uses capitalised and non-capitalised 
> instances of "Control Plane".

Ack

> You use the term "Service Orchestration" in this section but I found 
> no reference, or previous definition, in the document.

Figure 3 introduces the "Service Orchestrator". Do you think we should add
more text to explain its function?

Thanks.
All nits are good nits.

Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 23 Aug 2017 09:38:09 +0100

Hi Dan,

Thank for the review.

I'm currently updating the document. Here are my answers to your comments.

> that are not exposed through the Customer-Provider Interface.

Yes. Less is more.

> British or American is fine, but maybe not both.

OK. Have gone American.

> console. Maybe the authors might want to use the term "super controller".

OK

> defined networks" in the abstract and earlier in the introductory text, and

OK. Added the term "SDN".

> systems with more direct human interactions might use web pages or even

OK to add the word "internal".

> Comment #6 - The document uses capitalised and non-capitalised instances of

OK

Comments #7 and #8 intentionally left blank?

> reference, or previous definition, in the document.

Section 4 discusses splitting the orchestration function between a "Service
Orchestrator" and a "Network Orchestrator". And figure 3 presents a service
orchestrator. Additionally, the service orchestrator and service orchestration
are mentioned in a few other sections. So I think this issue is covered.

Thanks,
Adrian