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