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
- [netmod] Adoption poll for draft-wwx-netmod-event… Joel Jaeggli
- Re: [netmod] Adoption poll for draft-wwx-netmod-e… Schönwälder
- Re: [netmod] Adoption poll for draft-wwx-netmod-e… Andy Bierman
- Re: [netmod] Adoption poll for draft-wwx-netmod-e… Benoit Claise
- Re: [netmod] Adoption poll for draft-wwx-netmod-e… King, Daniel
- Re: [netmod] Adoption poll for draft-wwx-netmod-e… Schönwälder
- Re: [netmod] Adoption poll for draft-wwx-netmod-e… Andy Bierman
- Re: [netmod] Adoption poll for draft-wwx-netmod-e… Qin Wu
- Re: [netmod] Adoption poll for draft-wwx-netmod-e… Xufeng Liu
- Re: [netmod] Adoption poll for draft-wwx-netmod-e… 刘 鹏
- Re: [netmod] Adoption poll for draft-wwx-netmod-e… Alexander Clemm
- Re: [netmod] Adoption poll for draft-wwx-netmod-e… Tianran Zhou
- Re: [netmod] Adoption poll for draft-wwx-netmod-e… Alexander Clemm
- Re: [netmod] Adoption poll for draft-wwx-netmod-e… Andy Bierman
- Re: [netmod] Adoption poll for draft-wwx-netmod-e… Igor Bryskin
- Re: [netmod] Adoption poll for draft-wwx-netmod-e… Andy Bierman
- Re: [netmod] Adoption poll for draft-wwx-netmod-e… Alexander Clemm