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:[email protected]] On Behalf Of Qin Wu > Sent: Tuesday, July 05, 2016 2:02 PM > To: [email protected] > 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 > -----邮件原件----- > 发件人: [email protected] [mailto:[email protected]] > 发送时间: 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 > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
