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

mohamed.boucadair@orange.com Tue, 29 September 2020 05:40 UTC

Return-Path: <mohamed.boucadair@orange.com>
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 73F0C3A03C9; Mon, 28 Sep 2020 22:40:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
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 oDV3J9Wdz-LI; Mon, 28 Sep 2020 22:40:40 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A70003A03EC; Mon, 28 Sep 2020 22:40:39 -0700 (PDT)
Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 4C0pBs6ppbz10Xg; Tue, 29 Sep 2020 07:40:37 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1601358037; bh=myqcuErAGL1MBb8di+M7NAXP0/ID5czKPwOQFoC5Fhc=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=ax52zu+6Eran1IzBvFAEMNgZWl1BT47rSyUcyx7/cJ6PhvJ+GcK4CTJZ7HCs96lOd keJJK80SF7jyoLWpzT087tUUCteeE2pc7R0HwDKcAW7MlE7FwIVDXPfFyR7eJtrWQk PA3Jnv5k30UgbtIx4A3c7YFpgXIKsmF8E6Q019F6w2hv8i+HyC4E4RqE2lB44Zpdy7 WhT/3itIkjGRhLglRVqAONPDPjpb3qrqzHq6qZNIoNY8U3Q3INFhjGHQzZCbWQy17c iN30psIDxYjzYo2TMi/DcNAJAcBoJwe0aTm2gHcq/Ncsu/4QaXmSMxkLPLetGy5xQR A1/zir/PA1C0w==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.67]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 4C0pBs65khzDq7J; Tue, 29 Sep 2020 07:40:37 +0200 (CEST)
From: <mohamed.boucadair@orange.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, "last-call@ietf.org" <last-call@ietf.org>
CC: "draft-ietf-opsawg-model-automation-framework.all@ietf.org" <draft-ietf-opsawg-model-automation-framework.all@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: Last Call: <draft-ietf-opsawg-model-automation-framework-06.txt> (A Framework for Automating Service and Network Management with YANG) to Informational RFC
Thread-Index: AQHWleY/SOf2h+BAv0+f7s2TXT27dKl/FERA
Date: Tue, 29 Sep 2020 05:40:36 +0000
Message-ID: <13759_1601358037_5F72C8D5_13759_498_1_787AE7BB302AE849A7480A190F8B933031549FD3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <160095255684.28293.2595806209469918634@ietfa.amsl.com> <0ae283b5-1675-9995-757f-d6e6ccbd6d54@gmail.com>
In-Reply-To: <0ae283b5-1675-9995-757f-d6e6ccbd6d54@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/ZVuOoZK9nms6Yd68aiibGZH7An4>
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 05:40:42 -0000

Hi Brian, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> Envoyé : mardi 29 septembre 2020 00:25
> À : last-call@ietf.org
> Cc : draft-ietf-opsawg-model-automation-framework.all@ietf.org;
> opsawg@ietf.org
> 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,
> 
> 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. 

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

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

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

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