Hey Luis,
As we are updating the draft for last call comment, here are responses to your
comments.
> *Specific comments*
>
> - There are several sentences along the document trying to define the scope of
> service model in the context of IETF. These are: (1) in Terms and Concepts,
for
> Service, "... A service in the context of this document (sometimes called a
> Network Service) is some form of connectivity between customer sites and the
> Internet, or between customer sites across the network operator's network and
> across the Internet"; (2) section 5, first bullet, "The services we are
discussing are
> services provided by network operators to customers ... network operators may
> offer value-added services as well as network connection services to their
> customers."; (3) section 6.4, "The IETF's work on service models is typically
> smaller offering a simple, self-contained service YANG module".
> Since in the abstract it is stated that "This document briefly sets out the
scope of
> and purpose of an IETF service model", probably the best would be to include
at
> the very beginning a clear sentence with such definition, in order to focus
the
> reader.
OK. That is easy to add.
In summary, a service model is a formal representation of the data
elements
that describe a network service as that service is described to or
requested
by a customer of a network operator. Details included in the service
model
include a description of the service as experienced by the customer, but
not
features of how that service is delivered or realized by the service
provider.
> - In abstract: "... details of how network protocols and devices are
engineered to
> deliver a service are captured in other models that are not exposed through
the
> Customer-Provider Interface" <-- Thinking on recursiveness, the Customer-
> Provide Interface can require low-level details or models. In other words,
when a
> Network Operator is Customer of another Network Operator, what kind of
> interface would you consider for that relationship?
For me, recursion does not add detail. So, a network operator that engages with
another network operator as a customer could do so exactly using the service
model.
If the relationship is internal to a commercial organisation then it is possible
that the interface will be more transparent.
It is also true that if the recursion happens lower down (e.g., at the service
delivery interface) then more details are exposed.
I don't believe that any of this has direct bearing on this document, but I can
see that there may be space for more architectural debate about how SDN systems
are constructed. MEF, ETSI, and TMF seem to be having this sort of discussion.
> - Figure 2: in contrast with Figure 3, where would be positioned here the
Service
> Delivery models? Should it be assumed a collapse of functionality in the
> Orchestrator of Fig. 2 including both Service and Network Orchestrator? Would
> be those models internal? Maybe it could be convenient to reflect also in Fig.
2
> both Service Delivery and Network Configuration models, for consistency.
I think that is exactly the point. The "traditional" SDN approach shown in
Figure 2 makes it hard to place these different models in context, so we
introduce an extended view in Figure 3.
> - In section 4, below Fig. 2: "This means that the service request must be
mapped
> to the orchestrator's view, and this mapping may include a choice of which
> networks and technologies to use depending on which service features have
> been requested." < -- Such mapping is performed by the Orchestrator itself,
> right? So maybe the sentence can be rephrased (e.g., ... the service request
must
> be mapped by the orchestrator ...).
Yeah. OK.
> - Figure 3. The Customer Service model in segment (a) would be probably
> something else than a connectivity/transport service, even though parts of
such
> service request are out of scope of IETF. I mean, e.g. a Network Service
> Descriptor in NFV. So the Service Orchestrator purpose can be broader than
what
> is the scope of IETF. This can be maybe clarified.
It is true that there is a broader architectural picture sitting behind this.
One that includes the NFV features and might be modeled after the ETSI NFV work.
As you note, those features are out of scope of the IETF. And this document is
quite clear that its scope is to discuss the IETF's use of service models.
As I said above, I can see that there may be space for a document discussing a
wider architecture. That would probably not be an IETF document, but it could go
to the NFVRG.
> - Figure 3. As part of the figure or in the text description, it would be nice
to have
> hints about how recursiveness or east/west relationships (for multiple
> administrative domains) are mapped to model categories here.
The L3SM work talks a little about multi-operator service delivery, but this is
handled in a relatively simplistic way because the interface between operators
is a complex commercial relationship and the involvement of customers in that
relationship is beyond complex.
I think we can talk about a multi-network solution where those networks are all
under the control of one service provider. And I think this document does that
OK (although I'd be happy to hear specific suggestions for improvement) by the
text you suggested to be modified, above.
The orchestrator must map the service
request to its view, and this mapping may include a choice of which
networks and technologies to use depending on which service features
have been requested.
This, of course, does not speak to an east/west relationship, but to a
coordinated north/south relationship.
> - Section 5, bullets about Commercial terms and SLAs. Maybe it can be
> convenient to explicitly say that they are out of the scope. It is mentioned
that is
> hard to standardize this, but no assertive indication if both are out of the
scope.
Yes. Good idea.
Added text to both bullets.
> - Section 6: "... interface between the Service Orchestrator or OSS/BSS ...".
Does
> it apply as well to Fig. 3? If so, maybe it would be nice also to include in
Fig. 3 for
> consistency.
This is already shown in Figure 3. Perhaps something is not clear in that figure
do we will add a second label (b) on the communication between OSS/BSS and
Network Orchestrator.
> - Figure 4. I think that the figure it is not clear at all. There is a mix of
functional
> elements (e.g. Service Orchestrator, OSS/BSS) with models. Probably a more
> homogeneous figure could be better.
Figure 4 comes from RFC 8199 (with only minor modifications) and is not in scope
for us to change.
Probably gets clearer with several readings of RFC 8199 which is a normative
reference.
> - Section 6.2: it would be nice to make clear what of the sample models can be
> categorized as Service Delivery model, and what of them can be categorized as
> network Element (or device) models.
:-)
No, I don't plan to walk into that minefield!
Well, not in this document that is not actually about either of those categories
of model. In fact, the reason why we grouped all of these models into one
section was because we didn't see rapid convergence (even among the authors of
those documents) and didn't want to get distracted from the purpose of this
document.
> - MEF work is mentioned in section 6.4. I think it would be necessary to
> cover/describe some other initiatives like the one of ETSI NFV with respect to
> Network Service Descriptors.
In earlier revisions of this draft we had a lot more text about the MEF
architecture and made attempts to compare and draw some parallels. But over time
we discovered that that wasn't so easy so we collapsed the section into
something quite simple that gives the reference and states that the approaches
fill a similar space but are different.
We could easily include a similar section on ETSI NFV, but:
- Someone else would have to write it as I'm not familiar with that work
- I am very cautious about attempting to reach completeness with regard to all
other approaches. Fundamentally, we are writing about IETF service models.
> - Section 6.4: "This does not invalidate either approach, but only observes
that
> they are different." More than different, MEF as described here is broader in
> scope. Maybe the sentence can be rephrased in this sense.
You can't be "more than different". The text already summarises the breadth of
scope of the MEF work and says that "the IETF's work on service models is
typically smaller offering a simple, self-contained service YANG module".
I think that this cover the point you wanted made and that we don't want to get
into any further comparison.
> - Section 7.2: it is not clear if policies are considered or not as part of
the scope of
> the customer service models. Difficulties on identifying common policies for
the
> operators are mentioned. But similar situation is also mentioned in section
7.3
> with the result of identifying common parametrization after working on it. So
> maybe it can be mentioned that such kind of work is required, instead of not
> covering policies at all.
Right. Like the bullets in Section 5 that you mentioned, this will be clarified.
> - Section 8: the interface between Service Orchestrator and Network
> Orchestrator can be also external, and then security measures should be
applied.
Agreed.
> - Section 9, last paragraph: Reporting is essential for SLAs (monitoring) and
> accounting / billing (resource usage). But it seems (as mentioned before in
the
> document) that commercial terms and SLAs are not part of the customer service
> models. Then, if reporting is included as part of the customer service model,
as
> suggested by this paragraph, it is apparently inconsistent with the fact of
not
> having the ways of requesting SLAs and billing, but having the necessary
> information for that being reported (in other words, how can I express what
> information is of interest for me if I cannot express SLAs or commercial
terms?).
You're right. Monitoring information is on a similar level to SLA description
(although personally I've never quite trusted the service provider's reports of
performance as evidence that they are meeting the SLA :-).
This text needs to be treated the same way as the bullet you pointed to in
section 5, and we'll do that.
> *Editorial comments*
>
> - In abstract: RFC 8049 should be included between brackets.
Well, actually, no. There should be no citations in an Abstract because that
piece of text must be able to stand alone.
> - In section 2, Terms and concepts: for Network Operator -> it is mentioned
that
> "The term is also used to refer to an individual who performs operations and
> management on those networks." <-- Since it is not used with this meaning in
the
> text, I would remove that clarification to avoid ambiguity.
Could catch. And we previously fixed the ambiguity by saying "human operator"
when we needed to.
> - In section 2, Terms and concepts: for Data Model -> the following sentence
> seems to be editorial, maybe it can be removed: "so it may be helpful to quote
> some text to give context within this document."
Yup.
> - Section 6.2 < -- Probably it would be better to separate Service Delivery
from
> Network Element models in different sections, with sample models referred
As above. The authors really don't want to go there.
> - Same section. Network Element model is introduced here for 1st time. In
figure
> 3 it is referred as device configuration model. It would be better to have an
> homogeneous naming.
Well, "Network Element model" shows in 6.1 and comes from RFC 8199.
"Device models" comes from draft-ietf-l2sm-l2vpn-service-model.
So we're stuck with both terms, but I've added text to help with the terminology
mapping.
> - Section 9, first sentence: "... related to network management." -> "...
related to
> network management and control."
OK
Many thanks for your really helpful review.
Adrian
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
