Re: [Ibnemo] [Supa] SUPA charter proposal

Hi Benoit and others.

So would this work prevent the formation of a WG that would do IBNEMO (Intent Based NEtwork MOdeling)
work? I certainly hope not. In the charter you have:

       (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.

IBNEMO intends (no pun intended) to define/standardize a Intent expression language.
The work you describe above can be input to the work IBNEMO wants to do.

Bert

On 07/08/15 18:03, Benoit Claise wrote:
> 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:
>
> -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:
>
> 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
>
>
>
>
> _______________________________________________
> Supa mailing list
> Supa@ietf.org
> https://www.ietf.org/mailman/listinfo/supa