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

Adrian Farrel <adrian@olddog.co.uk> Tue, 29 September 2020 09:22 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE4B3A09DF; Tue, 29 Sep 2020 02:22:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqptCTmIyVHy; Tue, 29 Sep 2020 02:22:17 -0700 (PDT)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2BC93A0983; Tue, 29 Sep 2020 02:22:14 -0700 (PDT)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 08T9MBxp010214; Tue, 29 Sep 2020 10:22:11 +0100
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8A75C2203B; Tue, 29 Sep 2020 10:22:11 +0100 (BST)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id 74E8A22048; Tue, 29 Sep 2020 10:22:11 +0100 (BST)
Received: from LAPTOPK7AS653V ([84.93.44.153]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 08T9MAK7021077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Sep 2020 10:22:10 +0100
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Brian E Carpenter'" <brian.e.carpenter@gmail.com>, <last-call@ietf.org>
Cc: <draft-ietf-opsawg-model-automation-framework.all@ietf.org>, <opsawg@ietf.org>
References: <160095255684.28293.2595806209469918634@ietfa.amsl.com> <0ae283b5-1675-9995-757f-d6e6ccbd6d54@gmail.com>
In-Reply-To: <0ae283b5-1675-9995-757f-d6e6ccbd6d54@gmail.com>
Date: Tue, 29 Sep 2020 10:22:08 +0100
Organization: Old Dog Consulting
Message-ID: <016e01d69642$0230d150$069273f0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQKfhEHhx+3V2VyAohJSowpRNmx55AHck4PTp96UiqA=
X-Originating-IP: 84.93.44.153
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25694.006
X-TM-AS-Result: No--25.418-10.0-31-10
X-imss-scan-details: No--25.418-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25694.006
X-TMASE-Result: 10--25.417600-10.000000
X-TMASE-MatchedRID: 0+daXaNUWRVfsB4HYR80ZggKAWhuC2ojJqv0GX3SOh0/vgFpaLdKG1GF fKtYi+mRwmI3wHn00/O6J6Q2kaleR+QWMIp3xgxOUt2416ob94gGchEhVwJY3xw0HKhKjTfpG8C 0PsNHuGSYjwQFne5Ma8y29sIsy7ym4LUIl499ABKBVj0DhF8PTkN+63YtzViHRjNrjV0arFKpvK rYHQCqxkuryLJ2dvb5rJIEUzjQo8T0kLWHzhc9QQDZzaMAAwI7ChdI4sLlrjh8Tu6cvkQQvN3qV kYGwCw/tdoZ8QGJi5CmapFy0/LWhxntnm3pEHIpuwdUMMznEA9R3sGN+j7mNN+gRbw3K+dvEeWU GBiCoDXV7VjYFubQMB/AvecL4poEW/OF0jTZNZjx5KZMlKYS/WfQgc3VUSnOL7zjy4L8mSbTv2P UTA1slIrrlJcQuQmzcisyxejsi45rqtGzUvgHYImR/mpCAiHdqRoPgSQVccSG5TDCgYTolBFEt9 7pQ+C8+skl2vYAj5T78ZiX3vVqi6q07IAfK9ogPja3w1ExF8QvV5f7P0HVDPdpM2ZaJMkefMrdD 3NIUvtrbpYkBKsvfFfBkIvXvL7Ma72LzVxTKQWOjIrMSa2sR3MewI65KqfWSgweX1yjoU8Qp2GR JnINDban6GoJ8aHbdQi4jWkKa54M8jMXjBF+sIMbH85DUZXy2n9TdfAvmQKw7M6dyuYKg/cUt5l c1lLgtT4piLWpY7p+3BndfXUhXQ==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/KA0zmJbTPza7ow7V7lg2Zdx5NWU>
Subject: Re: [OPSAWG] Last Call: <draft-ietf-opsawg-model-automation-framework-06.txt> (A Framework for Automating Service and Network Management with YANG) to Informational RFC
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2020 09:22:19 -0000

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 <brian.e.carpenter@gmail.com> 
Sent: 28 September 2020 23:25
To: last-call@ietf.org
Cc: draft-ietf-opsawg-model-automation-framework.all@ietf.org; opsawg@ietf.org
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,

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