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

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 8 Sep 2016 20:30:25 +0100

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