Subject: Re: [Supa] SUPA charter proposal

From: Ying Cheng <[email-masked]>
Date: Mon, 10 Aug 2015 11:13:32 +0800

Hi Benoit et al,

After reading this new charter and comparing to the previous one, I think most of the concerns we discussed in the mailing list and during the latest BoF were well addressed, especially the section "Out of scope of this working group", making it quite clear to the previous pending issues. I think this would make a working group and I could contribute to it. 

Thanks and best regards,
Ying

2015-08-10 

Ying CHENG  程莹
China Unicom Network Technology Research Institute 中国联通网络技术研究院
Tel: +86-10-68799999-7702
Mobile: +86-18601102971

发件人： Benoit Claise 
发送时间： 2015-08-08  00:03:40 
收件人： [email-masked] 
抄送： Eggert, Lars 
主题： [Supa] SUPA charter proposal 
 
Dear all,

As promised in my last email ("SUPA: Situation Summary and Next Steps"), here is a proposed charter.
Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu.

Hopefully, this new version will clarify the situation, and will be acceptable to everybody.
Please let us know. Note: I prefer to keep the edit token from now.

Regards, Benoit (OPS AD)

==============================================================

SUPA CHARTER PROPOSAL (2015-08-07)
 
Policy is an important configurable component in the delivery of services and the operation of networks. Operators want and need to be able to determine the policies that apply to their different customers and to the equipment that comprises their physical and virtual networks. As policy spans such a wide range of services and device types, it will be helpful if there is a common way of expressing and describing policies that is uniform and consistent in all environments. Such an approach will help to avoid configuration errors that arise from confusion between different systems, will enable easy understanding of policies that apply in different environments, will make the implementation of policy-based systems quicker and cheaper, and will facilitate the rapid development of standards-based data models that include policy elements.

SUPA (Simplified Use of Policy Abstractions) defines a model to interface with a network management function (within a controller, an orchestrator, a network element) that takes high-level, possibly network-wide policies as input. SUPA will not define what the function does with that input but anticipates that it will ultimately result in network configuration changes

Practically, SUPA will define generic YANG data models to encode policy, which can point to device-, technology-, and service-specific YANG models of other working groups. 
 
SUPA will be designed to work with device, protocol, network, and service data models.
 
The SUPA working group will develop a model for expressing policy at different levels of abstraction.  Specifically, three model fragments are envisioned: (i) a generic model that defines concepts and vocabulary needed by policy management independent of the form and content of the policy, (ii) a more specific model that refines the generic model to specify how to build policy rules of the event-condition-action paradigm, and (iii) the working group will investigate the practically of building policy rules that declaratively specify what goals to achieve (this is often called "intent-based" policy) but not how to achieve those goals and may create a model accordingly.
 
If the working group finds it necessary to work on an information model before the data model, to help provide guidance and derive the data models, it might do so. The working group will decide later whether the information model needs to be published as an RFC.
 
Out of scope of this working group is:  
<!--[if !supportLists]-->-   <!--[endif]-->The specification of a new policy language. The YANG data models are to be used with protocols such as NETCONF/RESTCONF.
<!--[if !supportLists]-->-   <!--[endif]-->Design of protocol-specific policies and specific design for embedded policies in network elements (which are usually interpreted in isolation, and often at timescales that require optimization for specific purposes).
<!--[if !supportLists]-->-   <!--[endif]-->Specific handling of policies (although the application document will provide some examples), and therefore the specification of a policy engine that maps a specific policy instance to actual configuration snippets.
 
List of work items:
 
1) A document that explains the scope of the policy-based management framework and how it relates to existing work of the IETF.
 
2) If the working group considers it necessary, an information model composed of policy concepts and vocabulary. 
 
3) A set of YANG data models consisting of a base policy model for representing policy management concepts independent of the type or structure of a policy, plus an extension for defining policy rules according to the event-condition-action paradigm. Another extension for defining policy rules according to a declarative, or intent-based, paradigm, may be produced. These models will be designed to be generic and extensible.
 
4) An applicability document providing a few examples that demonstrate how the generic policy models can be used to express policies that are relevant for network operators. The examples may tie into configuration models or network service models developed by other working groups.
 
The working group will decide how the work items are best mapped into deliverables. 
 
This working group will be a success when the SUPA policy constructs are re-used in future IETF specifications (and, ideally, specifications from other SDOs), in a manner that will save development time and avoid inconsistencies between data models developed by different working groups. In the meantime, SUPA should not impede work in other working groups while waiting for SUPA to produce its deliverables. 
 
The working group will communicate with other SDOs (MEF, TMF, ETSI) that are working on related issues.
 
Milestones:
 
TBD

如果您错误接收了该邮件，请通过电子邮件立即通知我们。[email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。
If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked] if you want to unsubscribe from this mail. We will immediately remove your information from our sending catalogue.

---

From: "Jun Bi" <[email-masked]>
Date: Fri, 14 Aug 2015 18:26:42 +0800

Hi All,

The new charter looks fine to me, in general. It is more understandable and the work items are reasonable.

I have one question regarding “out of scope #3” 

Specific handling of policies (although the application document will provide some examples), and therefore the specification of a policy engine that maps a specific policy instance to actual configuration snippets.

Previously we worked on mapping and right now the applicability document all have major component focused on this kind of mapping procedure from policy to real configurations. And also, the  mailing list has been talked about a lot on policy translation function or policy engine to do the similar job. From the charter text here, we are no longer working on this translation on details. So do we just assume the network management function, let’s say controller, has such capability?

Best Regards,

Jun Bi

From: Supa [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Saturday, August 08, 2015 12:03 AM
To: [email-masked] <mailto:[email-masked]> 
Cc: Eggert, Lars
Subject: [Supa] SUPA charter proposal

Dear all,

Regards, Benoit (OPS AD)

 

 

-   The specification of a new policy language. The YANG data models are to be used with protocols such as NETCONF/RESTCONF.

-   Design of protocol-specific policies and specific design for embedded policies in network elements (which are usually interpreted in isolation, and often at timescales that require optimization for specific purposes).

-   Specific handling of policies (although the application document will provide some examples), and therefore the specification of a policy engine that maps a specific policy instance to actual configuration snippets.

List of work items:

Milestones:

TBD