Subject: Re: [OPSAWG] New Version Notification for draft-wu-opsawg-service-model-explained-00.txt

From: Qin Wu <[email-masked]>
Date: Tue, 5 Jul 2016 12:02:19 +0000

Hi,
We have submitted a new I-D that discusses the scope and purpose of service models within
the IETF and describes how a service model can be used by a network
operator.
https://datatracker.ietf.org/doc/draft-wu-opsawg-service-model-explained/

In addition, this draft clarifies the role and position of service model in the SDN architecture and
Clear several misconception on the service model.

Your questions and comments are welcome.

Regards!
-Qin
-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2016年7月5日 19:55
收件人: Liushucheng (Will); Adrian Farrel; Liushucheng (Will); Qin Wu
主题: New Version Notification for draft-wu-opsawg-service-model-explained-00.txt

A new version of I-D, draft-wu-opsawg-service-model-explained-00.txt
has been successfully submitted by Qin Wu and posted to the IETF repository.

Name:		draft-wu-opsawg-service-model-explained
Revision:	00
Title:		Service Models Explained
Document date:	2016-07-05
Group:		Individual Submission
Pages:		12
URL:            https://www.ietf.org/internet-drafts/draft-wu-opsawg-service-model-explained-00.txt
Status:         https://datatracker.ietf.org/doc/draft-wu-opsawg-service-model-explained/
Htmlized:       https://tools.ietf.org/html/draft-wu-opsawg-service-model-explained-00

Abstract:
   The IETF has produced a considerable number of data models in the
   YANG modelling language.  The majority of these are used to model
   devices and they allow access for configuration and to read
   operational status.

   A small number of YANG models are used to model services (for
   example, the Layer Three Virtual Private Network Service Model
   produced by the L3SM working group).

   This document briefly sets out the scope of and purpose of an IETF
   service model, and it shows where a service model might fit into a
   Software Defined Networking architecture or deployment.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Thu, 7 Jul 2016 13:47:14 +0000

Hi all,

I have quickly scanned this document. Some initial comments [ms]:

*** Page 3:

   Service Model:  A service model is a specific type of data model.  It
      describes a service and all of the parameters of the service in a
      portable, operator-independent way.  It can be used by a human or
      by software to configure or request a service and may equally be
      consumed by a human or by a software component.

[ms] I would suggest a more careful wording regarding the completeness of the model, e.g., "It aims at describing a service and all of the parameters of the service...". As discussed in L3SM in the past, for certain services (e.g., firewalls, DoS prevention, ...) the service model would have to be extended / augmented. Also note that the statement "all parameters" contradicts the statement on SLAs later in the text.

[ms] I find the wording "it can be used by a human..." confusing. Is the assumption that a user would manually type in a service request resulting in a valid data model, e.g., by manually typing in NETCONF commands? I would rather write something like "the parameters can be entered by software or also manually by a human..."

*** Page 3:

   The encoding and communication protocol used to exchange a service
   model between customer and network operator are deployment- and
   implementation-specific.  The IETF recommends the use of the NETCONF
   Configuration Protocol [RFC4741] with data encoded in XML or JSON for
   interactions "on the wire" between software components.  However, co-
   located software components might use an API, while systems with more
   direct huan interactions might use web pages or even paper forms.

[ms] I am not sure if the IETF should suggest the use of NETCONF on the northbound interface of a "service orchestrator", which seems to be the scope of this document. Are there pointers to running code that actually do that? I would rather prefer a wording such as "The IETF has standardized NETCONF and RESTCONF for interactions "on the wire" between software components".

*** Page 7:

   o  The network operator may use further data models that help to
      describe how the service is realized in the network.  These models
      might be used on the interface between the Service Orchestrator
      and the Network Orchestrator as shown in Figure 3 and might
      include many of the pieces of information in the service model
      alongside protocol parameters and device configuratin information.
      It is important that the Service Orchestrator should be able to
      map from a service model to these data models, but they are not
      the same things.

[ms] Why is it not possible that the data models are the same? In Figure 3, the "service orchestrator" is actually a "client" (read this as "customer") of the "network orchestrators". Inside an operator, the "service orchestrator" could be operated by a different organization than the "network orchestrator", i.e., there ould even be a business relationship. In general, architectures can be recursive. I think this statement requires further explanation or rewording.

*** Page 7:

   o  Service Level Agreements (SLAs) have a high degree of overlap with
      the definition of sevices present in service models.  Requests for
      specific bandwidth, for example, might be present in a service
      model, and agreement to deliver a service is a commitment to the
      description of the service in the service model, however, SLAs
      typically include a number of fine-grained details about how
      services are allowed to vary, by how much, and how often.  SLAs
      are also linked to commercial terms with penalties and so forth,
      and so are also not good topics for standardization.

[ms] I wonder if it could make sense to distinguish between SLA and Service Level Objective (SLO) or Service Level Requirement (SLR). While I agree that it is difficult to standardize commercial terms, this IMHO partly contradicts the positioning of the term "service model" earlier in the document. Maybe the scope of the definition of "service model" has to be narrowed down?

*** page 9:

6.4.  Supporting Multiple Services

   Network operators will, in general, offer many different services to
   their customers.  Each would normally be the subject of a separate
   service model.

[ms] The actual question here is if there could be communality between service models for similar services. That problem cannot be solved by this document but the text could e.g. explain that for a customer it can be confusing if separate service models model related concepts in different ways. 

Thanks

Michael

-----Original Message-----
From: OPSAWG [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Tuesday, July 05, 2016 2:02 PM
To: [email-masked]
Subject: Re: [OPSAWG] New Version Notification for draft-wu-opsawg-service-model-explained-00.txt

Hi,
We have submitted a new I-D that discusses the scope and purpose of service models within the IETF and describes how a service model can be used by a network operator.
https://datatracker.ietf.org/doc/draft-wu-opsawg-service-model-explained/

In addition, this draft clarifies the role and position of service model in the SDN architecture and Clear several misconception on the service model.

Regards!
-Qin
-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]]
发送时间: 2016年7月5日 19:55
收件人: Liushucheng (Will); Adrian Farrel; Liushucheng (Will); Qin Wu
主题: New Version Notification for draft-wu-opsawg-service-model-explained-00.txt

Abstract:

The IETF Secretariat

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

---

From: Qin Wu <[email-masked]>
Date: Mon, 11 Jul 2016 06:51:42 +0000

-----邮件原件-----
发件人: Scharf, Michael (Nokia - DE) [mailto:[email-masked]] 
发送时间: 2016年7月7日 21:47
收件人: Qin Wu; [email-masked]
主题: RE: New Version Notification for draft-wu-opsawg-service-model-explained-00.txt

Hi all,

*** Page 3:

[Qin] What the service is has been well defined and clarified before service model definition in the section 2.
That is to say, Firewall and DoS prevention are just additional functionalities that are used to enhance the basic service we defined in the document.
For what the service is not is further clarified in the section 5, the first bullet.

In addition, we don't take SLA fine granularity details combining commercial terms as service parameters, so I don't see there is inconsistency issue, for some misconception on the service model
Understanding is clarified in the different section, this is intentional.

[Qin]: what we try to convey here is Human can rely on CLI,script or other human readable language to define a service, request the service, but such parameter will not directly implemented by network element.

*** Page 3:

[Qin]: You are right, I think RESCONF is recommended on the northbound interface of a service orchestrator, your proposed change looks good. Thanks.

*** Page 7:

[Qin]: The concept to split Orchestrator into service orchestrator and network orchestrator, is the service orchestrator is network agnostic while network orchestrator is network aware.
Service model consumed by the service orchestrator could be different from the data model consumed by network orchestrator since network orchestrator need to decide what network device is selected, which protocol is enabled, which technology is used, which network interface or port is assigned. The service orchestrator doesn't need to care about the underlying technology or what protocol is available.

*** Page 7:

[Qin]: We have clarified what the service is in the section 2 and Our service model definition aligns with service definition. Yes, we need to distinguish SLA from Service Level Objective/Requirement, but not necessary introduce another new term. We have clarified their difference in the text you quoted.

*** page 9:

[Qin]: That is a good question, I hope some building blocks specified by one service model can be reused in another service model.
Unfortunately we don't have too many YANG models that are used to model service in the IETF. We could cover this in the next version if more such service models are needed.

Thanks

Michael

-----Original Message-----
From: OPSAWG [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Tuesday, July 05, 2016 2:02 PM
To: [email-masked]
Subject: Re: [OPSAWG] New Version Notification for draft-wu-opsawg-service-model-explained-00.txt

Hi,

Regards!
-Qin
-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]]
发送时间: 2016年7月5日 19:55
收件人: Liushucheng (Will); Adrian Farrel; Liushucheng (Will); Qin Wu
主题: New Version Notification for draft-wu-opsawg-service-model-explained-00.txt

Abstract:

The IETF Secretariat

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Mon, 11 Jul 2016 10:15:51 +0000

Hi Qin,

Thanks for your reply. Inline some further comments [ms2].

> [ms] I would suggest a more careful wording regarding the completeness
> of the model, e.g., "It aims at describing a service and all of the
> parameters of the service...". As discussed in L3SM in the past, for
> certain services (e.g., firewalls, DoS prevention, ...) the service
> model would have to be extended / augmented. Also note that the
> statement "all parameters" contradicts the statement on SLAs later in
> the text.
> 
> [Qin] What the service is has been well defined and clarified before
> service model definition in the section 2.
> That is to say, Firewall and DoS prevention are just additional
> functionalities that are used to enhance the basic service we defined
> in the document.

[ms2] I am not sure if I can follow. My point is that the wording "describes a service and all of the parameters" seems contradicting given the use of the term "all" if you exclude SLAs. Also, Section 5 does not really have a well-defined definition - excluding some examples does not necessarily result in a precise definition. (I agree that "Service" is challenging to define but maybe this could be one reason to find an alternative term to "service model"). 

> In addition, we don't take SLA fine granularity details combining
> commercial terms as service parameters, so I don't see there is
> inconsistency issue, for some misconception on the service model

[ms2] My point is that SLA parameters may be an important part of the customer-service provider agreement of a service and it is surprising to first seeing this mentioned at the end of Section 5.
 
> [ms] I find the wording "it can be used by a human..." confusing. Is
> the assumption that a user would manually type in a service request
> resulting in a valid data model, e.g., by manually typing in NETCONF
> commands? I would rather write something like "the parameters can be
> entered by software or also manually by a human..."
> 
> [Qin]: what we try to convey here is Human can rely on CLI,script or
> other human readable language to define a service, request the service,
> but such parameter will not directly implemented by network element.

[ms2] Sure, but what is the role of a service model defined in YANG e.g. when the human relies on CLI or scripts? To me this wording does not explain this well.
 
> [ms] I am not sure if the IETF should suggest the use of NETCONF on the
> northbound interface of a "service orchestrator", which seems to be the
> scope of this document. Are there pointers to running code that
> actually do that? I would rather prefer a wording such as "The IETF has
> standardized NETCONF and RESTCONF for interactions "on the wire"
> between software components".
> 
> [Qin]: You are right, I think RESCONF is recommended on the northbound
> interface of a service orchestrator, your proposed change looks good.
> Thanks.
> 
> *** Page 7:
> 
> [ms] Why is it not possible that the data models are the same? In
> Figure 3, the "service orchestrator" is actually a "client" (read this
> as "customer") of the "network orchestrators". Inside an operator, the
> "service orchestrator" could be operated by a different organization
> than the "network orchestrator", i.e., there ould even be a business
> relationship. In general, architectures can be recursive. I think this
> statement requires further explanation or rewording.
> 
> [Qin]: The concept to split Orchestrator into service orchestrator and
> network orchestrator, is the service orchestrator is network agnostic
> while network orchestrator is network aware.
> Service model consumed by the service orchestrator could be different
> from the data model consumed by network orchestrator since network
> orchestrator need to decide what network device is selected, which
> protocol is enabled, which technology is used, which network interface
> or port is assigned. The service orchestrator doesn't need to care
> about the underlying technology or what protocol is available.

[ms2] You may want to add that assumption more explicitly to the text and possibly add that this is only one potential architecture. 
 
> [ms] I wonder if it could make sense to distinguish between SLA and
> Service Level Objective (SLO) or Service Level Requirement (SLR). While
> I agree that it is difficult to standardize commercial terms, this IMHO
> partly contradicts the positioning of the term "service model" earlier
> in the document. Maybe the scope of the definition of "service model"
> has to be narrowed down?
> 
> [Qin]: We have clarified what the service is in the section 2 and Our
> service model definition aligns with service definition. Yes, we need
> to distinguish SLA from Service Level Objective/Requirement, but not
> necessary introduce another new term. We have clarified their
> difference in the text you quoted.

[ms2] Well, I think you should comment on SLAs in Section 2 to avoid confusion.

Michael

> [ms] The actual question here is if there could be communality between
> service models for similar services. That problem cannot be solved by
> this document but the text could e.g. explain that for a customer it
> can be confusing if separate service models model related concepts in
> different ways.
> 
> [Qin]: That is a good question, I hope some building blocks specified
> by one service model can be reused in another service model.
> Unfortunately we don't have too many YANG models that are used to model
> service in the IETF. We could cover this in the next version if more
> such service models are needed.
> 
> Thanks
> 
> Michael
> 
> 
> We have submitted a new I-D that discusses the scope and purpose of
> service models within the IETF and describes how a service model can be
> used by a network operator.
> In addition, this draft clarifies the role and position of service
> model in the SDN architecture and Clear several misconception on the
> service model.
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Qin Wu <[email-masked]>
Date: Tue, 12 Jul 2016 02:24:44 +0000

Hiya
-----邮件原件-----
发件人: Scharf, Michael (Nokia - DE) [mailto:[email-masked]] 
发送时间: 2016年7月11日 18:16
收件人: Qin Wu; [email-masked]
主题: RE: New Version Notification for draft-wu-opsawg-service-model-explained-00.txt

Hi Qin,

[Qin]: As we clarified Service Level Agreements (SLAs) have a high degree of overlap 
 with the definition of services present in service models, but we don't want to cover a number of fine-grained details of attributes defined in SLA for the reason given in section 5.
 That's why we add a constraint after " describes a service and all of the parameters " to limit these parameters to abstract level and operator independent way. Maybe we could add
some text to make this more clear.

 
[Qin]: Sure, to avoid confusion with the service defined in the model, as I mentioned above, we use the different term for these Quality related parameters.

> other human readable language to define a service, request the 
> service, but such parameter will not directly implemented by network element.

[Qin]: why we should tie service model definition with YANG, the service model is just a service template, you can use human readable language to express it or you
Can use machine readable language to express it, it doesn't matter. Therefore, in some cases, you just need fill the service parameters in some kind of form and submit this form
to the server for further parsing and interpretation.
 
> [ms] I am not sure if the IETF should suggest the use of NETCONF on 
> the northbound interface of a "service orchestrator", which seems to 
> be the scope of this document. Are there pointers to running code that 
> actually do that? I would rather prefer a wording such as "The IETF 
> has standardized NETCONF and RESTCONF for interactions "on the wire"

[Qin]: We give two optional architecture in the figure 2 and figure 3, let us know if there is any potential architecture we are missing.
> Service Level Objective (SLO) or Service Level Requirement (SLR). 
> While I agree that it is difficult to standardize commercial terms, 
> this IMHO partly contradicts the positioning of the term "service 
> model" earlier in the document. Maybe the scope of the definition of "service model"
> has to be narrowed down?
> 

[Qin]: Done, see above.

Michael

> Unfortunately we don't have too many YANG models that are used to 
> model service in the IETF. We could cover this in the next version if 
> more such service models are needed.
> 
> Thanks
> 
> Michael
> 
> 
> service models within the IETF and describes how a service model can 
> be used by a network operator.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 13 Jul 2016 12:13:07 +0100

Hi Michael and Qin,

Thanks for the constructive discussions.

In line...

> >    Service Model:  A service model is a specific type of data model.
> > 
> >   It describes a service and all of the parameters of the service in a
> [ms2] I am not sure if I can follow. My point is that the wording "describes a
> service and all of the parameters" seems contradicting given the use of the term
> "all" if you exclude SLAs. Also, Section 5 does not really have a well-defined
> definition - excluding some examples does not necessarily result in a preciser
> definition. (I agree that "Service" is challenging to define but maybe this could be
> one reason to find an alternative term to "service model").
> 
>  with the definition of services present in service models, but we don't want to
> cover a number of fine-grained details of attributes defined in SLA for the reason
> given in section 5.
>  That's why we add a constraint after " describes a service and all of the
> parameters " to limit these parameters to abstract level and operator
> independent way. Maybe we could add

I think this is a language issue.
I tend to agree with Michel that "all" is a risky word.
Clearly we (well, OK, I wrote those words) meant "all of the parameters that describe the part of the service we are describing". We did not mean *all* and that should be clear from the discussions of augmentations that operators might make to cover their own additions to the base service.

What we are trying to do is:
- define a core, base service that all operators agree on
- list *all* of the parameters of that core, base service
- list all of the settings of those parameters necessary to define
    that core, base service.

We can make that clearer.

> [ms2] My point is that SLA parameters may be an important part of the customer-
> service provider agreement of a service and it is surprising to first seeing this
> mentioned at the end of Section 5.
> 
> [Qin]: Sure, to avoid confusion with the service defined in the model, as I
> mentioned above, we use the different term for these Quality related
> parameters.

I agree with both of you here.
Without doubt, SLA will form an important part of the commercial agreement between operator and customer.
However, with the exception of some high-level parameters of the service (such as bandwidth) we find that SLA parameters vary widely between operators.

I'm aware that a number of organisations (most notably TMF) have spent a lot of time parameterising and generalising SLAs. This may be something we can try to do as well, but in my opinion it is both hard and an extension to the service model work we are doing.

> [ms2] Sure, but what is the role of a service model defined in YANG e.g. when
> the human relies on CLI or scripts? To me this wording does not explain this well.
> 
> [Qin]: why we should tie service model definition with YANG, the service model is
> just a service template, you can use human readable language to express it or
> you
> Can use machine readable language to express it, it doesn't matter. Therefore, in
> some cases, you just need fill the service parameters in some kind of form and
> submit this form to the server for further parsing and interpretation.

I think we might go for "it can be used by a human via a user interface such as a GUI, web form, or CLI" to cover the meaning.

What we are really doing is distinguishing between human control (by whatever means) and application (i.e., autonomous software) control.

> [ms2] You may want to add that assumption more explicitly to the text and
> possibly add that this is only one potential architecture.
> 
> [Qin]: We give two optional architecture in the figure 2 and figure 3, let us know if
> there is any potential architecture we are missing.

Additionally, we tried to capture this in Section 5.

> > more such service models are needed.

Agree with both of you.
We're still playing with our first few service models so it is hard to guess how this will pan out. But I suspect that the "building block" approach will be what we end up with.

Best,
Adrian

---

From: Benoit Claise <[email-masked]>
Date: Tue, 19 Jul 2016 10:18:02 +0200

Qin,

Explaining the difference between a service and network element YANG 
modules is the objective of 
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/

Abstract

    The YANG [RFC6020] data modeling language is currently being
    considered for a wide variety of applications throughout the
    networking industry at large.  Many standards-defining organizations
    (SDOs), open source software projects, vendors and users are using
    YANG to develop and publish YANG modules of configuration, state data
    and operations for a wide variety of applications.  At the same time,
    there is currently no well-known terminology to categorize various
    types of YANG modules.

    A consistent terminology would help with the categorization of YANG
    modules, assist in the analysis the YANG data modeling efforts in the
    IETF and other organizations, and bring clarity to the YANG-related
    discussions between the different groups.

    This document describes a set of concepts and associated terms to
    support consistent classification of YANG modules.

Regards, Benoit

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 19 Jul 2016 09:27:48 +0100

Benoit,
 
I think that you mean to say "is *an* objective of". That is, the draft you point at has a far wider scope and purpose.
 
No problem with that.
 
Doing our work in L3SM we repeatedly encountered confusion about what a service model is and where it fits in the "hierarchy". So we wrote some text.
 
Looking at our draft and Figure 1 in the yang-model-classification there is not complete coherence.
 
Which way would like to go forward?
Roll our text into yang-model-classification?
Push forward separately?
 
Adrian
 
From: OPSAWG [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: 19 July 2016 09:18
To: Qin Wu; [email-masked]
Subject: Re: [OPSAWG] New Version Notification for draft-wu-opsawg-service-model-explained-00.txt
 
Qin,

Explaining the difference between a service and network element YANG modules is the objective of https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/
Abstract

 

 
Regards!
-Qin
-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2016年7月5日 19:55
收件人: Liushucheng (Will); Adrian Farrel; Liushucheng (Will); Qin Wu
主题: New Version Notification for draft-wu-opsawg-service-model-explained-00.txt

Abstract:

 

The IETF Secretariat