Re: [Supa] I-D Action: draft-ietf-supa-policy-based-management-framework-00.txt

Zhoutianran <zhoutianran@huawei.com> Tue, 13 September 2016 03:31 UTC

Return-Path: <zhoutianran@huawei.com>
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB1312B1A8 for <supa@ietfa.amsl.com>; Mon, 12 Sep 2016 20:31:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.729
X-Spam-Level:
X-Spam-Status: No, score=-5.729 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_PASS=-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 A0dhyqwg3S8i for <supa@ietfa.amsl.com>; Mon, 12 Sep 2016 20:31:05 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A158D12B1CB for <supa@ietf.org>; Mon, 12 Sep 2016 20:31:04 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CRE25975; Tue, 13 Sep 2016 03:31:02 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 13 Sep 2016 04:31:01 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Tue, 13 Sep 2016 11:30:58 +0800
From: Zhoutianran <zhoutianran@huawei.com>
To: "supa@ietf.org" <supa@ietf.org>
Thread-Topic: [Supa] I-D Action: draft-ietf-supa-policy-based-management-framework-00.txt
Thread-Index: AQHSDW89p5C1YLacFUO2U75YU5TphQ==
Date: Tue, 13 Sep 2016 03:30:58 +0000
Message-ID: <BBA82579FD347748BEADC4C445EA0F21A21F5684@NKGEML515-MBX.china.huawei.com>
References: <147252665079.19122.13584591411041648624.idtracker@ietfa.amsl.com>
In-Reply-To: <147252665079.19122.13584591411041648624.idtracker@ietfa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.156.116]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.57D772F7.000C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: c498fc40fe954d26ffe011e09e25fdc8
Archived-At: <https://mailarchive.ietf.org/arch/msg/supa/kSlQk1clj7q_3yRzGq4n_j2jfYc>
Subject: Re: [Supa] I-D Action: draft-ietf-supa-policy-based-management-framework-00.txt
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." <supa.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/supa>, <mailto:supa-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/supa/>
List-Post: <mailto:supa@ietf.org>
List-Help: <mailto:supa-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/supa>, <mailto:supa-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Sep 2016 03:31:08 -0000

Here are some review comments on this draft.

1. In the abstract, you mentioned that “SUPA policy can point to device, technology, service specific models”. That means SUPA model could be device policy. But the following words, “Policy rules within an operator’s environment can be used to express high-level, possibly network-wide policies to a network management function” and “Policies are a set of rules that define how services are designed, delivered, and operated within an operator's networking environment.” It seems not consistent on the policy scope. So I just want to know what exactly the SUPA scope is, the device policy or service policy or both.
 
2. In figure 1, both SUPA Generic and ECA Policy YANG data modules are used directly with resource and service model. I think both of them are base models which need to be extended, for example, specific event, condition and action. And those extension/augment belongs to other WGs or SDOs. Only those specific models can be really used. If so, I think both the figure and related text need to modify.
And this figure may give the impression that YANG data models can only come from IETF. I suspect that various vendors and other organizations (SDOs) may also want to define vendor specific or other SDO standardized YANG data models.
 
3. The second paragraph of 2.1 is not clear. And what’s “that” stands for. It reads (or can be interpreted) as if no YANG data models exists at all. That is not what you mean. I guess you mean "data models for a specific policy or target, or ??" or "do not exist for everything yet" or some such.  guess you want to explain/state that the GPIM can be extended with new YANG data models that build on GPIM or something like that.
 
4.In 2.1 the paragraph ”An ECA policy rule is …” is duplicated.
 
5. Figure 2 mixed the design time and run time process and is not logically right. The SUPA model block describes how to generate data models during the design time. It cannot communicate with the OSS/BSS or the controller. In the run time, OSS/BSS fill the data model and generate model instance, and send the instance to the controller. So I suggest to modify this figure by separating the two stages, and rewrite the corresponding text.
 
6.Following fig 2, you describe the EPRIM, “This type of Policy Rule explicitly defines the current and desired states of the system being managed.” In ECA policy, event and condition stands for the current state, the action is how to go the desired state. EPRIM does not define the desired states.
 
7. In 2.4 the paragraph “The YANG module derived from” is duplicated.
 
8. I think the IM in the process described in 2.4 will make the revision complex. The implementation feedback can just modify the DM if necessary. But this approach also need to modify the IM. 

9. You may want to change the reference [RFC6020bis] into a reference [RFC7950]. 

10. Page 9 states:
       SUPA will provide guidelines for translating the GPIM (or the
       combination of the GPIM and the EPRIM) into concrete YANG data
       models that define how to manage and communicate policies between
       systems.
Firstly, what's the "concrete YANG data models mean"? Do you mean the SUPA Generic and ECA Policy YANG data modules? I think they are base models. Can they be used directly to " manage and communicate policies between systems"?
Secondly, I thought that this WG must also define the SUPA Generic and ECA Policy YANG data models for GPIM and EPRIM from the charter. In fact Strassner and Halpern have already submitted drafts for that. So it is not just guidelines, it is the actual data models I think.

11. The last sentence of this draft is not clear. Cannot understand.
 
12. The draft only mentioned about the different model abstraction level, e.g. GPIM, EPRIM. But it does not mention functional abstraction in different level, right? For example, service level->network level. The policy may need to translate. Several lower level events will trigger higher level event and then higher level policy. I do not know whether this can be addressed in this document.

Regards,
Tianran

> -----Original Message-----
> From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of
> internet-drafts@ietf.org
> Sent: Tuesday, August 30, 2016 11:11 AM
> To: i-d-announce@ietf.org
> Cc: supa@ietf.org
> Subject: [Supa] I-D Action:
> draft-ietf-supa-policy-based-management-framework-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Simplified Use of Policy Abstractions of
> the IETF.
> 
>         Title           : SUPA policy-based management framework
>         Authors         : Will(Shucheng) Liu
>                           John Strassner
>                           Georgios Karagiannis
>                           Maxim Klyus
>                           Jun Bi
>                           Chongfeng Xie
> 	Filename        :
> draft-ietf-supa-policy-based-management-framework-00.txt
> 	Pages           : 14
> 	Date            : 2016-08-29
> 
> Abstract:
>    Simplified Use of Policy Abstractions (SUPA) defines base YANG data
>    models to encode policy, which will point to device-, technology-,
>    and service-specific YANG models developed in other working groups.
>    Policy rules within an operator's environment can be used to express
>    high-level, possibly network-wide policies to a network management
>    function (within a controller, an orchestrator, or a network element).
>    The network management function can then control the configuration
>    and/or monitoring of network elements and services. This document
>    describes the SUPA basic framework, its elements and interfaces.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-supa-policy-based-manageme
> nt-framework/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-supa-policy-based-management-fr
> amework-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> Supa mailing list
> Supa@ietf.org
> https://www.ietf.org/mailman/listinfo/supa