Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang

刘 鹏 <liupengyjy@outlook.com> Tue, 25 February 2020 09:00 UTC

Return-Path: <liupengyjy@outlook.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372273A0A73; Tue, 25 Feb 2020 01:00:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.597
X-Spam-Level:
X-Spam-Status: No, score=-0.597 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, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 dkOUqNsd98Ts; Tue, 25 Feb 2020 01:00:38 -0800 (PST)
Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254027.outbound.protection.outlook.com [40.92.254.27]) (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 87DD43A0A72; Tue, 25 Feb 2020 01:00:37 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AGpkDtvTyR5oZCPxKvJQtYZ0q6DjiGnMexYir2z5Z4zkmP7XDBC0Vql4+D8RwbThppmfddlDaB8vvIxe2Ed1cY/v/obAggE0hb2ApseIH1JqWEgyjEf2hfrQ8glbf2f1ByCK/4eFscdlBrrCZ7Z9QOPAAhZ1Bztj3cxXV09hP5Bxpdz8qDzuCzppqbsXL+Vm6aE4g1oVCkbTwP5wq8yJZZYw+To49+XsHbeXI4GF5A6B6Hl8YtBEftQ9t92sgzEMgS0ERy/dmWsXmsnFBySbv+O33Zoz7MAZ+SkBuXKbEhaQrBmz8ftF3LBcN4r8aMoil6e8OLHTAO/SYdoGAKq4YA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ja/kXUkUhbo+BCrG/qoA7S3ZSdaSod2mq/sQsfKloH4=; b=D2bmBy/NFiVMKKgZyZ0XvE8HFsTdkL9lSNrfy3HTrILzW8L01wy4uu+Aw61TT9KW2oXtqaOo+Z73YCGhtL8bJyIhh/Pj7cfxM1QQH/tg/gYEA3nn48cd3gddlzRHOtV70O6OHuPdTvSojzp9lC8qkzZDBAWY464NjnDtheRFB82y+M64YPLjGP54DTC2R/O/72xsSo0WGMZzJdtRd6X6KyyPAQjyUPUOz+toxHpYhHfUnBGok05M/nHrzO3QOPjQ9ZxjIVRAxJP4XXasAI1H4iFEPANr8/umwtP77XyjQo6MDtbt9oOMovam3haS4LjslEMveFZSkWZVd8vL60MhNg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ja/kXUkUhbo+BCrG/qoA7S3ZSdaSod2mq/sQsfKloH4=; b=n40S8aS9hqcQ3DG8B8i3qyxHnEHB0iqIoQt04CllVHHzVivoTEIY5znRQEUPJF2Z6W8Bu0B82YIkjWQyvs/k5vj9nX1BL9vsi8GfscZ2m4JNrEngF4JEttDw2Yru8SKfaqdc13OueOZUMR+T5SsYYHxSM1B3Bm6PLugOX8dPmrqGzYmmJu5aoxzYvgOwUkzB4Xvt3PzKxTXnJ9JmIp8Yr7+d5rpnmWBnQB2eYuJboZRsVAjbJSSA8fcX0H54z+I53JODlZuhv+T9mK/O1ZdgUe3VOKFG+2/KToYOCYb6XgqEYzJopx140lyXOlbergoq9nWy5eiAg8N+V/RiwZw/MA==
Received: from PU1APC01FT014.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::3a) by PU1APC01HT240.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::254) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.19; Tue, 25 Feb 2020 09:00:31 +0000
Received: from PU1PR06MB2215.apcprd06.prod.outlook.com (10.152.252.56) by PU1APC01FT014.mail.protection.outlook.com (10.152.252.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.18 via Frontend Transport; Tue, 25 Feb 2020 09:00:31 +0000
Received: from PU1PR06MB2215.apcprd06.prod.outlook.com ([fe80::a958:b7ef:77a6:adb4]) by PU1PR06MB2215.apcprd06.prod.outlook.com ([fe80::a958:b7ef:77a6:adb4%6]) with mapi id 15.20.2750.021; Tue, 25 Feb 2020 09:00:31 +0000
Received: from Peng (117.136.0.193) by HK2PR02CA0152.apcprd02.prod.outlook.com (2603:1096:201:1f::12) with Microsoft SMTP Server (version=TLS1_1, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA) id 15.20.2750.18 via Frontend Transport; Tue, 25 Feb 2020 09:00:29 +0000
From: 刘 鹏 <liupengyjy@outlook.com>
To: netmod-bounces <netmod-bounces@ietf.org>
CC: netmod <netmod@ietf.org>
Thread-Topic: [netmod] Adoption poll for draft-wwx-netmod-event-yang
Thread-Index: AQHV5nrGRuy6gexPPk2TqGQjqLyRmw==
Date: Tue, 25 Feb 2020 09:00:31 +0000
Message-ID: <PU1PR06MB2215AA7E56E20FD995A3093DDAED0@PU1PR06MB2215.apcprd06.prod.outlook.com>
References: <e655193d-79f5-f339-7043-65e2044c406e@bogus.com>, <20200218231700.3tho6ngescf2k4zh@anna.jacobs.jacobs-university.de>, <4b29cb4d-d252-b139-a46c-b5530f998a3b@cisco.com>, <CWXP265MB0775983A3A9DB3FABC23D932D6100@CWXP265MB0775.GBRP265.PROD.OUTLOOK.COM>, <CAEz6PPSgRX=NEfhDj_HyVddCMPHtQ9Zoo84mvyvLsdmmF4givQ@mail.gmail.com>, <B8F9A780D330094D99AF023C5877DABAAD4E2298@dggeml511-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: HK2PR02CA0152.apcprd02.prod.outlook.com (2603:1096:201:1f::12) To PU1PR06MB2215.apcprd06.prod.outlook.com (2603:1096:803:38::11)
x-incomingtopheadermarker: OriginalChecksum:893FFCADFBC8989C2ADF50EB3677FACD8FB6CCB104B9942CB9E5438FA492414D; UpperCasedChecksum:7AB5B270E4365E45F97534DBAFCF7B7FB2DDF7B9EC44B9F88ADEFD44F9F6C38A; SizeAsReceived:7917; Count:53
x-ms-exchange-messagesentrepresentingtype: 1
x-guid: C1161D1E-9940-493E-AFB4-E6A6FC58586B
x-has-attach: no
x-mailer: Foxmail 7.2.9.115[cn]
x-tmn: [Wb7ok4k5XRc6phKkXhStTuE/OvbKn5jL]
x-microsoft-original-message-id: <2020022517003043323011@outlook.com>
x-ms-publictraffictype: Email
x-incomingheadercount: 53
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 4d01c591-a7a9-4d4d-7092-08d7b9d12a08
x-ms-traffictypediagnostic: PU1APC01HT240:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: VG08FjgaXCk4i8YI0EQYi9UJqN2TK55F1olNDx/2qlNfiokFIOJEhtg+P4GIVERV3FZ9dR2iYgvG4w4KNABcpJ7QKVnSJdI0B/BWA1jHZtfFrKbXejtHa4ATsfNxexrqbZxwx34q8VszvfLPsv/3DFdkCr5vRSfn21YtGYws7aFZm0QntHj1AlC/e9yOrqRxkWDuyygPq2ub2LYFVXe0TOBvBxL1pA/byu3ak6RoUAA=
x-ms-exchange-antispam-messagedata: R9ug0eyBDlkjU8GDXs9mC6809QzVKayZeV8/qaUoRnbh7530IRilHon7pZRVEDL5Ytx4JFT0irVRuTbbkVmYZmu5cdG//uSMJPEiO9mfjAGDyO2gKkx67UTXUgcXF/gl8N7UKLHHTPvXV6fgdLDyKw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_PU1PR06MB2215AA7E56E20FD995A3093DDAED0PU1PR06MB2215apcp_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 4d01c591-a7a9-4d4d-7092-08d7b9d12a08
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2020 09:00:31.0808 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT240
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/jlLoOcv90SmLjagPPEE0ToXeZGo>
Subject: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2020 09:00:40 -0000

Hi ALL,

I have read this draft and if my understanding is correct, I believe the main idea of this draft is to preconfigure the device with some policy rule, which allows the device have the capability of self control on the management behavior within the system and have a prompt rapid response to the network state changes.

This is exactly something we are looking for in the network management automation. I support adoption of this work.

BR, Peng
China Mobile

From: netmod <netmod-bounces@ietf.org<mailto:netmod-bounces@ietf.org>> On Behalf Of Benoit Claise
发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Xufeng Liu
发送时间: 2020年2月25日 2:27
收件人: King, Daniel <d.king@lancaster.ac.uk>
抄送: netmod@ietf.org
主题: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang

Agree with Dan. The use case is valid, though the errors in the data model can be fixed.
Support.
Thanks,
- Xufeng

On Wed, Feb 19, 2020 at 6:44 AM King, Daniel <d.king@lancaster.ac.uk<mailto:d.king@lancaster.ac.uk>> wrote:
Hi All,

Expressing, and delegating base imperative policy to network nodes (regardless if it’s a switch, router, network function, or indeed “controller”) is a critical step for facilitating network automation. I support the I-D and would like to see the WG adopt the work. Yes, the I-D needs to be developed further and this would be better managed if the effort was owned by the WG.

I do agree somewhat with Jürgen that past experiences have shown a lack of willingness between vendors for expressing policy (imperative or otherwise). Major vendors have tended to implement their own policy language, or specific purpose (security, role management, et al.) language that has been based on standards (formal) or open-source project (de facto). The fact that the I-D author and contributor list already has a good mix of implementors demonstrates a willingness to develop an interoperable network-wide solution.

BR, Dan.

From: netmod <netmod-bounces@ietf.org<mailto:netmod-bounces@ietf.org>> On Behalf Of Benoit Claise
Sent: 19 February 2020 10:46
To: Schönwälder, Jürgen <J.Schoenwaelder@jacobs-university.de<mailto:J.Schoenwaelder@jacobs-university.de>>; Joel Jaeggli <joelja@bogus.com<mailto:joelja@bogus.com>>
Cc: netmod@ietf..org<mailto:netmod@ietf.org>
Subject: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang

Jürgen,

To tell that I was skeptical about the SUPA work is just wrong.

I had great hopes for SUPA, as having consistent policy constructs in YANG module was key. The big hope was that those SUPA constructs could be re-used in other YANG modules
    example: routing, ACL, security ...
    Regardless of the location: in a network element or in a controller/orchestrator
    Regardless of the function: network element and service YANG modules
If successful, in the end, SUPA would have helped to reuse code.

Was I disappointed by the progress? Yes. The results were not there while the rest of the world uses their YANG policy constructs. Timing was key so, as AD, I had to pull the plug.
The world has moved on. So be it.
You can't infer skepticism from pragmatism.

Now, back to the draft.
>From a network element point, I stressed the need to take have simple ECA rules directly routers.
Think about RMON event/alarm but for YANG. Think about removing the RMON event/alarm restrictions that it works only for integer/counter.
If your point is that the draft is not perfect, fair point.
Should we solve attempt to solve that issue? Yes.

A confusion comes from the abstract that implies that this work is based on SUPA.

Abstract



   RFC8328 defines a policy-based management framework that allows

   definition of a data model to be used to represent high-level,

   possibly network-wide policies.  Policy discussed in RFC8328 are

   classified into imperative policy and declarative policy, Event

   Condition Action (ECA) policy is an typical example of imperative

   policy.  This document defines a YANG data model for the ECA policy

   management.  The ECA policy YANG provides the ability for the network

   management function (within a network element) to control the

   configuration and monitor state change and take simple and instant

   action on the server when a trigger condition on the system state is

   met.
Actually, in my mind, the abstract should be simplified to something such as (and yes, it could be improved)

Abstract



   This document defines a YANG data model for the ECA policy

   management.  The ECA policy YANG provides the ability for the network

   management function (within a network element) to control the

   configuration and monitor state change and take simple and instant

   action on the server when a trigger condition on the system state is

   met.
And then, somewhere in the introduction, the following text should be reused:

   RFC8328 defines a policy-based management framework that allows

   definition of a data model to be used to represent high-level,

   possibly network-wide policies.  Policy discussed in RFC8328 are

   classified into imperative policy and declarative policy, Event

   Condition Action (ECA) policy is an typical example of imperative

   policy.

Regards, Benoit.

On Tue, Feb 18, 2020 at 08:44:18AM -0800, Joel Jaeggli wrote:

This email begins a 2 week working group adoption poll for:



https://tools.ietf.org/html/draft-wwx-netmod-event-yang-06



Please voice your support or objections before the poll completes on

March 3rd.



I am against adoption of this draft. I wonder whether Benoit will

explain his contributions to this document; Benoit was added as a

co-author in -06 and he used to be rather sceptical about the SUPA

work (and this is essentially part of the SUPA work resubmitted to the

NETMOD WG). Despite this, the YANG definitions are clearly not up to

the level one would expect for WG adoption. Many descriptions are

just repetition of leaf names and there are obvious errors such as



          leaf-list day-of-month {

            type uint8 {

              range "0..59";

            }

            description

              "A set of days of the month at which this

               scheduling timing will trigger.";

          }



Despite the strange range, it is unclear how a number will in the

range will identify a set. Note, this is an example, there are lots of

them in the document. The examples provides are not convincing and

technically wrong (how can <interval>10m</interval> match



          leaf interval {

            type uint32 {

              range "1..max";

            }

            units "seconds";

            mandatory true;

            description

              "The number of seconds between two triggers

               generated by this periodic timing object.";

          }



and I have serious doubts that the design is anywhere close to be

practically usable. There need to be mechanisms to bind 'variables'

while matching conditions that and be reused in action definitions, it

is not scalable to have constants such as interface names in the

examples hard-coded in policy rules - this would lead to a huge number

of rules if you want to apply policy rules to all interfaces.



There is also a lack of extensibility, which is important for a core

policy language, and definitions like:



  identity function-type {

    description

      "Possible values are:

       plus, minus, mult, divide, remain..";

  }



without ever defining these operators feels strange. I also not

convinced that the resulting expressions are expressive enough for

real-world use.



This document is in a state that requires way too much effort to fix

in a WG process. I also doubt that expressing policies in such a

low-level format is usable in practice. Policy languages for network

management have a long history and this proposal seems to ignore the

lessons learned in the past.



/js



_______________________________________________
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod