Re: [OPSAWG] WG LC: draft-ietf-opsawg-model-automation-framework-03

[Adrian Farrel <[e-mail]>]

Hi,

 

I've reviewed this document in working group last call and support its

publication. I found the Appendix particularly helpful.

 

I have some minor thoughts that the authors may want to consider as the

document moves forward.

 

Thanks,

Adrian

 

==

 

idits says that draft-ietf-dots-data-channel has been published as

RFC 8783

 

---

 

The Abstract is a little longer than the recommended maximum length of

20 lines. Maybe reduce the first paragraph to:

 

   Data models provide a programmatic approach to represent services and

   networks.  They can be used to derive configuration information for 

   network and service components, and state information that will be

   monitored and tracked.  Data models can be used during the service

   and network management life cycle, such as service instantiation,

   provisioning, optimization, monitoring, diagnostic, and assurance. 

   Data models are also instrumental in the automation of network

   management, and they can provide closed-loop control for adaptive and

   deterministic service creation, delivery, and maintenance.

 

---

 

Section 1

 

s/requirements and order/requirements and orders,/

s/operating in a silo/operate in a silo/

s/providers'savoir-faire/providers' savoir-faire,/

s/first tentative/first tentative attempt/

 

   YANG [RFC7950] module developers have taken both top-down and bottom-

   up approaches to develop modules [RFC8199] and to establish a mapping

   between a network technology and customer requirements on the top or

   abstracting common construct from various network technologies on the

   bottom.

s/construct/constructs/

s/on the/at the/  (twice)

 

---

 

Section 1

 

   other Standards Developing

   Organizations (SDOs) (e.g., MEF)

 

It's not clear to me why you cite MEF as an example of another SDO. I 

don't think you mean to be judgemental (i.e., saying that you would have

expected MEF to have done this) so it is probably best to leave that out

 

---

 

Section 2

 

I don't object to your definitions of Network Model and Device Model, 

but I wondered why you chose not to use or reference Network 

Configuration Model and Device Configuration Model from RFC 8309.

 

---

 

Section 3.1

 

   Figure 1 depicts the example of a VoIP service provider that relies

   upon connectivity services offered by a Network Operator.

 

But Figure 1 actually uses the terms "Provider" and "SP". It might be

helpful to clarify in the text (the paragraph before the figure) whether

the two "SP sites" and the "Provider" are all under the control of the 

"Network Operator" while the "Internet" is of broader scope.

 

---

 

Section 3.3

 

   To operate a service, Device Models derived from Service Models and/

   or Network Models can be used to provision each involved network

   function/device with the proper configuration information, and

   operate the network based on service requirements as described in the

   Service Model(s) and local operational guidelines.

 

It seems to me that you are describing a top-down approach to the 

construction of data models. But, in practice, isn't it the case that

Device Models are derived from the nature of the devices being managed

in a bottom-up approach. Thus there is a challenge of "meeting in the

middle" as the top-down service models meet the bottom-up device models.

 

Perhaps this issue is resolved by...

 

   To operate a service, the settings of the parameters in the Device

   Models are derived from Service Models and/or Network Models and are

   used to provision each involved network function/device...

 

---

 

Section 4

 

s/led to the/lead to the/

 

---

 

Can I be so bold as to suggest some changes to Figure 4?

Changes include:

- Minor updates to spacing to make arrows clearer

- Arrow end where path joins E2E Service Assurance to E2E Service

  Diagnostics

- Remove path cross-over in paths from Specific Service Assurance

- Arrow end where path joins Specific Service Assurance to Specific

  Service Optimization

- Dotted lines to separate the different levels and moved the names of

  the levels inside the boundaries.

 

                    +------------------+

  ................. |                  |

     Service level  |                  |

                    V                  |

      E2E          E2E                E2E              E2E

    Service --> Service --------->  Service   -----> Service -----+

    Exposure    Creation     ^    Optimization   ^  Diagnosis     |

               /Modification |                   |                |

                    |        |Diff               |                V

     Multi-layer    |        |         E2E       |               E2E

     Multi-domain   |        |       Service     |            Service

     Service Mapping|        +------ Assurance --+         Decommission

                    |                     ^

   ................ |<-----------------+  |

     Network level  |                  |  +-------+

                    V                  |          |

                Specific           Specific       |

                Service  -------->  Service <--+  |

                Creation     ^    Optimization |  |

               /Modification |                 |  |

                    |        |Diff             |  |

                    |        |      Specific --+  |

           Service  |        |      Service       |

        Decomposing |        +----- Assurance ----+

                    |                  ^

   ................ |                  |    Aggregation

     Device level   |                  +------------+

                    V                               |

   Service       Intent                             |

   Fullfillment  Config  -----> Config  -----> Performance ---> Fault

                 Provision      Validate       Monitoring     Diagnostic

 

---

 

Section 4.1.2

 

   Upon receiving a service request, the service orchestrator/management

   system should first verify whether the service requirements in the

   service request can be met (i.e., whether there is sufficient

   resources that can be allocated with the requested guarantees).

 

It may sound "obvious" but I think there is an authentication and 

authorisation step first. Is the user who they say they are? Are they

allowed to request the service they are asking for?

 

It would be worth mentioning this in Section 6 as well.

 

---

 

Section 4.1.3

 

s/feed/fed/

 

---

 

Section 4.3

 

   in Traffic Engineering Architecture and Signaling

   (TEAS) VN model [I-D.ietf-teas-actn-vn-yang]

 

I think you should use the name of the model as given in the referenced

document. 

 

---

 

Section 5.1

 

You use L3NM without expansion or a reference

 

I think it might be helpful to know where the model in [I-D.ogondio-

opsawg-uni-topology] fits in the context of Figure 5.

 

---

 

Figure 5

 

OLD

            |              +-----V- -------+                  |

NEW

            |              +-----V---------+                  |

 

OLD

            +-------------++----------  ++--------------------+

NEW

            +-------------++------------++--------------------+

 

OLD

            +--+--+      +++---+      --+---+           +--+--+

NEW

            +--+--+      +-+---+      +-+---+           +--+--+

 

OLD

            | CE1 -------| PE1 |      | PE2 |  ---------+ CE2 |

NEW

            | CE1 +------+ PE1 |      | PE2 +-----------+ CE2 |

 

---

 

Figure 6

 

OLD

              +-------------++----------  ++--------------------+

NEW

              +-------------++------------++--------------------+

 

OLD

              +--+--+      +++---+      --+---+           +--+--+

NEW

              +--+--+      +-+---+      +-+---+           +--+--+

 

OLD

              | CE1 |------| PE1 |      | PE2 |  ---------+ CE2 |

NEW

              | CE1 +------+ PE1 |      | PE2 +-----------+ CE2 |

 

---

 

Figure 7

 

OLD

            +----------------------V--------------------+----+

NEW

            +----------------------V--------------------+-----+

 

OLD

            | CE1 |------| PE1 |        | PE2 |---------+ CE2 |

NEW

            | CE1 +------+ PE1 |        | PE2 +---------+ CE2 |

 

---

 

Appendix A

 

   It is not the intent of this appendix to provide an inventory of

   tools and mechanisms used in specific network and service management

   domains; such inventory can be found in documents such as [RFC7276].

 

It is OK to say what this appendix is not, but it might be useful to 

also say what it is. Also to note that the appendix is non-normative.

 

From: OPSAWG <[e-mail]> On Behalf Of Tianran Zhou
Sent: 01 June 2020 03:25
To: [e-mail]
Cc: OpsAWG-Chairs <[e-mail]>
Subject: [OPSAWG] WG LC: draft-ietf-opsawg-model-automation-framework-03

 

Hi WG,

 

The authors requested the WG last call. And we think this draft is mature
and stable. We start a two week last call for this draft.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-model-automation-framewor
k/

 

Please send your comments stating whether you believe the document is ready
for publication. 

If not, please explain why not and provide comments to improve this
document.

 

Thanks,

Tianran and Joe