Re: [RTG-DIR] RtgDir Review: draft-ietf-opsawg-service-model-explained

["Adrian Farrel" <[e-mail]>]

Thanks David,

> Abstract: "... used within the IETF...". Wouldn't the document serve better to
> describe how the models could/are used by the industry including within SDN?
> Several of these models are used by other SDOs for their work in e.g., providing
> network architecture, equipment requirements, orchestration, OAM and
> management to support and provide the service. I would think that the matter
> of how these are used by the IETF would be much to narrow a view.

The IETF does not, I think, strive to speak for other SDOs. While it can speak for a slice of the industry, it is only that slice that participates at the IETF. So what we do best is describe what we have built.

Of course, if other SDOs like what we have done, they can reference it.

> Intro para 3, last sentences - This text dates itself. It would suffice to note that
> the models may be used in these environments regardless of the time frame. 
> (e.g., drop “eventually)

Hmmm, you reviewed -03? So this would be the last sentence of para 4.
You are right that this could become dated.
Don't mind making that change.

> Intro para 5 last sentence - customer - Provider Interface needs a forward
> reference or brief definition. 


Perhaps we should say "through the interface between the customer and the provider."  There is nothing clever here. Just that there is an interface.

> Intro para 6. - "described to" or "subscribed to"? 


We meant "described to". Is there a problem with describing a service to a customer?

> Intro para 6 - does it describe the service or the attributes of the service. I'm not sure
> a service model describes the service operation.  Add the words "attributes of the" 


You added the word "operation".
How would you describe a service except through the attributes of that service. But "describing the attributes" conveys (to me) something less than describing the service.

> Sec 1, para 4 - “... within the IETF...” but the document also discusses the MEF. Need
> to make statement more general. 


Weeeeeell, two brief paragraphs in a 22 page document hardly makes MEF the focus of this work. I think the paragraph you quote from accurately describes this document.

> Definition of Network Operator - change to read "... other network services."
> Not sure other non-network services are intended. 


The text reads...
|   Network Operator:  This term is used to refer to the company that
|     owns and operates one or more networks that provide Internet
|     connectivity services and/or other services.

Not sure where you found "other non-network services. 

> Definition of Customer: suggest change “purchases” to “subscribes”

The principal two definitions of "subscribe" are:

| to pledge, as by signing an agreement, to give or pay money as a
| contribution, gift, or investment 

...and...

| to give or pay money in fulfillment of such a pledge. 

That'll be "purchase" :-)

> Definition of Customer: Excludes residential customer... why?

I read and re-read. I don't find that exclusion.

But it is reasonable to infer that residential customers are peripheral to the discussion. The type of service purchased by a residential customer is very simple, but is still covered by the discussion as it is only a scaled down version of some types of serviced purchased by commercial organisations.

> Definition of Service: - Would help to give titles of RFCs, but may not be
> aligned with conventions.

Hmmm, no, I think the way this is presented is the normal IETF way.

> Definition of Data Model: Refers to information model and relationships
> between managed objects.  Should it be just objects?

The definition of Data Model quoted from RFC 3444 only has meaning when presented with the definition of Information Model. And, of course, we can't change the quoted text.

> Definition of Service model - in IETF it's a data model. In other groups? E.g., ITU? It
> could be an information model.

You may be right. I don't know. Personally, I might be interested in finding out, but surely it is not the job of the IETF to attempt to interpret and document other SDO's views?

> Definition of Customer Service Model: Not sure example of order fulfillment
> system illustrates a human.  Is there a better example of a human consumer?

I don't see the problem. An order fulfillment system in network management often (usually) has a human interface so that actions can be confirmed. Do you have any suggestions?

> Definition of Service model - "... a portable way". Portable way? or do
> you mean more agnostic to deployment architecture and equipment?

Yes, that is the usual meaning. We can spell it out.

> Last para just before section 3. - while a service model as a whole may not be
> intended to be sent to network devices, parts of it may be sent to network
> equipment. This could be clarified.

I think you are saying that one model may contain modules used in other models.

> Sec 3, 2nd para - “... choice for whoever specifies the model.” And the next
> sentence notes the IETF. Is the choice that of the organization where the
> model is specified, the individuals specifying the model or some combination
> of both?

The "whoever" is individuals or SDOs. However, individuals participating in the IETF use the mechanisms adopted by the IETF.

> Sec 3, para 1&2 - these two paragraphs don’t add to the discussion and
> distract from para 3 where the actual discussion starts.

Unless there is a big problem here, we like the text.

> Sec 3, para 3, last sentence - “... direct human interaction...”. This crosses
> from implementation to business process and should be noted. Add a
> sentence to the effect of “Where direct human interaction comes into
> play, interface interactions may become realized via business practices
> and must account for some margin of error, thus raising the priority for
> automated, deterministic interfaces.”

That works.

> Figure 1 -move figure to the definition of customer service model

Added forward reference.

> Sec 3, para 8, last sentence - distinction of modules and models. Good
> description of modules, but needs to be contrasted vs models.

The description of "module" is provided by using the term "model". Are you proposing we should also add a definition of "model" using the term "module"? Wouldn't that just be saying the same thing only backwards.

> Sec 3, para 7 –“ The practicality…”  these last two paragraphs highlight a 
> debate and the different points of view. This is different from the “big
> picture” usage description in the paragraphs above. Subsections (e.g., 
> “The Big Picture” and “Practically Speaking”) would help call out the
> transition in thinking & flow.

OK

> Sec 4, heading or para 1, 1st sentence - “SDN” has been spelled out
> previously in the introduction but given the elementary level of
> explanation here, e.g., “controller”, it may be worth spelling it out again.

OK

> Sec 4, para 2, 1st sentence - remove the “But” or clarify what the statement
> is contradicting or juxtaposing.

OK

> Sec 4, para 2, 2nd sentence “ That is,…” - This statement should be clarified. 
> Inherently the technology available to deliver a service will influence the
> functions that a customer can request. E.g., an Ethernet connectivity service
> will be defined in terms of MAC addresses, etc. I think the point trying to be 
> made here is that the underlying technology specific details should not, or to
> the lowest extent possible, be reflected in customer service requests. E.g., 
> one should not have to specify switch or router ids, IP addresses or MAC
> addresses for a TV service. 
See section 7 of the document

I think you are mistaken. A customer can request *anything*. However, the service provider may not be able to deliver it :-)

But I see what you mean about this text.

OLD
   But a customer's service request is (or should be) technology-
   agnostic.  That is, the technology that the network operator has
   available to deliver the service should not influence the behavior
   and functions that a customer requests.  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.
NEW
   A customer's service request is (or should be) technology-
   agnostic.  That is, a customer is unware of the technology that the
   network operator has available to deliver the service and so the 
   customer does not make requests specific to the underlying 
   technology, but is limited to making requests specific to the
   service that is to be delivered.  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.
END

> Sec 4, para 2 & 3 - wouldn’t this point about a Service/Network split be true
> outside of the SDN context as well? Why would this be limited to SDN?

The discussion is limited to SDN simply because we're inside Section 4 ("Service Models in an SDN Context").

> Sec 4, Figure 3 - could the figure show an orchestrator interacting
> directly to a network element? 

That is possible, but surely a distraction and a dangerous diversion into debates about the architecture of an SDN system.
Apart from completeness, does it add anything to the document?

> Sec 5, bullet 1 - In the terminology section, “Service” is defined as a connectivity
> service. For purposes of this document then it should not be confused with
> higher layer services. The “customer” for this definition *is* aware of technology
> specific parameters and constraints of the connectivity service they are subscribing
> to. The cause of the confusion, and this is an age old problem, is that “service” is a
> recursive term. That is, a consumer/client of one level of service (e.g., Ethernet
> connectivity) is the provider/server of another (e.g., Internet access) for higher
> layer use (e.g., TV service) 
Modeling methods (G.805) have been established to
> describe the client/server relationship.

I agree with a lot of this. But you need to be careful talking about "technology of the service". Yes, the service is technology-specific (e.g., give me an Ethernet connection from here to there"), but, no, the service is technology-agnostic (don't care if this is native Ethernet, EoMPLS, EoATM, or whatever, and don't care whether OSPF, ISIS, BGP, or widgetFlow is used to set up the service).

That said, not sure what you are asking for.

> Sec 5, bullet 2 - “completely” -> might want to tone this down a bit, to 
> accommodate exceptions noted elsewhere in the document. While kept
> to a minimum, network operation is not *completely* out of scope when
> discussing service between a customer and network operator. E.g., Part
> of a service could be routing of the connect to avoid geopolitical borders.
> (Noted on the very next page) another example is, Fault notification and
> protection mechanisms may be discussed. 
The statement here seems to
> contradict the definition of Customer Service Model in the terminology
> section where it states that “Except where specific technology details
> (such as encapsulations, or mechanisms applied on access links) are directly
> pertinent to the customer, customer service models are technology agnostic
> so that the customer does not have influence over or knowledge of how the
> network operator engineers the service.” 
Perhaps use “normally” vs
> “completely”

OK2

> Sec 5, bullet 2 - providing detail about how the service is offered could
> actually be considered a security vulnerability.

OK

> Sec 5, bullet 4 - give some examples of “commercial terms”.

OK

> Sec 5, bullet 5 - give an example of the “fine grained details”

We already have "how services are allowed to vary, by how much, and how often"

> Sec 6.2 list of drafts - will these works in progress be stable or
> final before publication?

I suspect they will still be works in progress, but who can tell the wonders of the IETF process.

> Sec 6.4, para 2,3rd sentence - the statement on it being impractical to
> fit IETF models into MEF models seems a bit broad. Has anyone looked
> into this? 

Oh yes. :-) Some energy was expended looking at LSO.

Well, we have "may be impractical" so the door is open.

Thanks again,
Adrian