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

["Scharf, Michael (Nokia - DE)" <[e-mail]>]

Hi Qin,

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

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

[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
> Understanding is clarified in the different section, this is
> intentional.

[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.
 
> *** 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".
> 
> [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:
> 
>    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.
> 
> [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. 
 
> *** 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?
> 
> [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



> *** 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.
> 
> [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:[e-mail]] On Behalf Of Qin Wu
> Sent: Tuesday, July 05, 2016 2:02 PM
> To: [e-mail]
> 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.
> 
> Your questions and comments are welcome.
> 
> Regards!
> -Qin
> -----邮件原件-----
> 发件人: [e-mail] [mailto:[e-mail]]
> 发送时间: 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
> 
> _______________________________________________
> OPSAWG mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsawg