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

[[e-mail]]

Hi Adrian,

Thank you for the review.

I integrated almost all your suggestions. FWIW, an updated version is available at: https://github.com/boucadair/draft-ietf-opsawg-model-automation-framework.

Please see inline for more details.

Cheers,
Med

De : OPSAWG [mailto:[e-mail]] De la part de Adrian Farrel
Envoyé : jeudi 11 juin 2020 17:37
À : [e-mail]
Cc : 'OpsAWG-Chairs'
Objet : Re: [OPSAWG] WG LC: draft-ietf-opsawg-model-automation-framework-03

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

[Med] Fixed.
---

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.

[Med] Deal. Thanks.
---

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/

[Med] Fixed.

   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)

[Med] Fixed.
---

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

[Med] The intent was to give an example. Deleted it to avoid misinterpretations.
---

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.

[Med] There is no "formal" definition in 8309, if you will. Updated the text to say that these terms refer to Network Configuration Model and Device Configuration Model discussed in 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.

[Med] Updated the text as follows:

NEW:
   Figure 1 depicts the example of a VoIP service that relies upon
   connectivity services offered by a Network Operator.  In this
   example, the VoIP service is offered to the Network Operator's
   customers by Service Provider (SP1).  In order to provide global VoIP
   reachability, SP1 service site interconnects with other Service
   Providers service sites typically by interconnecting Session Border
   Elements (SBEs) and Data Border Elements (DBEs) [RFC5486][RFC6406].
   For other VoIP destinations, sessions are forwarded over Internet.
   These connectivity services can be captured in a YANG Service Module
   that reflects the service attributes that are shown in Figure 2.

---

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...

[Med] That is the intent. Thanks.
---

Section 4

s/led to the/lead to the/

[Med] Fixed. Thanks.
---

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

[Med] I like the changes. Much appreciated!
---

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?

[Med] Updated as follows:

NEW:

   Upon receiving a service request, and assuming that appropriate

   authentication and authorization checks have been made, the service

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

[Med] We do have some text about access control. We can add more text if you think this is not covered.

---

Section 4.1.3

s/feed/fed/

[Med] OK
---

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.

[Med] OK.
---

Section 5.1

You use L3NM without expansion or a reference
[Med] This one was already fixed as per a comment from Oscar. We also added NEW text for L2xM.

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.

[Med] Will be added.

---

Figure 5

OLD
            |              +-----V- -------+                  |
NEW
            |              +-----V---------+                  |

OLD
            +-------------++----------  ++--------------------+
NEW
            +-------------++------------++--------------------+

OLD
            +--+--+      +++---+      --+---+           +--+--+
NEW
            +--+--+      +-+---+      +-+---+           +--+--+

OLD
            | CE1 -------| PE1 |      | PE2 |  ---------+ CE2 |
NEW
            | CE1 +------+ PE1 |      | PE2 +-----------+ CE2 |

[Med] Fixed.
---

Figure 6

OLD
              +-------------++----------  ++--------------------+
NEW
              +-------------++------------++--------------------+

OLD
              +--+--+      +++---+      --+---+           +--+--+
NEW
              +--+--+      +-+---+      +-+---+           +--+--+

OLD
              | CE1 |------| PE1 |      | PE2 |  ---------+ CE2 |
NEW
              | CE1 +------+ PE1 |      | PE2 +-----------+ CE2 |

[Med] Fixed.
---

Figure 7

OLD
            +----------------------V--------------------+----+
NEW
            +----------------------V--------------------+-----+

OLD
            | CE1 |------| PE1 |        | PE2 |---------+ CE2 |
NEW
            | CE1 +------+ PE1 |        | PE2 +---------+ CE2 |

[Med] Fixed.
---

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.

[Med] Here is a first tentative (will work this further):

NEW:

   This appendix lists a set of data models that can be used for the

   delivery of connectivity services.  These models can be classified as

   Service, Network, or Device Models.

Thank you, again.

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-framework/



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


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.