Hi Michael, all,
Apologies for dropping this thread.
I am making changes to the -03 revision and we'll post it soon.
More comments in line.
Cheers,
Adrian
> > > 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 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").
> >
> > [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.
>
> 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.
So the text has changed a bit with the split of the definition to separate
"customer service model" and "service delivery model" under the general
definition of "service model".
What I have done is...
- In the general text I deleted "all" to give...
"It describes a service and the parameters of the service in a portable way."
- In the definition of "customer service model" I gave more specifics...
A customer
service model is expressed as a core set of parameters that are
common across network operators: additional features that are
specific to the offerings of individual network operators would
be defined in extensions or augmentations of the model.
- In the definition of "service delivery model" I gave more specifics...
A service delivery model is expressed as a core set of parameters
that are common across a network type and technology: additional
features that are specific to the configuration of individual
vendor equipment or proprietary protocols would be defined in
extensions or augmentations of the 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.
> >
> > [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.
What I have done here is primarily a forward pointer to Section 5 from Section
2. I want to draw attention but not write stuff twice.
> > > [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.
> >
> > [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.
I made this change.
> > > *** 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 human 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.
I made this change.
> > > *** 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.
> >
> > [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.
I made no further change for this.
> > > *** 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.
> >
> > [Qin]: Done, see above.
Yes, as above.
> > > *** 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.
>
> 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.
I haven't added any text for this at this stage.
I'm not sure how or whether this would even be visible to a customer. It may be
implementation dependent according to how the information is collected from the
customer and populated into the customer service model.
Anyway, while I tend to agree with you from an architectural view point, I
don't think this is the document to use to tell people how to build models.
Thanks once again,
Adrian
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
