Subject: Re: [Last-Call] Last Call: <draft-ietf-opsawg-model-automation-framework-06.txt> (A Framework for Automating Service and Network Management with YANG) to Informational RFC

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 24 Sep 2020 14:24:17 +0100

Thanks for issuing this last call, Rob.

I think this document is a useful scene-setting for people trying to understand how to put together an automation tool for network and service management. 

I've been shepherding this draft and watching the updates done by the authors after AD review. I've read the current version and think it is ready for publication as an Informational RFC.

Cheers,
Adrian

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: 24 September 2020 14:03
To: IETF-Announce <[email-masked]>
Cc: [email-masked]; [email-masked]; Adrian Farrel <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Last Call: <draft-ietf-opsawg-model-automation-framework-06.txt> (A Framework for Automating Service and Network Management with YANG) to Informational RFC

The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document: - 'A Framework
for Automating Service and Network Management with YANG'
  <draft-ietf-opsawg-model-automation-framework-06.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2020-10-08. Exceptionally, comments may
be sent to [email-masked] instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

   Data models provide a programmatic approach to represent services and
   networks.  Concretely, 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.

   This document describes an architecture for service and network
   management automation that takes advantage of YANG modeling
   technologies.  This architecture is drawn from a network operator
   perspective irrespective of the origin of a data module; it can thus
   accommodate modules that are developed outside the IETF.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsawg-model-automation-framework/

No IPR declarations have been submitted directly on this I-D.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Sep 2020 11:25:09 +1300

Hi,

I have a question for clarification, and then a comment.

First, consider these extracts:

> 5.1.  L2VPN/L3VPN Service Delivery
> 
>    In reference to Figure 5, the following steps are performed to
>    deliver the L3VPN service within the network management automation
>    architecture defined in this document:
> 
>    1.  The Customer requests to create two sites (as per service
>        creation operation in Section 4.2.1)...
...
> 5.2.  VN Lifecycle Management
> 
>    In reference to Figure 7, the following steps are performed to
>    deliver the VN service within the network management automation
>    architecture defined in this document:
> 
>    1.  Customer requests (service exposure operation in Section 4.1.1)
>        to create 'VN' based on Access point...
...
>    3.  The Customer exchanges connectivity-matrix on abstract node and
>        explicit path using TE topology model with the orchestrator...

In those examples, how does the customer "request" or "exchange" data? I assume this is intended to happen by software, rather than by telefax. So what protocol is involved, and which entity on the customer side is doing it?

> 5.3.  Event-based Telemetry in the Device Self Management
> 
>    In reference to Figure 8, the following steps are performed to
>    monitor state changes of managed objects or resources in a network
>    device and provide device self-management within the network
>    management automation architecture defined in this document:
> 
>    1.  To control which state a network device should be in or is
>        allowed to be in at any given time, a set of conditions and
>        actions are defined and correlated with network events (e.g.,
>        allow the NETCONF server to send updates...

Second, this is the first mention of NETCONF in the document, and the only other mention is in the Security Considerations. I suggest that there should be a short description of the role of NETCONF (and RESTCONF) earlier in the document, either in section 3 or more likely in section 4 (Functional Blocks and Interactions).

Regards
   Brian Carpenter

---

From: <[email-masked]>
Date: Tue, 29 Sep 2020 05:40:36 +0000

Hi Brian, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Brian E Carpenter [mailto:[email-masked]]
> Envoyé : mardi 29 septembre 2020 00:25
> À : [email-masked]
> Cc : [email-masked];
> [email-masked]
> Objet : Re: Last Call: <draft-ietf-opsawg-model-automation-
> framework-06.txt> (A Framework for Automating Service and Network
> Management with YANG) to Informational RFC
> 
> Hi,
> 
> In those examples, how does the customer "request" or "exchange"
> data? I assume this is intended to happen by software, rather than
> by telefax. 

[Med] We hope this can be by software if we want to benefit from the automation in the full cycle but the approach still apply independently how a service request is captured. 

We don't zoom that much on that interface because the document is more on the provider's side.

So what protocol is involved, and which entity on the
> customer side is doing it?

[Med] The component at the client side are generally represented as service ordering (see RFC 4176). That component may interact with the Order Handling at the provider side using a variety of means such as https://www.rfc-editor.org/authors/rfc8921.txt (Section 5) or by offering a management interface to the customer, etc. 

Please let us know if you think that we need to add some text on this part.

> Second, this is the first mention of NETCONF in the document, and
> the only other mention is in the Security Considerations. I suggest
> that there should be a short description of the role of NETCONF (and
> RESTCONF) earlier in the document, either in section 3 or more
> likely in section 4 (Functional Blocks and Interactions).

[Med] Point taken. We will also clarify that in some cases the use of YANG does not require NETCONF/RESTCONF. 

>    Brian Carpenter

_________________________________________________________________________________________________________________________

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.

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 29 Sep 2020 10:22:08 +0100

Hi Brian,

I'll let the authors answer in more detail, but when we started the L3SM work we were by no means certain that an automated software approach would be adopted to requests by customers for service provision. The intent, therefore, was to represent the service via a data model that would be equally clear to the customer and the service provider. Communication could be on paper, via email, on a web form, or using Netconf (or, as you say, using telefax).

But this document is about the automation of network management, so we should assume that there is a protocol-based solution to the question. I think the authors will respond "Netconf" and that will mean that your second point is right - there should be a little bit more about the use of Net/Restconf in the document.

Best,
Adrian

-----Original Message-----
From: Brian E Carpenter <[email-masked]> 
Sent: 28 September 2020 23:25
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: Last Call: <draft-ietf-opsawg-model-automation-framework-06.txt> (A Framework for Automating Service and Network Management with YANG) to Informational RFC

Hi,

...
...

Regards
   Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Sep 2020 08:48:06 +1300

> But this document is about the automation of network management, so we should assume that there is a protocol-based solution to the question. I think the authors will respond "Netconf" and that wil…

I'm not completely sure Netconf is the right answer, but then, I'm a protagonist of ANIMA, which would certainly be another possible answer in the long term. Once we get the base ANIMA documents out I think there needs to be a conversation about exactly how ANIMA, NETCONF and YANG interact. (I'm thinking that an autonomic service agent on the customer side would negotiate with one on the provider side, and that would trigger the requisite actions as defined in the present document.)

Regards,

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Sep 2020 08:54:49 +1300

Hi Med, see below...
> [Med] The component at the client side are generally represented as service ordering (see RFC 4176). That component may interact with the Order Handling at the provider side using a variety of mean…

Well, I'd rather see a standardised and generic solution to that problem, as noted in my reply to Adrian. But indeed, that is the requirement.
 
> Please let us know if you think that we need to add some text on this part.

I think it needs just a few words in section 3 or 4, even just to say that the mechanism is out of scope for this document.

> [Med] Point taken. We will also clarify that in some cases the use of YANG does not require NETCONF/RESTCONF. 

Thanks. (For example, draft-ietf-anima-grasp-distribution can serve for distributing YANG.)

    Brian