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
Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 29 September 2020 19:48 UTC
Return-Path: <brian.e.carpenter@gmail.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 728B63A1113; Tue, 29 Sep 2020 12:48:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.311
X-Spam-Level:
X-Spam-Status: No, score=-2.311 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 i_RjgWBZECg9; Tue, 29 Sep 2020 12:48:11 -0700 (PDT)
Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D5E13A1111; Tue, 29 Sep 2020 12:48:11 -0700 (PDT)
Received: by mail-pf1-x434.google.com with SMTP id n14so5672694pff.6; Tue, 29 Sep 2020 12:48:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=mJ2hli0QHicZLy0i9RyenhaF0igo7sunDHMvOT7lupg=; b=JVaUWwFhDR7tNoMl4QexM1gT33Gt0+sdYeW6imdpNkmqLC6kS9p3imra3G9RAhgIFA OlUxbI699ng8f5c9yj1xSkxxiqn03wzxsSmnEIuh9QuNEoyCr6efwF21xvdGlLSdJA4e ahxHE+/RWZI8lCnRxZ43o52qss+Gy863HC1CQFSZnwv/crlmxLdidGnlZ3/xzvMs4SO5 h9ypQnVgofTaE3XJG3cdSKf4vw7msKVl9bx8OXNJ67czEsIuSR+TY4aTOYoNv7BBmOrc pgk4A0uV7dSUaUvEO8r+cH+IJWkcqQG0z8aR14twnk6JiLRa3OewUxGu4KyVLN35b/e/ NCPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=mJ2hli0QHicZLy0i9RyenhaF0igo7sunDHMvOT7lupg=; b=Vg04oxyFxrtBMjDXNbHEybbgB7AgAaW2gUUcgA0HExeba692MZb62SVKHc0EgIH5SU 5Mhr7O2AHPA3uME7297x6v8PPbfdq75yxfheOzVhNFaCRJzRE0ffAWLKTpT4I5o7+eYU WZ0A/x0sdcQR3Rab/wnIYtyHxgPY4s7Zyq/Qi5X3vOOWxcHKPuPsWqs2HENKR7AlEmPB kJSXqblokIw2MydhlNzeHOhMzzfwkLZVwkBNohHaHYidRjkhw9pJ1t+G0CkZX5qgF/q2 QNm24agjI+CveeEQSs9A8uu8DaJWODW1HsXXsk7JWO7eGDLqEbbPbhr71bglmUf1BFdr vWgA==
X-Gm-Message-State: AOAM532uIzmSF0zgmJXh8BKfVBrWis3UHSvaLzdmjJqWYlbFTwfYs/MS 5wBuyizW7VX0NGNhKn0nhaWAxS64MQ+YCA==
X-Google-Smtp-Source: ABdhPJwhHTuYBspPaGElV4dp8LSUT6EfDScm4uPYRO4SqwYHf6eQcDJJ6AmImsfjNtpDy46M2PlXJA==
X-Received: by 2002:a17:902:a418:b029:d1:e598:4009 with SMTP id p24-20020a170902a418b02900d1e5984009mr6219581plq.67.1601408890543; Tue, 29 Sep 2020 12:48:10 -0700 (PDT)
Received: from [192.168.178.20] ([151.210.138.136]) by smtp.gmail.com with ESMTPSA id y7sm5561473pgk.73.2020.09.29.12.48.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Sep 2020 12:48:09 -0700 (PDT)
To: adrian@olddog.co.uk, 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> <016e01d69642$0230d150$069273f0$@olddog.co.uk>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <f33e44d9-70ac-cb11-0d6d-144b5e411219@gmail.com>
Date: Wed, 30 Sep 2020 08:48:06 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <016e01d69642$0230d150$069273f0$@olddog.co.uk>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/Q8pNZgkXYi6Zp5G9ucPDYpmAPaw>
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 19:48:13 -0000
On 29-Sep-20 22:22, Adrian Farrel wrote: > 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. 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 > > 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 > >
- [OPSAWG] Last Call: <draft-ietf-opsawg-model-auto… The IESG
- Re: [OPSAWG] Last Call: <draft-ietf-opsawg-model-… Adrian Farrel
- Re: [OPSAWG] Last Call: <draft-ietf-opsawg-model-… Brian E Carpenter
- Re: [OPSAWG] Last Call: <draft-ietf-opsawg-model-… mohamed.boucadair
- Re: [OPSAWG] Last Call: <draft-ietf-opsawg-model-… Adrian Farrel
- Re: [OPSAWG] Last Call: <draft-ietf-opsawg-model-… Brian E Carpenter
- Re: [OPSAWG] Last Call: <draft-ietf-opsawg-model-… Brian E Carpenter
- Re: [OPSAWG] Last Call: <draft-ietf-opsawg-model-… Qin Wu
- Re: [OPSAWG] Last Call: <draft-ietf-opsawg-model-… Brian E Carpenter
- Re: [OPSAWG] Last Call: <draft-ietf-opsawg-model-… mohamed.boucadair
- Re: [OPSAWG] Last Call: <draft-ietf-opsawg-model-… Brian E Carpenter