Subject: [Supa] SUPA charter proposal

From: Benoit Claise <[email-masked]>
Date: Fri, 7 Aug 2015 18:03:13 +0200

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

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Fri, 07 Aug 2015 20:46:22 +0200

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.
> Hopefully, this new version will clarify the situation, and will be acceptable to everybody.
> 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.
>
> -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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa

---

From: Andrew Veitch <[email-masked]>
Date: Sat, 8 Aug 2015 15:24:41 +0000

H Benoit et al,

My congratulations on this version of the charter.  I think it is crisp, clear and well scoped.

I have included a few comments or recommended changes in the text below, mostly, I hope, to have made it be clearer. But none change the substance.  Very nice job.

Thanks and best regards,

Andy

Andrew Veitch | Mobile: +1 (781) 366-7763 | www.<http://www.NetCracker.com>Net<http://www.NetCracker.com>Cracker<http://www.NetCracker.com>.com<http://www.NetCracker.com> >>>>  Proven Partner to Communications Service Providers

On Aug 7, 2015, at 12:03 PM, Benoit Claise <[email-masked]<mailto:[email-masked]>> wrote:

Dear all,

Regards, Benoit (OPS AD)

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.

Old:

[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]

New (moved clauses around to be clearer.):

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

Note: I changed “can” to “will” here.  I do not see how a policy can exist without reference to the context(s) or domain(s) for which it is applicable.  Others may disagree.

Practically, SUPA will define base YANG data models to encode policies, which will point to device-, technology-, and service-specific YANG models developed in other working groups.

Note: Got rid of “fragment”, made bulleted list look like list.  Also removed “form”, as it is not necessary and confusing a bit.  SUPA is defining the form, I think.

The SUPA working group will develop a model for expressing policy at different levels of abstraction.  Specifically, three models are envisioned:

(i) a base model that defines concepts and vocabulary needed by policy management independent of the content of the policy,
(ii) a more specific model that refines the base 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:

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 Yang policy data 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.

Note: Item 4  says a document will provide examples on how data models can be used to express policies relevant to operators.  I changed text to specifically mention the Yang policy data models, as that is what is being defined by the group, so I wanted to be clear that the value will be to show how those will work.  However, I also want to be clear i am not envisioning the group defining or “standardizing” specific policies using the Yang models.  Other working groups would own that work as described in the penultimate paragraph.

Note: I would consider moving this next paragraph to earlier, perhaps after the line "SUPA will be designed to work with device, protocol, network, and service data models.”  I think it might benefit by being clear up front that the purpose os the define constructs to benefit the creation of policy definition across all working groups and perhaps beyond.  This is important context to be aware of when reading the rest of the document.  I am interested in what others think.

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.

Milestones:

TBD

_______________________________________________
Supa mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/supa

________________________________
The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential, proprietary and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 8 Aug 2015 19:14:44 +0200

> network configuration changes

I am not sure what the intend of the last sentence is. I hope that the
semantics of the interface to the policy network management function
are defined clearly enough that the translation of policy into network
configuration changes is not a mystery.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Sat, 8 Aug 2015 10:48:42 -0700

Hi,

I have a lot of questions about this work, but in general I would like
a coherent approach to all YANG data model development.  This includes
data models for policy-base management. SUPA can really help
in this area.

Without work item (1) completed, I don't see how any speculation
on the details of (2), (3), and (4) are possible. (But I will speculate
anyway ;-)

The deliverable in (2) is not very clear. Does this mean an Informational
RFC
based on
https://tools.ietf.org/html/draft-strassner-supa-generic-policy-info-model-00
I hope it does not mean create a CIM-like model of everything.
This text should be clear wrt/ identifying the deliverable(s).

The data models in (3) are not very clear either.
Since a "new policy language" is out of scope,
it makes me wonder if the IETF is going to attempt
to get people to "program in YANG" instead.  I am only
interested in practical, efficient, and easy-to-use solutions.
I am skeptical that SUPA is going to deliver that.

There are no milestones mentioned at all.
I guess this is the new normal in the IETF?
Schedules are a joke, so let's just get rid of them completely?
I share Adrian's concern about taking too long to deliver (3),
because other policy work is not going to wait for SUPA.
Can (3) be delivered within 1 year or not? If not, then why not?

Andy

On Fri, Aug 7, 2015 at 9:03 AM, Benoit Claise <[email-masked]> wrote:

> 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
>
>
>
>
>
> which can point to device-, technology-, and service-specific YANG models
> of other working groups.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> -   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:
>
>
>
> 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.
>
>
>
> 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.
>
>
>

---

From: Andrew Veitch <[email-masked]>
Date: Sat, 8 Aug 2015 19:01:08 +0000

Hi Andy,

Your comment on (3) is interesting.   I do not think there is any expectation of programming in Yang.  I did have some thoughts like that in Prague, as the policies (as I understood them and i might have this wrong) are in the form of First Order Logic statements.  If at a fine enough granularity,  perhaps they could be strung together and processed as statements are in Prolog.

But I believe the intention, buttressed by my reading of the term “high level … policies” (I take that very seriously) in the charter, is that these define high-level policies and a policy engine (or whatever) would process them and use scripts, or rules, or whatever, to figure out how to support them (also specifically listed as out of scope.)

My hope for SUPA is what you listed up front, and I think it could deliver: providing a piece for the coherent approach to data models.  And it seems like SUPA could deliver a common form for representing policy, with specializations for ECA and/or Declarative as needed.

I agree, milestones are a must.  I think the TBD is just that, perhaps these can be easily addressed after the first part is settled.

Best regards,

Andy

On Aug 8, 2015, at 1:48 PM, Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Without work item (1) completed, I don't see how any speculation
on the details of (2), (3), and (4) are possible. (But I will speculate anyway ;-)

The deliverable in (2) is not very clear. Does this mean an Informational RFC
based on https://tools.ietf.org/html/draft-strassner-supa-generic-policy-info-model-00
I hope it does not mean create a CIM-like model of everything.
This text should be clear wrt/ identifying the deliverable(s).

Andy

On Fri, Aug 7, 2015 at 9:03 AM, Benoit Claise <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,

Regards, Benoit (OPS AD)

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.

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.

List of work items:

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.

Milestones:

TBD

---

From: Jon Saperia <[email-masked]>
Date: Sat, 8 Aug 2015 15:45:51 -0400

My read of deliverable 3 is that this model is also still abstract.  It ‘extends’ the base model with information about the specific types of policy they define.  They are not concrete.

After all this work is completed, without concrete examples and rules about conversion from these policies into configuration data for systems, interoperation will be problematic.  Over the years policy efforts that I am aware of have remained ‘high level’ without tackling the difficult and more important problem of defining an approach for taking policy and translating it into something different systems using different technologies could use.  Without this, the value of the working group declines significantly.

/jon
> On Aug 8, 2015, at 3:01 PM, Andrew Veitch <[email-masked]> wrote:
> 
> Hi Andy,
> 
> Andrew Veitch | Mobile: +1 (781) 366-7763 | www. <http://www.netcracker.com/>Net <http://www.netcracker.com/>Cracker <http://www.netcracker.com/>.com <http://www.netcracker.com/> >>>>  Proven Partner to Communications Service Providers
> 
>> On Aug 8, 2015, at 1:48 PM, Andy Bierman <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi,
>> 
>> based on https://tools.ietf.org/html/draft-strassner-supa-generic-policy-info-model-00 <https://tools.ietf.org/html/draft-strassner-supa-generic-policy-info-model-00>
>> On Fri, Aug 7, 2015 at 9:03 AM, Benoit Claise <[email-masked] <mailto:[email-masked]>> wrote:
>> Dear all,
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/supa <https://www.ietf.org/mailman/listinfo/supa>
>> 
>> 
>> [email-masked] <mailto:[email-masked]>

Thanks
/jon
------------------------------------
Jon Saperia
(mobil) 617-201-2655
[email-masked]

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 9 Aug 2015 16:23:22 +0100

Hi Bert,

I don't think you are reading the proposed charter for SUPA right if you think
it precludes the formation of a working group for IBNEMO. Rather, the text that
Benoit has published says that SUPA is not the working group that works on
IBNEMO.

But maybe you are saying that the intent-based part of the SUAP charter could be
lifted out and placed in an IBNEMO work effort. That might be reasonable.

However, there is a separation between the use of existing data modeling and
protocols (such as YANG with NETCONF) and the development of a new and
specialised modeling language and communication protocol. I believe that this
charter text opens up the investigation of the practicalities of intent-based
policy modeling in order to determine whether such things could be modeled in
existing languages or whether new work is needed a priori. 

If, for example, it was possible to encode intent-based policy in YANG, that
would not preclude IBNEMO inventing something different/better/worse. 

Now there it seems sensible that SUPA should bundle all of the thought around
policy models in one place as a starting point. If it is later desirable to
split off the intent-based part (say after the initial investigation and
information models) that doesn't seem like a bad thing.

Alternatively, if there is a strong pull to move all of the intent-based work
out from day one, I will not be complaining.

Cheers,
Adrian

> -----Original Message-----
> From: Supa [mailto:[email-masked]] On Behalf Of Bert Wijnen (IETF)
> Sent: 07 August 2015 19:46
> To: Benoit Claise; [email-masked]
> Cc: Eggert, Lars; [email-masked]
> Subject: Re: [Supa] SUPA charter proposal
> 
> Hi Benoit and others.
> 
>        (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
here
> is a proposed charter.
acceptable to
> everybody.
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
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
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
> > Practically, SUPA will define generic YANG data models to encode policy,
which
> can point to device-, technology-, and
> > SUPA will be designed to work with device, protocol, network, and service
data
> models.
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
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.
> >
> > -The specification of a new policy language. The YANG data models are to be
> used with protocols such as NETCONF/RESTCONF.
> >
policies in
> network elements (which are usually interpreted
provide
> some examples), and therefore the specification of
composed
> of policy concepts and vocabulary.
> >
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
> 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
> > 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

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 9 Aug 2015 16:33:42 +0100

Hi Juergen,

I don't think I sourced the line of text you are asking about, but I certainly
reviewed it several times.

> configuration changes is not a mystery.

It was my view that the text was there to avoid exactly the discussion we will
now have :-)

You say that you believe that the output of policy network management function
resulting from policy input will be clearly defined configuration changes. It
seems to me that this is often likely, but not always the case. For example, if
I was building such a function I would make it stateful and I would expect it to
retain some policy state itself that it would then use to determine how to
process future policy instructions.

For example, a simple policy is "who is allowed to set policy?" You could, of
course, push this down in the form of network configuration, but I would tend to
implement that piece of policy within the network management function itself.
Thus, no direct mapping to network configuration (although *ultimately* it will
have an effect).

The point, therefore, of the text is to say "Yup, Juergen is probably right on
this, but it is not actually the aim of the WG to define how the policy network
management function works or how it responds to each policy-related instruction.
The aim is only to define the interface."

Cheers,
Adrian

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 9 Aug 2015 18:59:57 +0200

> The aim is only to define the interface."

Even with this explanation, I find the phrase "SUPA will not define
what the function does with that input but anticipates that it will
ultimately result in network configuration changes" too vague for
charter text. The IETF's mantra is rough consensus and running code
and for creating (interoperable) running code the semantics of the
interface must be clearly and precisely defined.

The reason I am concerned here is because I have seen various
proposals during the SUPA process so far where I would have little
clue how to really implement things (and I doubt two coders would have
filled the void with the same interpretation). Perhaps this is just
because we are in early stages but I personally would feel better if
the charter would make it clear that we are not looking for high-level
abstract blueprint descriptions of a policy function but rather
something concrete and well defined that can lead to interoperate
running code. To me, the sentence kind of legitimates high-level
abstract blueprint models - even if this might not have been the
intention.

Anyway, if it is just me how is concerned about this sentence and
everybody else is happy with the sentence, simply ignore my email.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 9 Aug 2015 17:13:06 +0000

What about: 

OLD: 

SUPA will not define what 
the function does with that input but anticipates that it will 
ultimately result in network configuration changes

NEW: 

We anticipate that processing that input will result in network configuration changes. SUPA however will not deal with the definition of the specific network configuration changes but with how the configuration changes are applied (e.g. who is allowed to set policies, when and how the policies are activated, changed or de-activated)

Regards,

Dan
 
> From: Supa [mailto:[email-masked]] On Behalf Of Juergen
> Schoenwaelder
> Sent: Sunday, August 09, 2015 8:00 PM
> To: Adrian Farrel
> Cc: 'Benoit Claise'; 'Eggert, Lars'; [email-masked]
> > I don't think I sourced the line of text you are asking about, but I
> > certainly reviewed it several times.
> >
> > > > 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
> > >
> > > I am not sure what the intend of the last sentence is. I hope that
> > > the semantics of the interface to the policy network management
> > > function are defined clearly enough that the translation of policy
> > > into network configuration changes is not a mystery.
> >
> > It was my view that the text was there to avoid exactly the discussion
> > we will now have :-)
> >
> > You say that you believe that the output of policy network management
> > function resulting from policy input will be clearly defined
> > configuration changes. It seems to me that this is often likely, but
> > not always the case. For example, if I was building such a function I
> > would make it stateful and I would expect it to retain some policy
> > state itself that it would then use to determine how to process future
> policy instructions.
> >
> > For example, a simple policy is "who is allowed to set policy?" You
> > could, of course, push this down in the form of network configuration,
> > but I would tend to implement that piece of policy within the network
> management function itself.
> > Thus, no direct mapping to network configuration (although
> > *ultimately* it will have an effect).
> >
> > The point, therefore, of the text is to say "Yup, Juergen is probably
> > right on this, but it is not actually the aim of the WG to define how
> > the policy network management function works or how it responds to each
> policy-related instruction.
> Even with this explanation, I find the phrase "SUPA will not define what the
> function does with that input but anticipates that it will ultimately result in
> network configuration changes" too vague for charter text. The IETF's mantra
> is rough consensus and running code and for creating (interoperable) running
> code the semantics of the interface must be clearly and precisely defined.
> 
> The reason I am concerned here is because I have seen various proposals
> during the SUPA process so far where I would have little clue how to really
> implement things (and I doubt two coders would have filled the void with the
> same interpretation). Perhaps this is just because we are in early stages but I
> personally would feel better if the charter would make it clear that we are
> not looking for high-level abstract blueprint descriptions of a policy function
> but rather something concrete and well defined that can lead to interoperate
> running code. To me, the sentence kind of legitimates high-level abstract
> blueprint models - even if this might not have been the intention.
> 
> Anyway, if it is just me how is concerned about this sentence and everybody
> else is happy with the sentence, simply ignore my email.
> 
> /js
> 
> --
> Fax:   +49 421 200 3103
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jacobs-
> 2Duniversity.de_&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31O
> cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=4mENw6of-
> _UVUsUHR2rL3Sz3LMr1SnSv6ZgG-
> oD8Xnk&s=Msl9oYAWg1eaEBh_nEGwBPXY_DzxBf8HJ3R2ljv6R4s&e= >
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_supa&d=BQICAg&c=BFpWQw8bsuKpl1
> SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=4mENw6
> of-_UVUsUHR2rL3Sz3LMr1SnSv6ZgG-oD8Xnk&s=1dLn8TEyfCDS-GF-
> Dw6cUisU7HxDU7eBkeQsbGisWNM&e=

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 9 Aug 2015 19:30:27 +0200

I think we are messing up two different things, namely (a) what does a
policy mean and how is it leading to configuration changes and (b) who
is allowed to define policies, how are policies activated, when are
policies evaluated, etc.

I think both (a) and (b) are important and the text sounds like (a)
does not have to be precisely defined but (b) better is. I think both
need to be defined precisely enough to allow interoperable running
code.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 9 Aug 2015 17:39:36 +0000

Maybe. Can you give an example of (a) which is not (b)? Would help to understand what is missing. 

Regards,

Dan

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Sunday, August 09, 2015 8:30 PM
> To: Romascanu, Dan (Dan)
> Cc: Adrian Farrel; 'Benoit Claise'; 'Eggert, Lars'; [email-masked]
> I think we are messing up two different things, namely (a) what does a policy
> mean and how is it leading to configuration changes and (b) who is allowed to
> define policies, how are policies activated, when are policies evaluated, etc.
> 
> I think both (a) and (b) are important and the text sounds like (a) does not
> have to be precisely defined but (b) better is. I think both need to be defined
> precisely enough to allow interoperable running code.
> 
> /js
> 
> > We anticipate that processing that input will result in network
> > configuration changes. SUPA however will not deal with the definition
> > of the specific network configuration changes but with how the
> > configuration changes are applied (e.g. who is allowed to set
> > policies, when and how the policies are activated, changed or
> > de-activated)
> >
> > Regards,
> >
> > Dan
> >
> > > > I don't think I sourced the line of text you are asking about, but
> > > > I certainly reviewed it several times.
> > > >
> > > > > > 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
> > > > > I am not sure what the intend of the last sentence is. I hope
> > > > > that the semantics of the interface to the policy network
> > > > > management function are defined clearly enough that the
> > > > > translation of policy into network configuration changes is not a
> mystery.
> > > >
> > > > It was my view that the text was there to avoid exactly the
> > > > discussion we will now have :-)
> > > >
> > > > You say that you believe that the output of policy network
> > > > management function resulting from policy input will be clearly
> > > > defined configuration changes. It seems to me that this is often
> > > > likely, but not always the case. For example, if I was building
> > > > such a function I would make it stateful and I would expect it to
> > > > retain some policy state itself that it would then use to
> > > > determine how to process future
> > > policy instructions.
> > > >
> > > > For example, a simple policy is "who is allowed to set policy?"
> > > > You could, of course, push this down in the form of network
> > > > configuration, but I would tend to implement that piece of policy
> > > > within the network
> > > > The point, therefore, of the text is to say "Yup, Juergen is
> > > > probably right on this, but it is not actually the aim of the WG
> > > > to define how the policy network management function works or how
> > > > it responds to each
> > > clue how to really implement things (and I doubt two coders would
> > > have filled the void with the same interpretation). Perhaps this is
> > > just because we are in early stages but I personally would feel
> > > better if the charter would make it clear that we are not looking
> > > for high-level abstract blueprint descriptions of a policy function
> > > but rather something concrete and well defined that can lead to
> > > interoperate running code. To me, the sentence kind of legitimates high-
> level abstract blueprint models - even if this might not have been the
> intention.
> > >
> 2Duniversity.de_&d=BQIBAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31O
> cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3uyNMdscJLa783xPWEeFpd9mKjE
> Awj2Yn9IJYA6-RVg&s=YXS8MfmG3w-
> 2bRIwEHNfesClpkdiDYW0OHYBs5QL7G8&e= >

---

From: Andy Bierman <[email-masked]>
Date: Sun, 9 Aug 2015 10:41:39 -0700

On Sun, Aug 9, 2015 at 9:59 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> we will
> function
> could, of
> right on

The IETF has lots of experience with domain-specific data models.
We can agree on the knobs, bells, and whistles for almost anything.
This has specific standards value and can be accomplished in
a reasonable timeframe.

So what does charter item (1) really mean to this type of data model work?

So SUPA is delivering a policy-based management framework?

I am in favor of any progress towards standard framework and away from

a random collection of YANG modules. I'll take any attempt

at a "management system" as progress.

I don't understand the abstract policy deliverables very well.

That seems to be completely operator-programmed policy, not

standard or vendor provided data models.  If so, how does this

operator policy coexist with the "direct" policy data models?

I guess we have to wait for this document to find out.

IMO this abstract approach will not be cost effective when compared

to the direct data model approach.  You cannot just bury the

domain-specific complexity in implementation details.

A generic policy engine needs to be fully automated to be worthwhile.

> everybody else is happy with the sentence, simply ignore my email.
I am not concerned about constraining the "action" in ECA.
A policy monitoring application is just going to report policy violations
to humans and/or other applications.

Andy

---

From: Jon Saperia <[email-masked]>
Date: Sun, 9 Aug 2015 15:46:26 -0400

>> I guess we have to wait for this document to find out.
With out explicit instructions about how the policy is to be converted (mapped, translated, transformed, etc.) to specific device-specific domain models, the high level policy is of far less value. Without these automated methods of translation I don’t know how the desired results are achieved.
>> A generic policy engine needs to be fully automated to be worthwhile.
I agree.
/jon

> On Aug 9, 2015, at 1:41 PM, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> On Sun, Aug 9, 2015 at 9:59 AM, Juergen Schoenwaelder <[email-masked] <mailto:[email-masked]>> wrote:
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/ <http://www.jacobs-university.de/>>
> 
Thanks
/jon

---

From: John Strassner <[email-masked]>
Date: Sun, 9 Aug 2015 13:30:08 -0700

Hi Adrian,

I also do not think that there is any overlap between what SUPA has defined
and what NEMO has defined. SUPA provides a common model for
expressing imperative (e.g., event-condition-action, or ECA) and declarative
(e.g., goal-based, or "intent") policies. SUPA proposes that each of these
representations are realized as separate models, but are related through
their "common ancestry" (i.e., they were both derived from the same
superstructure). This means that each can use the other.

In addition, there are distinct differences between SUPA and NEMO:

  1) SUPA defines NETCONF or RESTCONF as its protocol. Period. In
      contrast, NEMO wants to define a new protocol.
  2) SUPA defines intent as declarative logic, and thus implements it
      using either propositional or first order logic (see section 3.2.4.,
      Mathematical Logic Terminology, of draft-strassner-supa-generic-
      policy-info-model). In contrast, NEMO defines implements its
      intent policy using condition-action (imperative) logic.
 3) SUPA is NOT working on a language. In contrast, NEMO is working
     on a language.

regards,
John

On Sun, Aug 9, 2015 at 8:23 AM, Adrian Farrel <[email-masked]> wrote:

> > So would this work prevent the formation of a WG that would do IBNEMO
> (Intent
> > Based NEtwork MOdeling)
> > IBNEMO intends (no pun intended) to define/standardize a Intent
> expression
> > language.
> services
> interface
> service
> > > in isolation, and often at timescales that require optimization for
> specific
> > purposes).
> > >
> > > a policy engine that maps a specific policy instance to actual
> configuration
> > snippets.
> > >
> > > List of work items:
> > >
> how
> > > The working group will communicate with other SDOs (MEF, TMF, ETSI)
> that are
> > working on related issues.
> > >
> > > Milestones:
> > >
> > > TBD
> > >
> > >
> > >
> > >

-- 
regards,
John

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Sun, 09 Aug 2015 22:42:26 +0200

Hi Adrian, inline

> Benoit has published says that SUPA is not the working group that works on
OK, that was certainly not so clear to me. Thanks for clarifying this. I am still abit worried about
the text:

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

So what does that last piece of the sentence "and may create a model accordingly" mean then?
> lifted out and placed in an IBNEMO work effort. That might be reasonable.
I think that makes sense to me too. But maybe we need more discussion on this.
In fact, Intent Based Network Modeling has already quite some traction (including code) in
Open Daylight projects. So they are quite active already in that space.
Standardizing a language to express intent seems something that a WG in IETF could very well
work on, actually pretty soon.  AS we discussued in our barbof in Prague.
> existing languages or whether new work is needed a priori.
In fact, in IBNEMO we realize that we need to use (or define maybe) some YANG data models
that would allow us to translate "intent expressions" into actual network-wide, conroller-wide
or device-specific data models. We would use any existing data models if at laa possibl.
But we do need some data models in order to prove that our expression language can work and
be implemented in interoperable code.
> would not preclude IBNEMO inventing something different/better/worse.
RIght, but my personal preference would be to try and see if we can use existing YANG data models
> information models) that doesn't seem like a bad thing.
Could be I guess
> out from day one, I will not be complaining.
And I think some of that work has already started, although still at an indiviadual-draft level.

Bert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 9 Aug 2015 22:55:03 +0200

I thought it is obvious...

Example for (a):

  P1: All edge routers shall have SSH disabled.

Example for (b)

  P2: Only users who are edge-admins are allowd to insert policies
      affecting edge routers.

  P3: P1 is not active during maintenance hours.

P1 requires access to topology information and a way to modify the
configuration disabling SSH. P2 is a policy rule constraining who is
allowed to insert certain policy rules. P3 is a policy rule
controlling the activation (and implicitely the deactivation) of a
policy rule. P1 will affect device configurations, P2 and P3 might
only be visible to the policy function.

All I want is that policies of both types are clearly defined such
that the policy function can be implemented in an interoperable way
and I do not see why the charter should include phrases that weaken
this requirement.

/js

---

From: John Strassner <[email-masked]>
Date: Sun, 9 Aug 2015 13:58:31 -0700

Hi,

> Your comment on (3) is interesting.   I do not think there is any
> expectation of programming in Yang.  I did have some thoughts
> like that in Prague, as the policies (as I understood them and I
> might have this wrong) are in the form of First Order Logic
> statements.  If at a fine enough granularity,  perhaps they could
> be strung together and processed as statements are in Prolog.

Remember that SUPA defines a framework for both imperative
(e.g., event-condition-action) and declarative policies. I think that
mapping the former to YANG is easier than the latter, since
additional semantics (e.g., some system of inference rules and
axioms must be supplied, along with the ability to ensure that
formulae are well-formed (e.g., restricted stratification).

Put another way:

  1) for ECA, YANG data models should be able to be directly produced
  2) for declarative policies, I would first send to a logic evaluation
      function, and then send the output to produce YANG data models

regards,
John

On Sat, Aug 8, 2015 at 12:01 PM, Andrew Veitch <[email-masked]
> wrote:

> Hi Andy,
>
> Your comment on (3) is interesting.   I do not think there is any
> expectation of programming in Yang.  I did have some thoughts like that in
> Prague, as the policies (as I understood them and i might have this wrong)
> are in the form of First Order Logic statements.  If at a fine enough
> granularity,  perhaps they could be strung together and processed as
> statements are in Prolog.
>
> But I believe the intention, buttressed by my reading of the term “high
> level … policies” (I take that very seriously) in the charter, is that
> these define high-level policies and a policy engine (or whatever) would
> process them and use scripts, or rules, or whatever, to figure out how to
> support them (also specifically listed as out of scope.)
>
> My hope for SUPA is what you listed up front, and I think it could
> deliver: providing a piece for the coherent approach to data models.  And
> it seems like SUPA could deliver a common form for representing policy,
> with specializations for ECA and/or Declarative as needed.
>
> I agree, milestones are a must.  I think the TBD is just that, perhaps
> these can be easily addressed after the first part is settled.
>
> Best regards,
>
> Andy
>
>
>
> Andrew Veitch | Mobile: +1 (781) 366-7763 | www.
> <http://www.NetCracker.com>Net <http://www.NetCracker.com>Cracker
> <http://www.NetCracker.com>.com <http://www.NetCracker.com> >>>> * Proven
> Partner to Communications Service Providers*
>
> On Aug 8, 2015, at 1:48 PM, Andy Bierman <[email-masked]> wrote:
>
> Hi,
>
>> data models.
>> different levels of abstraction.  Specifically, three model fragments
>> are envisioned: (i) a generic model that defines concepts and vocabulary
>> 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
>> -   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
> ------------------------------
> The information transmitted herein is intended only for the person or
> entity to which it is addressed and may contain confidential, proprietary
> and/or privileged material. Any review, retransmission, dissemination or
> other use of, or taking of any action in reliance upon, this information by
> persons or entities other than the intended recipient is prohibited. If you
> received this in error, please contact the sender and delete the material
> from any computer.
>
>

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Sun, 9 Aug 2015 14:04:07 -0700

I agree with Jon.

During the BoF, I committed to finishing the info model quickly (within 3
months, but should be faster). Given this, I think that whatever role the
info model has to play is done before the end of the year.

Regarding the data model, I think that a few people that have built these
things before should get together (hopefully before Tokyo, but possibly
during Tokyo) and build a proposal (if SUPA is indeed chartered, of
course). That proposal should include a realistic schedule, which could
then feed back into the charter.

I'm all for trying to do the data model meeting earlier, perhaps in late
September or early October, if people want.

regards,
John

On Sat, Aug 8, 2015 at 12:45 PM, Jon Saperia <[email-masked]> wrote:

> My read of deliverable 3 is that this model is also still abstract.  It
> ‘extends’ the base model with information about the specific types of
> policy they define.  They are not concrete.
>
> After all this work is completed, without concrete examples and rules
> about conversion from these policies into configuration data for systems,
> interoperation will be problematic.  Over the years policy efforts that I
> am aware of have remained ‘high level’ without tackling the difficult and
> more important problem of defining an approach for taking policy and
> translating it into something different systems using different
> technologies could use.  Without this, the value of the working group
> declines significantly.
>
> /jon
>
> <http://www.netcracker.com/>Net <http://www.netcracker.com/>Cracker
> <http://www.netcracker.com/>.com <http://www.netcracker.com/> >>>> * Proven

-- 
regards,
John

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Sun, 09 Aug 2015 23:23:50 +0200

John, Inline,

> superstructure). This means that each can use the other.
OK, that sounds good to me.

>       contrast, NEMO wants to define a new protocol.
I do not know what makes you say so.
I think we have left it open sofar as to whether we want/need a new protocol or not.
Preferably we can use Netconf/Restconf. But I think that is all still open to discussion.
>       intent policy using condition-action (imperative) logic.
Again I do not understand why you think so.
I have not seen any ECA stuff in IBNEMO yet.
But then, maybe you can point me to it if you have.
>  3) SUPA is NOT working on a language. In contrast, NEMO is working
Yep, we would like to work on an "intent expression language" in IBNEMO.

Bert
>
> regards,
> John
>
> On Sun, Aug 9, 2015 at 8:23 AM, Adrian Farrel <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Bert,
>
>     > From: Supa [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Bert Wijnen (IETF)
>     > To: Benoit Claise; [email-masked] <mailto:[email-masked]>
>     > Cc: Eggert, Lars; [email-masked] <mailto:[email-masked]>

---

From: John Strassner <[email-masked]>
Date: Sun, 9 Aug 2015 14:25:19 -0700

I agree with Juergen. I think the model defined in #2 MUST be
generic, regardless of whether an info model is used to create
it or not. That being said, in order to achieve interoperability,
we need concrete, domain-specific data models and running
code. I would support tightening this statement.

regards,
John

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Sun, 9 Aug 2015 14:59:21 -0700

Bert,

please see inline.

In addition, there are distinct differences between SUPA and NEMO:

>>  1) SUPA defines NETCONF or RESTCONF as its protocol. Period.
>>  In contrast, NEMO wants to define a new protocol.

> Preferably we can use Netconf/Restconf. But I think that is all still

<jcs>
What makes me say so is a combination of
  1) listening to previous NEMO presentations in other fora
  2) various sentences in the IBNEMO Bar BoF presentation
      (e.g., "Question: scripts over http workable, Not sure
       RESTCONF rpc + pub.sub level needed",
  3) Statements such as "Synergistic means that sum of Intent Based
      NEMO protocol + NETCONF + RESTCONF + I2RS +PCE is more
      than any of the parts alone" and "creating protocol with minimal
      operations for to express intent from the application to the network".
      both from draft-hares-ibnemo-overview-01
  4) a mail from Sue on 7/17 to the NEMO and SUPA lists, that said
      "IBNemo’s 15 specific commands are better than NETCONF
        or RESTCONF commands"
I can give you many more examples...
</jcs>

>> 2) SUPA defines intent as declarative logic, and thus implements
>> it using either propositional or first order logic (see section 3.2.4.,

> But then, maybe you can point me to it if you have.

<jcs>
I said "condition-action", NOT ECA.
Please look at draft-xia-sdnrg-nemo-language-02, which says:
"All the policies follow the same pattern "when <condition>, to
execute <action>, with <constraint>", and can be applied to any entity."
</jcs>

On Sun, Aug 9, 2015 at 2:23 PM, Bert Wijnen (IETF) <[email-masked]>
wrote:

>>     > From: Supa [mailto:[email-masked] <mailto:
>> [email-masked]>] On Behalf Of Bert Wijnen (IETF)
>>     > So would this work prevent the formation of a WG that would do
>> IBNEMO (Intent
>>     > Based NEtwork MOdeling)
>> building
>> possibly network-
>>     > > in isolation, and often at timescales that require optimization
>> for specific
>>     > purposes).
>>     > >
>>     > > The working group will communicate with other SDOs (MEF, TMF,
>> ETSI) that are

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Sun, 9 Aug 2015 15:22:52 -0700

> I think we are messing up two different things, namely (a) what
> does a policy mean and how is it leading to configuration changes
> and (b) who is allowed to define policies, how are policies activated,
> when are policies evaluated, etc.
>

<jcs>
Agreed. That is why I thought we had separated (in the old charter)
deliverable #1 (framework document) from #2 and #3 (info and
data model) and from #4 (applicability document).

In the new charter, #1 is largely the same (minus the "framework"
qualifier. #2 is made optional, and #3 makes the declarative policy
deliverable a "may". #4 is the same.

I think that (a) maps to deliverables #2 and #3, while (b) maps to
deliverable #4 (and possibly deliverable #1).
</jcs>

>> configuration changes.

<jcs>
The problem is that policies will sometimes do this directly
(e.g., defining an ACL or a service chain), sometimes indirectly
(e.g., a declarative policy that says "Load balancing shall be
applied to traffic for which any CPU that exceeds 70%
utilization"), and sometimes, not at all (e.g., "Policies that
affect Gold Customers can only be written, deleted, or
executed by users that are members of both the
NetworkAdmin role and the CustomerGold role).

In order to be effective, SUPA should create policies of
all three types.
</jcs>

>> SUPA however will not deal with the
>> definition of the specific network configuration changes

<jcs>
This means that SUPA cannot demonstrate interoperable
solutions, as well as concrete solutions.

>> but with how the configuration changes are applied
>> (e.g. who is allowed to set policies, when and how
>> the policies are activated, changed or de-activated)

<jcs>
Dealt with above...
</jcs>

On Sun, Aug 9, 2015 at 10:30 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> configuration changes. SUPA however will not deal with the definition of
> the specific network configuration changes but with how the configuration
> changes are applied (e.g. who is allowed to set policies, when and how the
> policies are activated, changed or de-activated)
> >
> > Regards,
> >
> > Dan
> >
> what the
> interoperate
> abstract
> everybody

-- 
regards,
John

---

From: "Leroux, Francois" <[email-masked]>
Date: Mon, 10 Aug 2015 05:04:28 +0000

Benoit, et al,
Our initial reaction after reading the revised charter was that it was clear and precise. The objectives are well explained and understandable even by people who are not familiar with the history of the group.
I gathered two immediate comments:

1)       “-   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.”

The term “configuration snippets” maybe too specific as it is conceivable that the outcome of a policy evaluation could affect some behavior in the management and control layer, which may or may not involve actual NE/NF/vNF level changes (assuming this is what configuration snippets is referring to).

2)      “The working group will communicate with other SDOs (MEF, TMF, ETSI) that are working on related issues.”

The list of SDOs should include ONF or just not mention any specific ones. “Intent NBI” specifically has become a highly debated topic within ONF. Please see the attached message suggesting a new organization aimed at accelerating this work with modeling activities (possibly similar to SUPA’s) done under the ONF framework group. An Intent NBI implementation would certainly benefit from a unified information/data modeling framework aimed at expressing (and possibly mixing) different types of policy through well defined abstractions.
Best regards,
François Leroux
--
Fujitsu Network Communications
2801 Telecom Pkwy
Richardson, TX 75082

From: Supa [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Friday, August 07, 2015 11:03 AM
To: [email-masked]
Cc: Eggert, Lars
Subject: [Supa] SUPA charter proposal

Dear all,

Regards, Benoit (OPS AD)

Milestones: TBD

Subject: [NBI] Intent NBI: Special topic for call this Wednesday, August 12th at 08:00 Pacific
From: "Janz, Chris" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 10 Aug 2015 00:12:00 +0000
List-Id: nbi <nbi.login.opennetworking.org>

Intent NBI Sub-Group Participants:

On our Wednesday August 12th 08:00 Pacific call (please contact me if you need webex details) we will discuss a proposal to move the Intent NBI Sub-Group’s work from the ONF framework to the Open Source SDN (sponsored by ONF) framework.  The proposal unites Intent NBI code work under the Boulder project (Open Source SDN framework) with the “theory” work now being done under the ONF framework, within one, open umbrella (i.e., Boulder.)

The reason to do this is simple: we want the wide community of implementation projects to benefit early – immediately – from the principles we are now stabilizing and the information model we are now developing.  This will benefit the entire community and secure the maximum impact of the work we are doing.  Additionally, we would benefit from the opportunity to participate in the discussions afforded to individuals who may not work for ONF member companies.

I’ve attached a document that shows the relative “terms and conditions” of the various ONF and ONF-associated frameworks.  Long and short: anti-trust provisions would continue to apply; IPR and liaison guidelines (and restrictions) would not.

In practice: we would have a new (open) e-mailer, new (open) calls, and our document drafts would be posted in a new (openly accessible) place with different labeling and “terms.”  Such terms would not in fact differ from those attached to ONF Technical Requirements (versus Specification) documents.  We’d seek agreement also to post draft documents from related ONF Working Groups and Sub-Groups that would be useful as references. There will be nothing new for ONF members (or anyone else) to “sign” other than relating to submissions of code artifacts, where applicable.

Rick Bauer and Reda Habib will be on the call to walk us through the provisions, answer any questions, and help take feedback, receive any concerns and get things moving.  Please join.

Regards

Chris Janz

Vice-Chair, Intent NBI Sub-Group

---

From: <[email-masked]>
Date: Mon, 10 Aug 2015 08:24:29 +0000

Dear all,
Thanks to Benoit for posting this new charter text, which I find, like many others, clearer than previous versions.
I too agree with Juergen (e.g., based upon the P1/P2/P3 example he provided in the message sent yesterday) about the need for the charter to be explicit about what is a policy and how its enforcement can possibly lead to configuration changes and who’s entitled to define policies and decide when these policies should be enforced and by what kind of PEP.
I also have a few comments inline – see below.
[snip]
==============================================================
SUPA CHARTER PROPOSAL (2015-08-07)

[CJ] I would suggest an additional introductory sentence about what policies are, maybe something like: “Policies are a set of rules that define how services are designed, delivered and operated within an operator’s networking environment.” And then:
OLD:
Policy is an important configurable component in the delivery of services and the operation of networks.
NEW:
As such, policies play a critical role in the automated service delivery and operational procedures.
Operators want and need to be able to determine
[CJ] s/determine/define?
the policies that apply to their different customers and to the equipment that comprises their physical and virtual networks. As policy spans
[CJ] I would use plural – s/policy/policies and then:
OLD:
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.
NEW:
Policies usually span a wide range of services that are supported by various technologies: thus, a common way for expressing and describing policies that is uniform and consistent regardless of the nature of the networking environment is likely to facilitate the overall service delivery procedure and operation.
Such an approach will help to avoid configuration errors
[CJ] or “will minimize the risk of configuration errors”, since the dynamic enforcement of well-defined policies is probably insufficient to guarantee that no configuration error is likely to occur: this is in particular what service fulfillment assurance and other feedback mechanisms are about – make sure that what has been delivered complies with what has been possibly negotiated with the customer, for example.
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.

The SUPA working group will develop a model for expressing policy at different levels of abstraction.  Specifically, three model fragments
[CJ] Like Andrew V., I would remove “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.
[CJ] Not sure I understand item #3, especially the notion of “practicality” that reads a bit vague to me. Also, does the intent-based policy wording suggest some kind of (dynamic service parameter) negotiation capabilities between the customer/app and the service provider – e.g., taking the bandwidth-on-demand example described in Section 4.3 of  draft-hares-ibnemo-overview-01, does this suggest that (1) the intent is “I need 10G from 08:00 AM to 06:00 PM and (2) the intent triggers a negotiation cycle like “I don’t have 10G but can provide 8G during the same epoch”, etc. (you may want to take a look at this draft<https://datatracker.ietf.org/doc/draft-boucadair-connectivity-provisioning-protocol/> for further details about what such a negotiation could look like)? I would clarify the text accordingly.

[CJ] Not sure I understand the second part of the above sentence, which seems to somewhat contradict the purpose of the SUPA model mentioned above at the risk of jeopardizing the overall consistency between the configuration changes that may result from the enforcement of the policy defined from the SUPA model and the behavior of the NE that may result from the enforcement of these embedded policies. An example of such possible inconsistency that comes to my mind is the enforcement of a traffic engineering policy network-wide that could in particular result in specific metric settings applied by participating nodes and the possible decisions made by some kind of LPDP embedded in some of these nodes that would result in modifying some of these metrics without informing the (logically centralized) controller because the “embedded policy is usually interpreted in isolation”. Maybe an example of the required optimization as a function of the timescales involved would help clarify the sentence.

Cheers,
[CJ] Christian.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 10 Aug 2015 09:04:58 +0000

I also believe that Juergen’s example clarified the type of policies that SUPA needs to support.
I suggest that Juergen continues to hold the pen for the charter text. I think that we need to keep the changes to Benoit’s proposed text to the minimum critical ones, and add milestones.
Regards,

Dan

From: Supa [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, August 10, 2015 11:24 AM
To: Benoit Claise; [email-masked]
Cc: Eggert, Lars
Subject: Re: [Supa] SUPA charter proposal

Dear all,

The SUPA working group will develop a model for expressing policy at different levels of abstraction.  Specifically, three model fragments
[CJ] Like Andrew V., I would remove “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.
[CJ] Not sure I understand item #3, especially the notion of “practicality” that reads a bit vague to me. Also, does the intent-based policy wording suggest some kind of (dynamic service parameter) negotiation capabilities between the customer/app and the service provider – e.g., taking the bandwidth-on-demand example described in Section 4.3 of  draft-hares-ibnemo-overview-01, does this suggest that (1) the intent is “I need 10G from 08:00 AM to 06:00 PM and (2) the intent triggers a negotiation cycle like “I don’t have 10G but can provide 8G during the same epoch”, etc. (you may want to take a look at this draft<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dboucadair-2Dconnectivity-2Dprovisioning-2Dprotocol_&d=BQMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=wanW2TcXNb87A4cL5eKEC-xUcRcad3kJ-ZX4BEiQTes&s=FfLv1xFmt9_Y5kOj16erC2imc81zI54oVfzxOb4TlY4&e=> for further details about what such a negotiation could look like)? I would clarify the text accordingly.

Cheers,
[CJ] Christian.

Thank you.

---

From: Tina TSOU <[email-masked]>
Date: Mon, 10 Aug 2015 09:22:52 +0000

Dear all,

Agreed.

In addition, attached is the diff between charter proposal version 2015-08-07 and 2015-06-15.

Thank you,
Tina

From: Supa [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Monday, August 10, 2015 5:05 PM
To: [email-masked]; Benoit Claise; [email-masked]
Cc: Eggert, Lars
Subject: Re: [Supa] SUPA charter proposal

Dan

From: Supa [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, August 10, 2015 11:24 AM
To: Benoit Claise; [email-masked]<mailto:[email-masked]>
Cc: Eggert, Lars
Subject: Re: [Supa] SUPA charter proposal

Dear all,

Cheers,
[CJ] Christian.

Thank you.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 10 Aug 2015 12:38:16 +0200

I prefer someone else does it since I am mostly on vacation and I
already had my share of charter text wordsmithing - others probably
like to have this experience as well.

/js

---

From: Maxim Klyus <[email-masked]>
Date: Mon, 10 Aug 2015 12:45:37 +0000

Hi Benoit et al,

I would like to say thank you for the charter clarification.

Also I agreed with comments provided by Juergen about policy types.

So my suggestion will be add the following sentences:

“The SUPA framework defines how to construct policy rules for Environment and Administrative layers within one or more Management domains, where Environment layer describes functional configuration policies for domain network elements (specific protocols, functions) and Administrative layer describes administrative non-functional access/management policies across domain network elements (user privileges, administrative states).“

Best Regards,
Maxim Klyus

From: Supa [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Friday, August 07, 2015 7:03 PM
To: [email-masked]
Cc: Eggert, Lars
Subject: [Supa] SUPA charter proposal

Dear all,

Regards, Benoit (OPS AD)

List of work items:

Milestones:

TBD

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 10 Aug 2015 18:16:49 -0400

John: 

To respond to the following part of your discussion with Bert: 

<jcs>

1)      listening to previous NEMO presentations in other forum 

<sue> 

I’m glad you’ve listen to Nemo presentations at other forums

</sue> 

<sue> 

It is this statement that Bert is alluding to.  We are open to using a transport mechanism from http, or RESTCONF with various forms to carry the Nemo commands.  

</sue> 

<sue>: The key point here is the Nemo commands (connection, plus language commands enable the user to ask for connection with easy human language for the end-user. 

</sue> 

        or RESTCONF commands"

<sue> The reason these 15 commands are better is that these commands are targeted the end-user for network-wide commands.  The Netconf/restconf commands are focused at the device level.  

</sue> 

</jcs>

 

From: Ibnemo [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Sunday, August 09, 2015 5:59 PM
To: Bert Wijnen (IETF)
Cc: Adrian Farrel; Eggert, Lars; [email-masked]; [email-masked]
Subject: Re: [Ibnemo] [Supa] SUPA charter proposal

Bert,

please see inline.

> I think we have left it open sofar as to whether we want/need a new

> protocol or not.
> Preferably we can use Netconf/Restconf. But I think that is all still

> open to discussion.

<jcs>

        or RESTCONF commands"

</jcs>

<jcs>

</jcs>

On Sun, Aug 9, 2015 at 2:23 PM, Bert Wijnen (IETF) <[email-masked]> wrote:

John, Inline,

Hi Adrian,

Bert

regards,
John

    Hi Bert,

    Cheers,
    Adrian

    policy rules
    here
    acceptable to
    and
    and
    device
    will
    with a
    in
    which
    data
    different
    investigate
    "intent-based"
    before
    policies in
    provide
    composed
    representing
    according to
    intent-based,

-- 
regards,
John

-- 

regards,

John

---

From: aldrin ietf <[email-masked]>
Date: Mon, 10 Aug 2015 16:06:46 -0700

Hi Benoit and others,

I have looked at the proposed charter, much better, thank you. Please find my comments inline.
Haven’t had time to read others comments. Hence, some of them could be repeat.
[O] - original
[S] - suggested
[Q] - question

Cheers
-sam
> 
> Subject:	SUPA charter proposal
> Date:	Fri, 7 Aug 2015 18:03:13 +0200
> From:	Benoit Claise <[email-masked]> <mailto:[email-masked]>
> To:	[email-masked] <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>
> CC:	Eggert, Lars <[email-masked]> <mailto:[email-masked]>
> 
> Dear all,
> 
[O]
> 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.
<S> Operators want and need to be able to determine, configure and manage various policies, applicable to both physical and virtual networks, in order to meet various customer and network requirements.

[O]
> 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.
[R] As policy spans 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 various environments.

[O]
> 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.
[R] Such an approach will enable uniformity and easy understanding of policies that apply in different environments, thereby minimizing configuration errors that arise from confusion between different systems. This will quicken  the implementation of policy-based systems, and facilitates the rapid development of standards-based data models that include policy elements.

> 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. 
[Q] Is SUPA going to create/generate models, for ex: Service models, which are not defined anywhere? Also, I am presuming here that it is SUPA WG here and NOT SUPA function. Clarification to remove the ambiguity could help.

Suggested Text> Models, which are not defined in any WG, will be identified but definition of those models is not within the scope. (something along those line could help)

> 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…
[Q] For (i) - the deliverable is Informational model as identified below as #2, correct?
[Q] For (ii) and (iii) - The deliverable is YANG, correct?
> 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 in…

[Q] I see that problem statement and usecase documents are not mentioned as deliverables, explicitly. What exactly will be #1 deliverable?

thanks
-sam

---

From: Andrew Qu <[email-masked]>
Date: Mon, 10 Aug 2015 23:32:49 +0000

Hi Benoit,
Thanks for writing up the proposal.  With so many open or privately developed network controllers, service
Orchestration tools, it is crucial to have a working group like SUPA to design/define a model/(set of languages) to
make various services like SaaS/IaaS/NaaS etc possibly integrated on heterogeneously developed hardwares/controllers/orchestration tools.
I’d like to contribute to SUPA in various tasks.
Thanks,
Andrew

From: Supa [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Friday, August 07, 2015 9:03 AM
To: [email-masked]
Cc: Eggert, Lars
Subject: [Supa] SUPA charter proposal

Dear all,

Regards, Benoit (OPS AD)

List of work items:

Milestones:

TBD

---

From: Qiong <[email-masked]>
Date: Tue, 11 Aug 2015 14:37:30 +0800

Hi Benoit,

I like this version of charter. I think it is an important work to define a
generic data model to encode policy. I will be interested to join this work
in the future.

One question: 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.
Do we have recommended use case for these examples ? Or we do not restrict
the scenario for which the policy models can be used ?

Thanks!

Best wishes
Qiong

China Telecom

-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude

Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/
<http://sourceforge.net/projects/laft6/>*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/
<http://sourceforge.net/projects/pcpportsetdemo/> *
===============================================

---

From: Xiaohong Deng <[email-masked]>
Date: Tue, 11 Aug 2015 09:15:27 +0000

Dear Benoit and all,

Thanks for all the efforts putting together this chapter. I see this is a fine start of providing an appropriate place to address policy issues in IETF.

My understanding is that the current chapter doesn't differentiate between inter-domain and cross-domain. Please correct me if I'm wrong. Though it may be too early to point out and may not necessary to address that in the chapter at this stage, from our past experience in SDN, cross-domain scenario does have different use cases than inter-domain. And I am personally keen to see cross-domain framework to be addressed. Thoughts?

Cheers,
Xiaohong

School of Electric Engineering and Telecom,
University of New South Wales, Australia

________________________________
From: Supa [[email-masked]] on behalf of Benoit Claise [[email-masked]]
Sent: 08 August 2015 02:03
To: [email-masked]
Cc: Eggert, Lars
Subject: [Supa] SUPA charter proposal

Dear all,

Regards, Benoit (OPS AD)

List of work items:

Milestones:

TBD

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 11 Aug 2015 12:05:59 +0000

Hi all,
Thanks Benoit for the new version.
Looking at Maxim email, I wonder if it could be appropriate to distinguish also policy rules for resources (e.g., “not use this kind of resource”, so resource or device oriented) apart from the configuration rules (related to control plane in my view, then service oriented) and management (related to management plane, then administrative oriented).
Best regards
Luis

De: Supa [mailto:[email-masked]] En nombre de Maxim Klyus
Enviado el: lunes, 10 de agosto de 2015 14:46
Para: Benoit Claise; [email-masked]
CC: Juergen Schoenwaelder ([email-masked]); Eggert, Lars
Asunto: Re: [Supa] SUPA charter proposal

Hi Benoit et al,

Best Regards,
Maxim Klyus

From: Supa [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Friday, August 07, 2015 7:03 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Eggert, Lars
Subject: [Supa] SUPA charter proposal

Dear all,

Regards, Benoit (OPS AD)

List of work items:

Milestones:

TBD

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 11 Aug 2015 12:09:29 +0000

Hi Xiaohong
This is a point of interest, maybe early to be addressed now, but certainly of interest.
Maybe the same mechanisms/methods could be used for interchanging policies between distinct operators to setup multi-domain services. Also, the multi-domain issues could happen within the internals of a network of a single operators, or between distinct companies of the same operator.
So, it is definitely of interest, I think.
Best regards
Luis

De: Supa [mailto:[email-masked]] En nombre de Xiaohong Deng
Enviado el: martes, 11 de agosto de 2015 11:15
Para: Benoit Claise; [email-masked]
CC: Eggert, Lars
Asunto: Re: [Supa] SUPA charter proposal

Dear Benoit and all,

Cheers,
Xiaohong

Regards, Benoit (OPS AD)

List of work items:

Milestones:

TBD

---

From: John Strassner <[email-masked]>
Date: Tue, 11 Aug 2015 09:23:18 -0700

Hi Christian,

I have three comments to your review:

[CJ] Like Andrew V., I would remove “fragments”.
<jcs>
The purpose of "fragments" was to emphasize the fact that this model was
NOT designed as an all-encompassing model. Rather, it was designed as a
portion of a model that could be fit into another model. For example,
neither the CIM nor the SID posses this capability.
</jcs>

[CJ] Not sure I understand item #3, especially the notion of “practicality”
that reads a bit vague to me. Also, does the intent-based policy wording
suggest some kind of (dynamic service parameter) negotiation capabilities
between the customer/app and the service provider – e.g., taking the
bandwidth-on-demand example described in Section 4.3 of
 draft-hares-ibnemo-overview-01, does this suggest that (1) the intent is
“I need 10G from 08:00 AM to 06:00 PM and (2) the intent triggers a
negotiation cycle like “I don’t have 10G but can provide 8G during the same
epoch”, etc. (you may want to take a look at this draft
<https://datatracker.ietf.org/doc/draft-boucadair-connectivity-provisioning-protocol/>
for further details about what such a negotiation could look like)? I would
clarify the text accordingly.
<jcs>
Intent was defined in SUPA to be declarative, and was made up of either
propositional logic or first order logic statements.
In the ONF, we took this definition and added the ability to negotiate,
much like what you described.

I think that the charter editors were worried that pure declarative
programming would not be easily expressible in YANG (hence, the "may create
a model accordingly"). I actually think that the solution would be to keep
the declarative model in its pure form (i.e., not YANG), feed it to a logic
evaluation program, and then use the output of the logic program to create
a YANG model. That way, YANG doesn't have to deal with the requirements of
logic-based computation.
</jcs>

[CJ] Not sure I understand the second part of the above sentence, which
seems to somewhat contradict the purpose of the SUPA model mentioned above
at the risk of jeopardizing the overall consistency between the
configuration changes that may result from the enforcement of the policy
defined from the SUPA model and the behavior of the NE that may result from
the enforcement of these embedded policies. An example of such possible
inconsistency that comes to my mind is the enforcement of a traffic
engineering policy network-wide that could in particular result in specific
metric settings applied by participating nodes and the possible decisions
made by some kind of LPDP embedded in some of these nodes that would result
in modifying some of these metrics without informing the (logically
centralized) controller because the “embedded policy is usually interpreted
in isolation”. Maybe an example of the required optimization as a function
of the timescales involved would help clarify the sentence.

<jcs>

The latter part that you question has its roots in the old charter (6/15),
which differentiated between "management policies" and "embedded policies".
The main difference is that management policies can be interpreted outside
of NEs, whereas embedded policies are typically interpreted in the NE. I
think that what is confusing you (and I agree with you) is the word
"isolation". Embedded policies are typically authored outside of the NE but
then executed inside the NE, so they are not "isolated" in the literal
sense.

What confuses me is "Design of protocol-specific policies". I can't parse
this phrase.

</jcs>

regards,

John

On Mon, Aug 10, 2015 at 1:24 AM, <[email-masked]> wrote:

> Dear all,
>
> Thanks to Benoit for posting this new charter text, which I find, like
> many others, clearer than previous versions.
>
> I too agree with Juergen (e.g., based upon the P1/P2/P3 example he
> provided in the message sent yesterday) about the need for the charter to
> be explicit about what is a policy and how its enforcement can possibly
> lead to configuration changes and who’s entitled to define policies and
> decide when these policies should be enforced and by what kind of PEP.
>
> [CJ] I would suggest an additional introductory sentence about what
> policies are, maybe something like: “Policies are a set of rules that
> define how services are designed, delivered and operated within an
> operator’s networking environment.” And then:
>
> OLD:
>
> and the operation of networks.
>
> NEW:
>
> 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
> and consistent in all environments.
>
> NEW:
>
> Policies usually span a wide range of services that are supported by
> various technologies: thus, a common way for expressing and describing
> policies that is uniform and consistent regardless of the nature of the
> networking environment is likely to facilitate the overall service delivery
> procedure and operation.
>
> [CJ] or “will minimize the risk of configuration errors”, since the
> dynamic enforcement of well-defined policies is probably insufficient to
> guarantee that no configuration error is likely to occur: this is in
> particular what service fulfillment assurance and other feedback mechanisms
> are about – make sure that what has been delivered complies with what has
> been possibly negotiated with the customer, for example.
>
> 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
> [CJ] Not sure I understand item #3, especially the notion of
> “practicality” that reads a bit vague to me. Also, does the intent-based
> policy wording suggest some kind of (dynamic service parameter) negotiation
> capabilities between the customer/app and the service provider – e.g.,
> taking the bandwidth-on-demand example described in Section 4.3 of
>  draft-hares-ibnemo-overview-01, does this suggest that (1) the intent is
> “I need 10G from 08:00 AM to 06:00 PM and (2) the intent triggers a
> negotiation cycle like “I don’t have 10G but can provide 8G during the same
> epoch”, etc. (you may want to take a look at this draft
> <https://datatracker.ietf.org/doc/draft-boucadair-connectivity-provisioning-protocol/>
> for further details about what such a negotiation could look like)? I would
> clarify the text accordingly.
>
>
>
> [CJ] Not sure I understand the second part of the above sentence, which
> seems to somewhat contradict the purpose of the SUPA model mentioned above
> at the risk of jeopardizing the overall consistency between the
> configuration changes that may result from the enforcement of the policy
> defined from the SUPA model and the behavior of the NE that may result from
> the enforcement of these embedded policies. An example of such possible
> inconsistency that comes to my mind is the enforcement of a traffic
> engineering policy network-wide that could in particular result in specific
> metric settings applied by participating nodes and the possible decisions
> made by some kind of LPDP embedded in some of these nodes that would result
> in modifying some of these metrics without informing the (logically
> centralized) controller because the “embedded policy is usually interpreted
> in isolation”. Maybe an example of the required optimization as a function
> of the timescales involved would help clarify the sentence.
>

-- 
regards,
John

---

From: <[email-masked]>
Date: Tue, 11 Aug 2015 16:58:33 +0000

Hello John,

Thanks for the clarification – a few additional comments inline.

[snip]
[CJ] Like Andrew V., I would remove “fragments”.
<jcs>
The purpose of "fragments" was to emphasize the fact that this model was NOT designed as an all-encompassing model. Rather, it was designed as a portion of a model that could be fit into another model. For example, neither the CIM nor the SID posses this capability.
</jcs>
[CJ] Agreed, but I would then suggest that the charter includes your “this model is not designed as an all-encompassing model” sentence above, which gracefully avoids the confusion introduced by the “fragment” wording imho.

[CJ] Not sure I understand item #3, especially the notion of “practicality” that reads a bit vague to me. Also, does the intent-based policy wording suggest some kind of (dynamic service parameter) negotiation capabilities between the customer/app and the service provider – e.g., taking the bandwidth-on-demand example described in Section 4.3 of  draft-hares-ibnemo-overview-01, does this suggest that (1) the intent is “I need 10G from 08:00 AM to 06:00 PM and (2) the intent triggers a negotiation cycle like “I don’t have 10G but can provide 8G during the same epoch”, etc. (you may want to take a look at this draft<https://datatracker.ietf.org/doc/draft-boucadair-connectivity-provisioning-protocol/> for further details about what such a negotiation could look like)? I would clarify the text accordingly.
<jcs>
Intent was defined in SUPA to be declarative, and was made up of either propositional logic or first order logic statements.
In the ONF, we took this definition and added the ability to negotiate, much like what you described.

I think that the charter editors were worried that pure declarative programming would not be easily expressible in YANG (hence, the "may create a model accordingly"). I actually think that the solution would be to keep the declarative model in its pure form (i.e., not YANG), feed it to a logic evaluation program, and then use the output of the logic program to create a YANG model. That way, YANG doesn't have to deal with the requirements of logic-based computation.
</jcs>
[CJ] I fully agree with you: as a matter of fact, I believe this computation logic will naturally “feed” the YANG model from which policy provisioning information will be derived accordingly. I think this is an essential part of the overall service delivery procedure as we see it. I hope a possibly updated version of the charter will reflect this approach.

<jcs>

The latter part that you question has its roots in the old charter (6/15), which differentiated between "management policies" and "embedded policies". The main difference is that management policies can be interpreted outside of NEs, whereas embedded policies are typically interpreted in the NE. I think that what is confusing you (and I agree with you) is the word "isolation". Embedded policies are typically authored outside of the NE but then executed inside the NE, so they are not "isolated" in the literal sense.

[CJ] Exactly.

What confuses me is "Design of protocol-specific policies". I can't parse this phrase.

[CJ] Neither can I.

</jcs>

[CJ] Cheers,

[CJ] Christian.

---

From: Xiaohong Deng <[email-masked]>
Date: Wed, 12 Aug 2015 05:42:55 +0000

Hi Luis,

Comments received with appreciation.

Exactly. There are multi-domain use cases within an operator and between operators. Good to hear interest from the group even at this early stage. I'd be delighted to see and to contribute how it may be addressed along with other chaptered perspectives.

Cheers,
Xiaohong

School of Electric Engineering and Telecommunications,
University of New South Wales, Australia

________________________________
From: LUIS MIGUEL CONTRERAS MURILLO [[email-masked]]
Sent: 11 August 2015 22:09
To: Xiaohong Deng; Benoit Claise; [email-masked]
Cc: Eggert, Lars
Subject: RE: [Supa] SUPA charter proposal

Hi Xiaohong

Dear Benoit and all,

Cheers,
Xiaohong

Regards, Benoit (OPS AD)

List of work items:

Milestones:

TBD

---

From: Benoit Claise <[email-masked]>
Date: Wed, 12 Aug 2015 17:05:00 +0200

+1 to what Adrian wrote.

Regards, B.
> .

---

From: Benoit Claise <[email-masked]>
Date: Wed, 12 Aug 2015 17:05:07 +0200

Bert, all,

In-line.
> OK, that was certainly not so clear to me. 
See in the charter " Out of scope of this working group is: The 
specification of a new policy language"
> Thanks for clarifying this. I am still abit worried about
> the text:
>
"will investigate" and "may create a model accordingly" are carefully 
written to stress the experimental aspect of the intent-based. See my 
previous email "SUPA: Situation Summary and Next Steps"
> work on, actually pretty soon.  AS we discussued in our barbof in Prague.
I shared my views on IB-NEMO during the barbof...

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Wed, 12 Aug 2015 17:35:05 +0200

Thanks Andy for the suggestions.

Regards, Benoit
> I have included a few comments or recommended changes in the text 
> below, mostly, I hope, to have made it be clearer. But none change the 
> substance.  Very nice job.
>
> Thanks and best regards,
>
> Andy
>
> <http://www.NetCracker.com>.com <http://www.NetCracker.com> >>>>  
> * Proven Partner to Communications Service Providers*
>
> 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 
> 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.
> Old:
>
> [SUPA (Simplified Use of Policy Abstractions) defines a model to 
> network configuration changes]
>
> [SUPA (Simplified Use of Policy Abstractions) defines a data model, to 
> be used to represent high-level, possibly network-wide, policies, 
> which can be input to a network management function (within a 
> controller, an orchestrator, a network element). SUPA will not define 
> ultimately result in network configuration changes]
>
>
> Note: I changed “can” to “will” here.  I do not see how a policy can 
> exist without reference to the context(s) or domain(s) for which it is 
> applicable.  Others may disagree.
>
> Practically, SUPA will define base YANG data models to encode 
> policies, which will point to device-, technology-, and 
> service-specific YANG models developed in other working groups.
>
> Note: Got rid of “fragment”, made bulleted list look like list.  Also 
> removed “form”, as it is not necessary and confusing a bit.  SUPA 
> is defining the form, I think.
>
> different levels of abstraction.  Specifically, three models are 
> envisioned:
>
> (i) a base model that defines concepts and vocabulary needed by policy 
> management independent of the content of the policy,
> (ii) a more specific model that refines the base model to specify how 
> to build policy rules of the event-condition-action paradigm, and
> 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.
> -The specification of a new policy language. The YANG data models are 
> according to the event-condition-action paradigm. Another extension 
> for defining policy rules according to a declarative, or intent-based, 
> how the Yang policy data 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.
>
> Note: Item 4  says a document will provide examples on how data models 
> can be used to express policies relevant to operators.  I changed text 
> to specifically mention the Yang policy data models, as that is what 
> is being defined by the group, so I wanted to be clear that the value 
> will be to show how those will work.  However, I also want to be clear 
> i am not envisioning the group defining or “standardizing” specific 
> policies using the Yang models.  Other working groups would own that 
> work as described in the penultimate paragraph.
> Note: I would consider moving this next paragraph to earlier, perhaps 
> after the line "SUPA will be designed to work with device, protocol, 
> network, and service data models.”  I think it might benefit by being 
> clear up front that the purpose os the define constructs to benefit 
> the creation of policy definition across all working groups and 
> perhaps beyond.  This is important context to be aware of when reading 
> the rest of the document.  I am interested in what others think.
>
> 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.
> that are working on related issues.
> Milestones:
> TBD
>
>
>
>
>
>
> ------------------------------------------------------------------------
> entity to which it is addressed and may contain confidential, 
> proprietary and/or privileged material. Any review, retransmission, 
> dissemination or other use of, or taking of any action in reliance 
> upon, this information by persons or entities other than the intended 
> recipient is prohibited. If you received this in error, please contact 
> the sender and delete the material from any computer.

---

From: Benoit Claise <[email-masked]>
Date: Wed, 12 Aug 2015 18:06:26 +0200

Hi Qiong,
> Hi Benoit,
>
> I like this version of charter. I think it is an important work to 
> define a generic data model to encode policy. I will be interested to 
> join this work in the future.
>
> One question: 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.
> Do we have recommended use case for these examples ? Or we do not 
> restrict the scenario for which the policy models can be used ?
I don't believe we should go as far as specifying the use case(s) in the 
charter, since SUPA is about generic models. So the
However, I wrote "a few examples". Indeed, during the first BoF (if I 
recall correctly), we had between 7 to 10 use cases.
Sure, generic policy models could be used for all sort of policies. This 
is a non-goal to document ALL the use cases.

Regards, Benoit
>
> Thanks!
>
> Best wishes
> Qiong
>
> China Telecom
>
> On Sat, Aug 8, 2015 at 12:03 AM, Benoit Claise <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Dear all,
>
>     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.
>
>     Practically, SUPA will define generic YANG data models to encode
>     policy, which can point to device-, technology-, and
>     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.
>
>     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.
>
>     -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.
>
>     according to the event-condition-action paradigm. Another
>     intent-based, paradigm, may be produced. These models will be
>     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.
>
>     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.
>
>     ETSI) that are working on related issues.
>
>     Milestones:
>
>     TBD
>
>
>
> lightweight 4over6: /http://sourceforge.net/projects/laft6//
> PCP-natcoord:/http://sourceforge.net/projects/pcpportsetdemo/ /

---

From: "Natale, Bob" <[email-masked]>
Date: Wed, 12 Aug 2015 20:38:06 +0000

+1 from me on this point from Adrian's message below* in particular: "SUPA should bundle all of the thought around policy models in one place as a starting point".

Fragmentation of PBNM solutions has resulted from the lack of standardization in the face of significant need ... the need is only growing as the requirements intended to be satisfied by the emerging technologies supporting network services virtualization (among many other drivers) raise the urgency of governed automation ... this is an opportunity for the IETF to restart in this challenging area (PBNM) and SUPA is a promising locus for the starting point (IMHO).

[* - Taken a little out of context, it's true ... but only a little. :)]

Avanti,
BobN

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Wednesday, August 12, 2015 11:05 AM
To: [email-masked]; 'Bert Wijnen (IETF)' <[email-masked]>; [email-masked]
Cc: 'Eggert, Lars' <[email-masked]>; [email-masked]
Subject: Re: [Supa] SUPA charter proposal

+1 to what Adrian wrote.

Regards, B.
> Hi Bert,
>
> I don't think you are reading the proposed charter for SUPA right if 
> you think it precludes the formation of a working group for IBNEMO. 
> Rather, the text that Benoit has published says that SUPA is not the 
> working group that works on IBNEMO.
>
> But maybe you are saying that the intent-based part of the SUAP 
> charter could be lifted out and placed in an IBNEMO work effort. That might be reasonable.
>
> However, there is a separation between the use of existing data 
> modeling and protocols (such as YANG with NETCONF) and the development 
> of a new and specialised modeling language and communication protocol. 
> I believe that this charter text opens up the investigation of the 
> practicalities of intent-based policy modeling in order to determine 
> whether such things could be modeled in existing languages or whether new work is needed a priori.
>
> If, for example, it was possible to encode intent-based policy in 
> YANG, that would not preclude IBNEMO inventing something different/better/worse.
>
> Now there it seems sensible that SUPA should bundle all of the thought 
> around policy models in one place as a starting point. If it is later 
> desirable to split off the intent-based part (say after the initial 
> investigation and information models) that doesn't seem like a bad thing.
>
> Alternatively, if there is a strong pull to move all of the 
> intent-based work out from day one, I will not be complaining.
>
> Cheers,
> Adrian
>
>> (Intent Based NEtwork MOdeling) work? I certainly hope not. In the 
>> charter you have:
>>
>> expression language.
>>> systems,
>>> policy,
>>> model
>>> are to be
>>> embedded
>>> demonstrate how
>>> tie into
>>> are re-
>>> development time
>>> not

---

From: Andy Bierman <[email-masked]>
Date: Wed, 12 Aug 2015 14:02:30 -0700

On Wed, Aug 12, 2015 at 1:38 PM, Natale, Bob <[email-masked]> wrote:

> +1 from me on this point from Adrian's message below* in particular: "SUPA
> should bundle all of the thought around policy models in one place as a
> starting point".
>
> Fragmentation of PBNM solutions has resulted from the lack of
> standardization in the face of significant need ... the need is only
> growing as the requirements intended to be satisfied by the emerging
> technologies supporting network services virtualization (among many other
> drivers) raise the urgency of governed automation ... this is an
> opportunity for the IETF to restart in this challenging area (PBNM) and
> SUPA is a promising locus for the starting point (IMHO).
>
IMO, the significant component here is network-level NM.
This is new territory for the IETF.  As we dig into "framework issues"
there are some common components that keep coming up:

   - topology database (query by attribute)
   - AAA (identity and authorization, logging)
   - inventory/capabilities

The need for cross-WG and cross-area coordination has never been greater.

Whether it's I2RS or PBNM or anything at the network level,
there are common problems dealing with NEs that must
be solved.  Let's make sure the foundation gets built before
the roof.

Avanti,

Andy

---

From: John Strassner <[email-masked]>
Date: Wed, 12 Aug 2015 21:35:40 +0000

Let's agree to disagree. REST defines FOUR commands and a particular architectural approach; I see NEMO redefining both aspects of this.

From: Supa [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, August 10, 2015 3:17 PM
To: 'John Strassner'; 'Bert Wijnen (IETF)'
Cc: 'Adrian Farrel'; 'Eggert, Lars'; [email-masked]; [email-masked]
Subject: Re: [Supa] [Ibnemo] SUPA charter proposal

John:

<jcs>

Bert,

please see inline.

<jcs>

<jcs>

On Sun, Aug 9, 2015 at 2:23 PM, Bert Wijnen (IETF) <[email-masked]<mailto:[email-masked]>> wrote:
John, Inline,

Bert

regards,
John

On Sun, Aug 9, 2015 at 8:23 AM, Adrian Farrel <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:

    Hi Bert,

    Cheers,
    Adrian

    > From: Supa [mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>] On Behalf Of Bert Wijnen (IETF)
    > To: Benoit Claise; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
    > Cc: Eggert, Lars; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
    policy rules
    here
    acceptable to
    and
    and
    device
    will
    with a
    in
    which
    data
    different
    investigate
    "intent-based"
    before
    policies in
    provide
    composed
    representing
    according to
    intent-based,
    > > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
    > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

    _______________________________________________
    Supa mailing list
    [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
    https://www.ietf.org/mailman/listinfo/supa

--
regards,
John

--
regards,
John

---

From: John Strassner <[email-masked]>
Date: Wed, 12 Aug 2015 21:50:49 +0000

Hi Sam,

in general, I like your suggestions [S] and recommendations [R]. Following are my comments to your questions [Q]:

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.
[Q] Is SUPA going to create/generate models, for ex: Service models, which are not defined anywhere? Also, I am presuming here that it is SUPA WG here and NOT SUPA function. Clarification to remove the ambiguity could help.
<jcs> SUPA will not create service models. The models that SUPA will create are limited to policy. SUPA could use other models (e.g., a VPN model or an ACL) model as part of its policy. </jcs>

Suggested Text> Models, which are not defined in any WG, will be identified but definition of those models is not within the scope. (something along those line could help)
<jcs> I would not add this, because this implies any model. SUPA should be focused on modeling policy. </jcs>

[Q] For (i) - the deliverable is Informational model as identified below as #2, correct?
<jcs>
My read is that the information model is now OPTIONAL. I'm a bit uncomfortable with that.
My read is that the objective of this paragraph was to remove the dependency on the information model, and instead define the three generic data models that were derived from the information model. Hence, (i) is the data model representation of the GPIM, (ii) is the data model representation of the EPRIM, and (iii) is the data model representation of the LSIM. </jcs>

[Q] For (ii) and (iii) - The deliverable is YANG, correct?
<jcs> Actually, YANG is the deliverable for (i), (ii), and (iii), though (i) is arguably too abstract to be used by itself. </jcs>

[Q] I see that problem statement and usecase documents are not mentioned as deliverables, explicitly. What exactly will be #1 deliverable?
<jcs> I would think that the problem statement is part of deliverable #1. I think that draft-klyus-supa-proposition is a good start to this deliverable.
SUPA had a number of use cases defined. I believe that the goal of the charter is to emphasize solution examples. Hence, those use cases could be used as input to solution examples, but the use case documents themselves are not goals.

regards,
John

From: Supa [mailto:[email-masked]] On Behalf Of aldrin ietf
Sent: Monday, August 10, 2015 4:07 PM
To: Benoit Claise; [email-masked]
Cc: [email-masked]
Subject: Re: [Supa] SUPA charter proposal

Hi Benoit and others,

Cheers
-sam

Subject:

SUPA charter proposal

Date:

Fri, 7 Aug 2015 18:03:13 +0200

From:

Benoit Claise <[email-masked]><mailto:[email-masked]>

To:

[email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>

CC:

Eggert, Lars <[email-masked]><mailto:[email-masked]>

Dear all,

Regards, Benoit (OPS AD)

[O]

[O]

List of work items:

thanks
-sam

Milestones:

TBD

---

From: aldrin ietf <[email-masked]>
Date: Wed, 12 Aug 2015 18:07:26 -0700

Hi John,

Comments inline.
> On Aug 12, 2015, at 2:50 PM, John Strassner <[email-masked]> wrote:
> 
> Hi Sam,
>  
%sam - I was meaning to say, policy models. for ex: policy models for different services. In other words, original question was, Is it the goal of SUPA WG to identify various policy models for different services or create them, if not present already?
> <jcs> I would not add this, because this implies any model. SUPA should be focused on modeling policy. </jcs>
%sam - Question was related to service policy itself? Either way, it needs to be clarified with appropriate text.
> <jcs> Actually, YANG is the deliverable for (i), (ii), and (iii), though (i) is arguably too abstract to be used by itself. </jcs>
%sam - Making that explicit in the deliverables will help the reader.
> SUPA had a number of use cases defined. I believe that the goal of the charter is to emphasize solution examples. Hence, those use cases could be used as input to solution examples, but the use cas…
%sam - From #1 text, I understood that the deliverable will be post problem definition and/or use cases. Hence the question.

-sam
> Benoit Claise <[email-masked]> <mailto:[email-masked]>
> To:
> [email-masked] <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>
> CC:
> Eggert, Lars <[email-masked]> <mailto:[email-masked]>
> 
> 
> Dear all,
>

---

From: John Strassner <[email-masked]>
Date: Wed, 12 Aug 2015 19:00:58 -0700

Hi Christian,

thanks for your reply. I agree with your comment about "fragment" - guess I
was too close to the problem. :-)

best regards,
John

On Tue, Aug 11, 2015 at 9:58 AM, <[email-masked]> wrote:

> [CJ] Agreed, but I would then suggest that the charter includes your “this
> model is not designed as an all-encompassing model” sentence above, which
> gracefully avoids the confusion introduced by the “fragment” wording imho.
>
>
>
> [CJ] I fully agree with you: as a matter of fact, I believe this
> computation logic will naturally “feed” the YANG model from which policy
> provisioning information will be derived accordingly. I think this is an
> essential part of the overall service delivery procedure as we see it. I
> hope a possibly updated version of the charter will reflect this approach.
>
>
>
> *[CJ] *Cheers,

-- 
regards,
John

---

From: Zhoutianran <[email-masked]>
Date: Thu, 13 Aug 2015 05:11:17 +0000

Hi John,

You have these words:
“Intent was defined in SUPA to be declarative, and was made up of either propositional logic or first order logic statements.
In the ONF, we took this definition and added the ability to negotiate, much like what you described.”
I followed ONF NBI work for a long time. However, I didn’t see any intent related document in ONF say “intent is made up of either propositional logic or first order logic statements”.
Tianran

From: Supa [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Thursday, August 13, 2015 10:01 AM
To: christian. jacquenet
Cc: Benoit Claise; Eggert, Lars; [email-masked]
Subject: Re: [Supa] SUPA charter proposal

Hi Christian,

thanks for your reply. I agree with your comment about "fragment" - guess I was too close to the problem. :-)

best regards,
John

On Tue, Aug 11, 2015 at 9:58 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hello John,

[snip]

<jcs>

[CJ] Exactly.

[CJ] Neither can I.

</jcs>

[CJ] Cheers,

[CJ] Christian.

Thank you.

--
regards,
John

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Thu, 13 Aug 2015 17:29:08 +0000

Is there an example how e.g. P1, P2, P3 could be done in a YANG data model? Some real YANG example could really help with better understanding what a WG outcome would actually be, and whether it would be useful. 

In general, I think SUPA should not define what a function does with the input and how policies are enforced, no matter whether the policies actually require network configuration changes or not. Unless I miss something, the actual policy enforcement may be far from being obvious, depending on the policy.

Also, I still don't understand why SUPA actually needs an applicability document. Wouldn't the YANG data model description come along some syntax examples for policies like P1, P2, and P3? If so, what is the added value of a separate applicability document?

Michael

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Sonntag, 9. August 2015 22:55
To: Romascanu, Dan (Dan)
Cc: 'Benoit Claise'; Adrian Farrel; 'Eggert, Lars'; [email-masked]
Subject: Re: [Supa] SUPA charter proposal

Example for (a):

Example for (b)

P1 requires access to topology information and a way to modify the configuration disabling SSH. P2 is a policy rule constraining who is allowed to insert certain policy rules. P3 is a policy rule controlling the activation (and implicitely the deactivation) of a policy rule. P1 will affect device configurations, P2 and P3 might only be visible to the policy function.

All I want is that policies of both types are clearly defined such that the policy function can be implemented in an interoperable way and I do not see why the charter should include phrases that weaken this requirement.

/js

On Sun, Aug 09, 2015 at 05:39:36PM +0000, Romascanu, Dan (Dan) wrote:
> > I think we are messing up two different things, namely (a) what does 
> > a policy mean and how is it leading to configuration changes and (b) 
> > who is allowed to define policies, how are policies activated, when are policies evaluated, etc.
> > 
> > does not have to be precisely defined but (b) better is. I think 
> > both need to be defined precisely enough to allow interoperable running code.
> > 
> > /js
> > 
> > > configuration changes. SUPA however will not deal with the 
> > > definition of the specific network configuration changes but with 
> > > how the configuration changes are applied (e.g. who is allowed to 
> > > set policies, when and how the policies are activated, changed or
> > > de-activated)
> > >
> > > Regards,
> > >
> > > Dan
> > >
> > > > > I don't think I sourced the line of text you are asking about, 
> > > > > but I certainly reviewed it several times.
> > > > >
> > > > > > > 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
> > > > > >
> > > > > > I am not sure what the intend of the last sentence is. I 
> > > > > > hope that the semantics of the interface to the policy 
> > > > > > network management function are defined clearly enough that 
> > > > > > the translation of policy into network configuration changes 
> > > > > > is not a
> > mystery.
> > > > >
> > > > > management function resulting from policy input will be 
> > > > > clearly defined configuration changes. It seems to me that 
> > > > > this is often likely, but not always the case. For example, if 
> > > > > I was building such a function I would make it stateful and I 
> > > > > would expect it to retain some policy state itself that it 
> > > > > would then use to determine how to process future
> > > > policy instructions.
> > > > >
> > > > > configuration, but I would tend to implement that piece of 
> > > > > policy within the network
> > > > > probably right on this, but it is not actually the aim of the 
> > > > > WG to define how the policy network management function works 
> > > > > or how it responds to each
> > > > Even with this explanation, I find the phrase "SUPA will not 
> > > > define what the function does with that input but anticipates 
> > > > that it will ultimately result in network configuration changes" 
> > > > too vague for charter text. The IETF's mantra is rough consensus 
> > > > and running code and for creating (interoperable) running code 
> > > > the semantics of the
> > > > proposals during the SUPA process so far where I would have 
> > > > little clue how to really implement things (and I doubt two 
> > > > coders would have filled the void with the same interpretation). 
> > > > Perhaps this is just because we are in early stages but I 
> > > > personally would feel better if the charter would make it clear 
> > > > that we are not looking for high-level abstract blueprint 
> > > > descriptions of a policy function but rather something concrete 
> > > > and well defined that can lead to interoperate running code. To 
> > > > me, the sentence kind of legitimates high-
> > level abstract blueprint models - even if this might not have been 
> > the intention.
> > > >
> > > > Anyway, if it is just me how is concerned about this sentence 
> > > > and everybody else is happy with the sentence, simply ignore my email.
> > > >
> > > > /js
> > > >
> > > > --

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Aug 2015 22:03:04 +0200

> In general, I think SUPA should not define what a function does with the input and how policies are enforced, no matter whether the policies actually require network configuration changes or not. U…

If "the actual policy enforcement may be far from being obvious", I
believe we leave the "rough consensus and running code" principle of
the IETF. IETF standards work best if they allow people to write
interoperable implementations and the availability of interoperable
implementations ideally opens a market. In fact, in many cases it is
implementation work and running code that helps to understand the
problem.

If we write specifications for policies where "the actual policy
enforcement may be far from being obvious" then it does not really
matter in my view whether we use an information model, a data model or
simply plain English language.

Anyway, I think I have stated my opinion and there is surely room for
other opinions. I guess Benoit and the IESG will have to sort this out
at the end.

/js

---

From: John Strassner <[email-masked]>
Date: Thu, 13 Aug 2015 19:21:39 -0700

Hi Sam,

comments inline as well:

%sam - I was meaning to say, policy models. for ex: policy models for
different services. In other words, original question was, Is it the goal
of SUPA WG to identify various policy models for different services or
create them, if not present already?

<jcs2>
IMHO, the goal of SUPA is to define a generic policy framework that enables
ECA and declarative policies to be used to manage network resources and
services. SUPA SHOULD be able to use policy models of other WGs; the value
of SUPA is a common framework that enables these (and new) models to be
used together.
</jcs2>

Suggested Text> Models, which are not defined in any WG, will be identified
but definition of those models is not within the scope. (something along
those line could help)
<jcs> I would not add this, because this implies any model. SUPA should be
focused on modeling policy. </jcs>

%sam - Question was related to service policy itself? Either way, it needs
to be clarified with appropriate text.
<jcs2> Does my clarification above help here, or do you think that we need
additional clarification? </jcs2>

...

[Q] For (ii) and (iii) - The deliverable is YANG, correct?
<jcs> Actually, YANG is the deliverable for (i), (ii), and (iii), though
(i) is arguably too abstract to be used by itself. </jcs>

<jcs2> Agreed </jcs2>

regards,
John

On Wed, Aug 12, 2015 at 6:07 PM, aldrin ietf <[email-masked]> wrote:

> [Q] Is SUPA going to create/generate models, for ex: Service models, which
> are not defined anywhere? Also, I am presuming here that it is SUPA WG here
> and NOT SUPA function. Clarification to remove the ambiguity could help.
> <jcs> SUPA will not create service models. The models that SUPA will
> create are limited to policy. SUPA could use other models (e.g., a VPN
> model or an ACL) model as part of its policy. </jcs>
>
> %sam - I was meaning to say, policy models. for ex: policy models for
> different services. In other words, original question was, Is it the goal
> of SUPA WG to identify various policy models for different services or
> create them, if not present already?
>
>
> Suggested Text> Models, which are not defined in any WG, will be
> identified but definition of those models is not within the scope.
> (something along those line could help)
> My read is that the objective of this paragraph was to remove the
> dependency on the information model, and instead define the three generic
> data models that were derived from the information model. Hence, (i) is the
> data model representation of the GPIM, (ii) is the data model
> representation of the EPRIM, and (iii) is the data model representation of
> the LSIM. </jcs>
>
> <jcs> Actually, YANG is the deliverable for (i), (ii), and (iii), though
> (i) is arguably too abstract to be used by itself. </jcs>
>
> [Q] I see that problem statement and usecase documents are not mentioned
> as deliverables, explicitly. What exactly will be #1 deliverable?
> <jcs> I would think that the problem statement is part of deliverable #1.
> I think that draft-klyus-supa-proposition is a good start to this
> deliverable.
> SUPA had a number of use cases defined. I believe that the goal of the
> charter is to emphasize solution examples. Hence, those use cases could be
> used as input to solution examples, but the use case documents themselves
> are not goals.
>
> %sam - From #1 text, I understood that the deliverable will be post
> problem definition and/or use cases. Hence the question.
>
> -sam
>
>
> regards,
> John
>
> *From:* Supa [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *aldrin ietf
> *Sent:* Monday, August 10, 2015 4:07 PM
> *To:* Benoit Claise; [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [Supa] SUPA charter proposal
>
> Hi Benoit and others,
>
> *Subject:*
> *Date:*
> *From:*
> Benoit Claise <[email-masked]> <[email-masked]>
> *To:*
> [email-masked] <[email-masked]> <[email-masked]>
> *CC:*
> Eggert, Lars <[email-masked]> <[email-masked]>
>
>
>
> Dear all,
>
> 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.
> <S> Operators want and need to be able to determine, configure and manage
> various policies, applicable to both physical and virtual networks, in
> order to meet various customer and network requirements.
>
> [O]
>
> 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.
> [R] As policy spans 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 various environments.
>
> [O]
>
> Such an approach will help to avoid configuration errors that arise from
> policies that apply in different environments, will make the implementation
> of policy-based systems quicker and cheaper, and will facilitate the rapid
> [R] Such an approach will enable uniformity and easy understanding of
> policies that apply in different environments, thereby
> minimizing configuration errors that arise from confusion between different
> systems. This will quicken  the implementation of policy-based systems, and
> facilitates the rapid development of standards-based data models that
> include policy elements.
>
>
>
>
> [Q] Is SUPA going to create/generate models, for ex: Service models, which
> are not defined anywhere? Also, I am presuming here that it is SUPA WG here
> and NOT SUPA function. Clarification to remove the ambiguity could help.
>
> Suggested Text> Models, which are not defined in any WG, will be
> identified but definition of those models is not within the scope.
> (something along those line could help)
>
>
>
> [Q] I see that problem statement and usecase documents are not mentioned
> as deliverables, explicitly. What exactly will be #1 deliverable?
>
> thanks
> -sam
>
>

-- 
regards,
John

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 14 Aug 2015 08:42:30 +0000

I actually strongly believe in "running code". And it is possible that I really miss something here. 

To me "running code" for a WG that shall deliver "a set of YANG data models consisting of a base policy model for representing policy management concepts" first of all means that the "running code" is YANG, right? Is there an initial YANG data model that would help me with better understanding how a potential outcome of a WG could look like? I'd really be interested in understanding how a YANG data model would deal with specific policy examples, e.g. P1, P2, and P3 as earlier mentioned. Being an engineer, I look for something specific instead of speculating about the future. Of course, I fully understand that any YANG data models could (and probably would) change during the WG work - as usual in the IETF. But I really struggle with understanding the intended work right now. I guess I'd need to see YANG examples to understand whether the planned work could help or not.

Regarding the enforcement: Would the actual enforcement of policies defined in SUPA YANG models not be realized internally in some software component? If so, what would the IETF actually standardize in the context of policy enforcement? Possibly some examples could help again to understand what an IETF standard would be about.

Thanks

Michael

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Donnerstag, 13. August 2015 22:03
To: Scharf, Michael (Michael)
Cc: Romascanu, Dan (Dan); 'Benoit Claise'; Adrian Farrel; 'Eggert, Lars'; [email-masked]
Subject: Re: [Supa] SUPA charter proposal

> In general, I think SUPA should not define what a function does with the input and how policies are enforced, no matter whether the policies actually require network configuration changes or not. U…

If "the actual policy enforcement may be far from being obvious", I believe we leave the "rough consensus and running code" principle of the IETF. IETF standards work best if they allow people to write interoperable implementations and the availability of interoperable implementations ideally opens a market. In fact, in many cases it is implementation work and running code that helps to understand the problem.

If we write specifications for policies where "the actual policy enforcement may be far from being obvious" then it does not really matter in my view whether we use an information model, a data model or simply plain English language.

Anyway, I think I have stated my opinion and there is surely room for other opinions. I guess Benoit and the IESG will have to sort this out at the end.

/js

---

From: Tina TSOU <[email-masked]>
Date: Fri, 14 Aug 2015 09:06:57 +0000

Dear Michael,

Laurent is the co-editor of data model design team. But he is in vacation now.

Here is Generic Policy Data Model + ECA Policy Data Model.
https://datatracker.ietf.org/doc/draft-chen-supa-eca-data-model/

Thank you,
Tina

On Aug 14, 2015, at 4:42 PM, Scharf, Michael (Michael) <[email-masked]<mailto:[email-masked]>> wrote:

Thanks

Michael

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Donnerstag, 13. August 2015 22:03
To: Scharf, Michael (Michael)
Cc: Romascanu, Dan (Dan); 'Benoit Claise'; Adrian Farrel; 'Eggert, Lars'; [email-masked]<mailto:[email-masked]>
Subject: Re: [Supa] SUPA charter proposal

/js

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 14 Aug 2015 09:51:31 +0000

Thanks a lot for the pointer! But is still hard do see how the "generic" model would indeed solve examples such as P1, P2, and P3 mentioned in this discussion, without requiring a tailored YANG model for each potential policy. At least the examples in section 5 and 6 seem to require that. My original question was how to solve more complex policies such as examples P1, P2, and P3 mentioned in this thread.
Also, I still wonder what added value an applicability document would have, if an actual YANG data model spec already contains some informal examples, which are probably required for illustration purposes.

Michael

From: Tina TSOU [mailto:[email-masked]]
Sent: Freitag, 14. August 2015 11:07
To: Scharf, Michael (Michael)
Cc: Juergen Schoenwaelder; Benoit Claise; Romascanu, Dan (Dan); Eggert, Lars; [email-masked]; Adrian Farrel
Subject: Re: [Supa] SUPA charter proposal

Dear Michael,

Thank you,
Tina

Thanks

Michael

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Donnerstag, 13. August 2015 22:03
To: Scharf, Michael (Michael)
Cc: Romascanu, Dan (Dan); 'Benoit Claise'; Adrian Farrel; 'Eggert, Lars'; [email-masked]<mailto:[email-masked]>
Subject: Re: [Supa] SUPA charter proposal

/js

---

From: Tina TSOU <[email-masked]>
Date: Fri, 14 Aug 2015 10:55:36 +0000

Dear Michael,

>From what I read from the list discussion, the generic policy model is a logic model, it is only practical in the way plus ECA data model, or plus logic statement data model.

In my understanding, P1 is content of policy, P2 and P3 are attributes of policy. At least draft-chen solves P1.

Let the others comment at your original questions about P1, P2, and P3.

Happy Friday.

Thank you,
Tina

On Aug 14, 2015, at 5:51 PM, Scharf, Michael (Michael) <[email-masked]<mailto:[email-masked]>> wrote:

Thanks a lot for the pointer! But is still hard do see how the “generic” model would indeed solve examples such as P1, P2, and P3 mentioned in this discussion, without requiring a tailored YANG model for each potential policy. At least the examples in section 5 and 6 seem to require that. My original question was how to solve more complex policies such as examples P1, P2, and P3 mentioned in this thread.
Also, I still wonder what added value an applicability document would have, if an actual YANG data model spec already contains some informal examples, which are probably required for illustration purposes.

Michael

Cc: Juergen Schoenwaelder; Benoit Claise; Romascanu, Dan (Dan); Eggert, Lars; [email-masked]<mailto:[email-masked]>; Adrian Farrel

Dear Michael,

Thank you,
Tina

Thanks

Michael

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Donnerstag, 13. August 2015 22:03
To: Scharf, Michael (Michael)
Cc: Romascanu, Dan (Dan); 'Benoit Claise'; Adrian Farrel; 'Eggert, Lars'; [email-masked]<mailto:[email-masked]>
Subject: Re: [Supa] SUPA charter proposal

/js

---

From: John Strassner <[email-masked]>
Date: Fri, 14 Aug 2015 14:59:33 -0700

Hi Michael,

comments inline:

> To me "running code" for a WG that shall deliver "a set of YANG
> data models consisting of a base policy model for representing
> policy management concepts" first of all means that the
> "running code" is YANG, right?

<jcs>
Not to me (but perhaps to others).
The focus of the WG is to produce YANG models. However, I
don't see how a policy management system can be implemented
solely in YANG.
</jcs>

> Is there an initial YANG data model that would help me with
> better understanding how a potential outcome of a WG could
> look like?

<jcs>
Please look at draft-chen-supa-eca-data-model-02.
</jcs>

> I'd really be interested in understanding how a YANG
> data model would deal with specific policy examples, e.g.
> P1, P2, and P3 as earlier mentioned.

<jcs>
I do not believe those specific examples have been defined in
YANG. I do believe that draft-klyus-supa-proposition-02
provides a useful description of how this is supposed to work.
It would be good to get feedback as to why this is not the case.
</jcs>

> Regarding the enforcement: Would the actual enforcement
> of policies defined in SUPA YANG models not be realized
> internally in some software component?

<jcs>
Not necessarily. It depends where the enforcement is taking
place, and more specifically, what you mean by enforcement.
</jcs>

> If so, what would the IETF actually standardize in the
> context of policy enforcement?

<jcs>
Policy enforcement is not part of the charter.
</jcs>

regards,
John

On Fri, Aug 14, 2015 at 1:42 AM, Scharf, Michael (Michael) <
[email-masked]> wrote:

> To me "running code" for a WG that shall deliver "a set of YANG data
> models consisting of a base policy model for representing policy management
> concepts" first of all means that the "running code" is YANG, right? Is
> there an initial YANG data model that would help me with better
> understanding how a potential outcome of a WG could look like? I'd really
> be interested in understanding how a YANG data model would deal with
> specific policy examples, e.g. P1, P2, and P3 as earlier mentioned. Being
> an engineer, I look for something specific instead of speculating about the
> future. Of course, I fully understand that any YANG data models could (and
> probably would) change during the WG work - as usual in the IETF. But I
> really struggle with understanding the intended work right now. I guess I'd
> need to see YANG examples to understand whether the planned work could help
> or not.
>
> Regarding the enforcement: Would the actual enforcement of policies
> defined in SUPA YANG models not be realized internally in some software
> component? If so, what would the IETF actually standardize in the context
> of policy enforcement? Possibly some examples could help again to
> understand what an IETF standard would be about.
>
> Thanks
>
> Michael
>
>
> > In general, I think SUPA should not define what a function does with the
> input and how policies are enforced, no matter whether the policies
> actually require network configuration changes or not. Unless I miss
> something, the actual policy enforcement may be far from being obvious,
> depending on the policy.
> >
>
> believe we leave the "rough consensus and running code" principle of the
> IETF. IETF standards work best if they allow people to write interoperable
> implementations and the availability of interoperable implementations
> ideally opens a market. In fact, in many cases it is implementation work
> and running code that helps to understand the problem.
>
> enforcement may be far from being obvious" then it does not really matter
> in my view whether we use an information model, a data model or simply
> plain English language.
>
> other opinions. I guess Benoit and the IESG will have to sort this out at
> the end.
>
> /js
>
> --

-- 
regards,
John

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Sat, 15 Aug 2015 14:56:24 +0000

> It would be good to get feedback as to why this is not the case.

... and the lack of backing by YANG is the reason for my original question. For what it is worth, draft-klyus-supa-proposition-02 would have been easier to parse if it would actually show with YANG (sniplets) how the examples therein could indeed be realized in reality. Looking at the examples mentioned now on the list and earlier makes me wonder how simple or complex the generic YANG policy data model would have to be. As far as I can see, draft-chen-supa-eca-data-model-02 only addresses a very narrow subset of use cases right now. While this is OK for an individual draft, the challenge is that it is hard to predict how much has to be added in future to bridge gaps to some of the examples mentioned elsewhere.

Regarding the charter wording, I wonder if the superset of potential SUPA use cases could require embedding of all the logic of a full programming or script language. Does "generic" mean that the policy logic should be able to support really *all* potential policies related to network configuration that an operator may want to express? If so, for instance, it is not clear to me if the generic YANG data models produced by the WG could finally be turing complete...

If this is not the intention, maybe one could explicit this in the charter? For instance:

OLD:

NEW:

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

But I am actually not sure whether all discussed use cases would then still be doable.

Michael

---

From: "Narasimha Rao Vadrevu" <[email-masked]>
Date: Sat, 15 Aug 2015 09:02:17 -0700

Mihael,

There is an 'Applicability document' which describes how this can evolve:  
The benefit of the SUPA is in creating many policies upfront. As the  operations grow in complexity SUPA can expand an existing policy by  adding more variables. This is how reusable policies can be    developed upfront and configuration and maintenance operations can  be dealt by modeling and programmatic approach.
https://datatracker.ietf.org/doc/draft-vadrevu-supa-applicability/?include_text=1

This document was a result of the BOF discussions pre IETF 93. There are 2 use cases.
Can you comment if this document elucidates a bit further or obfuscates more?

Thanks,
Narasimha

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Scharf, Michael (Michael)
Sent: Saturday, August 15, 2015 7:56 AM
To: John Strassner <[email-masked]>
Cc: Juergen Schoenwaelder <[email-masked]>; Romascanu, Dan (Dan) <[email-masked]>; Eggert, Lars <[email-masked]>; Benoit Claise <[email-masked]>; Adrian Farrel <[email-masked]>; [email-masked]
Subject: Re: [Supa] SUPA charter proposal

> I do not believe those specific examples have been defined in YANG. I 
> do believe that draft-klyus-supa-proposition-02 provides a useful 
> description of how this is supposed to work.

OLD:

NEW:

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

Michael

---

From: Andy Bierman <[email-masked]>
Date: Sat, 15 Aug 2015 10:09:32 -0700

Hi,

IMO the solution space looks very different to lots of people.
I have found it useful to think about how Juergen's SNMP policy
could be implemented. I would really like to see mock-up
solutions presented as early in the WG process as possible.

Essentially, the "smarts" to implement conditions and actions can either
be programmed in by the tool designers (more abstract info-model of
the managed pieces) or programmed in by the operator/client app
that is using SUPA.

The first interesting problem with "disable all incoming SNMP" is
knowing what SNMP is and what ports it uses in the network.
This can either be hard-wired or programmed.

The next problem is identifying the administrative domain boundaries,
which requires a topology database that is available to SUPA policies.

The YANG data needed to define a policy could be anything from
a complete decomposition of all logic into YANG data (which nobody
seems to think will work) to a leaf containing the name of the script
to invoke when a pre-configured event is received.

I prefer a solution where the smarts are provided by the client,
not built into the policy engine. Programming in YANG is a non-starter,
but programming in a scripting language that is very YANG-aware is quite
the opposite.

  event: leverage pub/sub work in NETCONF WG
  condition: scripts, using event data and framework to access topology and
NE data
  action: scripts, using some framework to access topology and NE data

It is hard to standardize a script language, so not sure how this will
happen.

Andy

On Sat, Aug 15, 2015 at 7:56 AM, Scharf, Michael (Michael) <
[email-masked]> wrote:

> ... and the lack of backing by YANG is the reason for my original
> question. For what it is worth, draft-klyus-supa-proposition-02 would have
> been easier to parse if it would actually show with YANG (sniplets) how the
> examples therein could indeed be realized in reality. Looking at the
> examples mentioned now on the list and earlier makes me wonder how simple
> or complex the generic YANG policy data model would have to be. As far as I
> can see, draft-chen-supa-eca-data-model-02 only addresses a very narrow
> subset of use cases right now. While this is OK for an individual draft,
> the challenge is that it is hard to predict how much has to be added in
> future to bridge gaps to some of the examples mentioned elsewhere.
>
> Regarding the charter wording, I wonder if the superset of potential SUPA
> use cases could require embedding of all the logic of a full programming or
> script language. Does "generic" mean that the policy logic should be able
> to support really *all* potential policies related to network configuration
> that an operator may want to express? If so, for instance, it is not clear
> to me if the generic YANG data models produced by the WG could finally be
> turing complete...
>

---

From: "Narasimha Rao Vadrevu" <[email-masked]>
Date: Sat, 15 Aug 2015 10:22:28 -0700

Great explanation Andy. 

From: Supa [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Saturday, August 15, 2015 10:10 AM
To: Scharf, Michael (Michael) <[email-masked]>
Cc: Juergen Schoenwaelder <[email-masked]>; John Strassner <[email-masked]>; Romascanu, Dan (Dan) <[email-masked]>; Eggert, Lars <[email-masked]>; Benoit Claise <[email-masked]>; Adrian Farrel <[email-masked]>; [email-masked]
Subject: Re: [Supa] SUPA charter proposal

Hi,

that is using SUPA.

the opposite.

  condition: scripts, using event data and framework to access topology and NE data

It is hard to standardize a script language, so not sure how this will happen.

Andy

OLD:

NEW:

Michael

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Sat, 15 Aug 2015 17:36:08 +0000

Indeed, having mock-up solutions early could be another alternative to better understand whether SUPA will finally standardize a script language, or not.

Michael

From: Supa [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Saturday, August 15, 2015 7:10 PM
To: Scharf, Michael (Michael)
Cc: Juergen Schoenwaelder; John Strassner; Romascanu, Dan (Dan); Eggert, Lars; Benoit Claise; Adrian Farrel; [email-masked]
Subject: Re: [Supa] SUPA charter proposal

Hi,

Andy

OLD:

NEW:

Michael

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Sat, 15 Aug 2015 18:22:29 +0000

Hi Narasimha,

Similar to other examples, it is not clear to me how the examples mentioned in this document tie into the YANG data model that SUPA shall provide for ECA.

Let's take example 2 in the draft-vadrevu-supa-applicability:

--snip---
ECA Policy:

   Event: a VPC user's location is changed (near to another DC)

   Condition:  network_load(DC_old, DC_new) < threshold

   Action:

     1. Migrate the VM to the new data center (DC_new)

     2. Update the VPNs connecting the user's services
--snip--

I really wonder how to map this to YANG. Some questions that immediately come into my mind would be:

1) How does the YANG data policy model refer to "user's location"? Probably, user location could be a leaf in some YANG model, right?

2) What logic operators are needed to detect whether "user's location" has changed? For instance, does this policy need an operator that can compare geo-coordinates? If so, would that operator be somehow be defined in the generic YANG data model? (Well, many other policy could also leverage comparison of geo-coordinates, so providing it for all a generic base model could be a reasonable solution, right? Or not?)

3) Where does the parameters "network_load", "DC_old", and "DC_new" come from? For instance, does this require a lookup in a traffic matrix if there are more than 2 data centers, with corresponding indexes etc.? 

4) How are the actions triggered? Note that DC management solutions may not necessarily have a NETCONF interface. So, does the action lists refer to external scripts? One script? Or several scripts?

5) What happens if the first action fails? Is there an exception handling inside the policy action list?

... (the list can be continued - the mapping to YANG data models is really not obvious to me)

To me, this type of use cases is clearly doable in whatever script or programming language. In YANG, it seems doable if Event, Condition, and Action all simply point to (highly domain-specific) scripts. But beyond that I am lost what the WG would actually standardize.

In other words, shall the SUPA WG simply standardize a format for pointers to non-YANG scripts? 

Thanks

Michael

> From: Narasimha Rao Vadrevu [mailto:[email-masked]]
> Sent: Saturday, August 15, 2015 6:02 PM
> To: Scharf, Michael (Michael); 'John Strassner'
> Cc: 'Juergen Schoenwaelder'; 'Romascanu, Dan (Dan)'; 'Eggert, Lars';
> 'Benoit Claise'; 'Adrian Farrel'; [email-masked]
> The benefit of the SUPA is in creating many policies upfront. As the
> operations grow in complexity SUPA can expand an existing policy by
> adding more variables. This is how reusable policies can be
> developed upfront and configuration and maintenance operations can  be
> dealt by modeling and programmatic approach.
> Cc: Juergen Schoenwaelder <[email-masked]>;
> Romascanu, Dan (Dan) <[email-masked]>; Eggert, Lars
> <[email-masked]>; Benoit Claise <[email-masked]>; Adrian Farrel
> <[email-masked]>; [email-masked]
> question. For what it is worth, draft-klyus-supa-proposition-02 would
> have been easier to parse if it would actually show with YANG
> (sniplets) how the examples therein could indeed be realized in
> reality. Looking at the examples mentioned now on the list and earlier
> makes me wonder how simple or complex the generic YANG policy data
> model would have to be. As far as I can see, draft-chen-supa-eca-data-
> model-02 only addresses a very narrow subset of use cases right now.
> While this is OK for an individual draft, the challenge is that it is
> hard to predict how much has to be added in future to bridge gaps to
> some of the examples mentioned elsewhere.
> 
> Regarding the charter wording, I wonder if the superset of potential
> SUPA use cases could require embedding of all the logic of a full
> programming or script language. Does "generic" mean that the policy
> logic should be able to support really *all* potential policies related
> to network configuration that an operator may want to express? If so,
> for instance, it is not clear to me if the generic YANG data models
> produced by the WG could finally be turing complete...
> 
> -The specification of a new policy language or programming language.
> The YANG data models are to be used with protocols such as
> NETCONF/RESTCONF.
> 
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 15 Aug 2015 22:22:31 +0200

On Sat, Aug 15, 2015 at 10:09:32AM -0700, Andy Bierman wrote:
> not built into the policy engine.

+1

> Programming in YANG is a non-starter,

There are examples in the IETF, like for instance the SIEVE mail
filtering language:

https://en.wikipedia.org/wiki/Sieve_%28mail_filtering_language%29

Unfortunately, Benoit's proposed charter seems to rule out solutions
where the power is in scriptable events / conditions / actions.  So,
the alternatives that are in Benoit's proposed charter are we either
do something that

(a) requires domain specific data models for every type of policy
    (unlikely to be implemented if you ask me) or something that

(b) exposes even simple boolean expressions as complex collections of
    YANG objects (leading to something way too complex to be used for
    anything more serious than hello world examples), or

(c) we will define a policy framework that essentially only works with
    strings that mean something to black boxes that interpret them in
    whatever way they like best (which is unlikely to be
    interoperable).

Going back to the 'disable SNMP on all edge routers' example, I would
assume that a solution has an action that essentially instantiates ACL
entries according to the YANG ACL configuration data model. The
knowledge of which ports need to be blocked is encoded in the config
snippet embodied in the action. The condition needs to hook into the
topology data model and extract all routers that are edge routers.
This ideally boils down to filtering on some tags in the topology
model. The events that trigger the rule would essentially be any
changes to the IP topology layer (e.g., when edge routers are added or
removed) and it might in addition be periodic. With scriptable
events/conditions/actions, I can see how I could do all this with
meaningful complexity. But as said above, unfortunately Benoit's
proposed charter rules this option out. So the proponents of the other
approaches need to explain how they are going to implement a simple
policy like 'disable SNMP on all edge routers'.

/js

---

From: Tina TSOU <[email-masked]>
Date: Sun, 16 Aug 2015 05:02:05 +0000

Dear Juergen,

What specific changes to you want to see in the charter, not ruling this option out?

Thank you,
Tina

> On Aug 16, 2015, at 4:22 AM, Juergen Schoenwaelder <[email-masked]> wrote:
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 16 Aug 2015 13:04:57 +0200

> What specific changes to you want to see in the charter, not ruling this option out?

Remove:

The first sentence is potentially disallowing useful work (depends on
the interpretation of 'policy language' I guess) and the second
sentence is stating the obvious or it is there to underpin something I
do not understand without heavy reading between the lines.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 16 Aug 2015 11:11:25 +0000

Hi Juergen,

I *think* that the intention of Benoit when proposing to exclude 'the specification of a new policy language' was that SUPA will not define something new (for example a COPSv2). Would 'policy protocol' be a better term?

I agree that the second sentence is unnecessary if we agree that YANG will be used to define data models. 

Regards,

Dan

> Sent: Sunday, August 16, 2015 2:05 PM
> To: Tina TSOU
> Cc: Andy Bierman; Scharf, Michael (Michael); John Strassner; Romascanu,
> Dan (Dan); Eggert, Lars; Benoit Claise; Adrian Farrel; [email-masked]
> The first sentence is potentially disallowing useful work (depends on the
> interpretation of 'policy language' I guess) and the second sentence is stating
> the obvious or it is there to underpin something I do not understand without
> heavy reading between the lines.
> 
> /js
> 
> --
> cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=1bF2bC7AMPQhPh1ka4YKnExrsW
> xOi4eO9h5suedkCyA&s=o0aftoqzssZv1_tILJJUrJ2xeWZkfIdvsp4weozRs-
> Y&e= >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 16 Aug 2015 13:43:26 +0200

Sure, I have no issue stating that SUPA is not doing traditional
protocol work. But that is not what the text says.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 16 Aug 2015 11:59:35 +0000

Would this change remove the concern: 

OLD: 

NEW: 

- The specification of a new policy protocol. 

Regards,

Dan

> Sent: Sunday, August 16, 2015 2:43 PM
> To: Romascanu, Dan (Dan)
> Cc: Tina TSOU; Andy Bierman; Scharf, Michael (Michael); John Strassner;
> Eggert, Lars; Benoit Claise; Adrian Farrel; [email-masked]
> Sure, I have no issue stating that SUPA is not doing traditional protocol work.
> But that is not what the text says.
> 
> /js
> 
> > I *think* that the intention of Benoit when proposing to exclude 'the
> specification of a new policy language' was that SUPA will not define
> something new (for example a COPSv2). Would 'policy protocol' be a better
> term?
> >
> > > Cc: Andy Bierman; Scharf, Michael (Michael); John Strassner;
> > > Romascanu, Dan (Dan); Eggert, Lars; Benoit Claise; Adrian Farrel;
> > > [email-masked]
> > > > What specific changes to you want to see in the charter, not
> > > > ruling this
> > > option out?
> > > >
> > >
> > > Remove:
> > >
> to
> > > The first sentence is potentially disallowing useful work (depends
> > > on the interpretation of 'policy language' I guess) and the second
> > > sentence is stating the obvious or it is there to underpin something
> > > I do not understand without heavy reading between the lines.
> > >
> > > /js
> > >
> > > --
> cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=ws2BDV46IhEsSRQqwFTWHH6Y_J
> MwJDB63iVRFJOEAi4&s=hPmYU51HZJmmrpakYm-dTt6VQvoHj-
> V2lTyHQDqLNXA&e= >

---

From: John Strassner <[email-masked]>
Date: Sun, 16 Aug 2015 20:43:49 -0700

Hi,

> solutions presented as early in the WG process as possible.

<jcs> Agree with both of these points </jcs>

> Essentially, the "smarts" to implement conditions and actions can
> either be programmed in by the tool designers (more abstract
> info-model of the managed pieces) or programmed in by the
> operator/client app that is using SUPA.

<jcs> Agree </jcs>

> The first interesting problem with "disable all incoming SNMP"
> is knowing what SNMP is and what ports it uses in the network.

<jcs> We need three pieces of information: 1) what disable
means (trivial for humans, but what if operators use synonyms?),
2) what SNMP is, and 3) what applying disable to SNMP means.
If we go to either Figure 1 in draft-klyus... or to slide 6 in the SUPA
Info Model presentation at IETF93, I submit that all three of these
things get handled in the Policy Engine. An information model can
NOT in general figure out that "disable" is the same thing as "deny"
or "block". The information model could certainly say that SNMP is
a protocol, and that ports 161 and 162 are reserved (by default)
for general messages and traps. This is just a statement of fact
(or a class attribute, if you want); something still has to make that
understandable by the device. Hence, the Policy Engine.

The whole point of the Policy Engine is to provide a local
execution environment for the operator, so that the operator would
not have to program an info model or a data model. The Policy
Engine, however, is not in the charter. So, even if I have a
scripting language, what happens if the protocol changes from
SNMP to xyz? I either design a simple solution focused on getting
one (or a couple) of protocols right, or I design a more robust
solution to scale. In either case, it is beyond the purview of the
info model to say what SNMP is, what ports it uses, and what
disable (or any other verb) is. </jcs>

> The next problem is identifying the administrative domain
> boundaries, which requires a topology database that is
> available to SUPA policies.

<jcs> I don't think that most topology databases have such
associated metadata available in an interoperable form. </jcs>

> The YANG data needed to define a policy could be anything
> from a complete decomposition of all logic into YANG data
> (which nobody seems to think will work) to a leaf containing
> the name of the script to invoke when a pre-configured
> event is received.

<jcs> Count me as one that doesn't like the former :-)
I agree with the latter </jcs>

> I prefer a solution where the smarts are provided by the
> client, not built into the policy engine. Programming in YANG
> is a non-starter, but programming in a scripting language that
>  is very YANG-aware is quite the opposite.

<jcs> I would actually favor the latter, only because if all the
smarts are defined by the client, then how do we achieve
interoperability?

I'm also not convinced that a scripting language would work
(unless by this you mean a policy DSL). For example, suppose
I choose PERL, or Python, or JavaScript. What I get is varying
levels of functionality, most of which I don't need. What I don't
get is any ability to know what a network object is.
</jcs>

happen.

<jcs> This could certainly work. But, if it was me, I would hope that the
scripts used in the condition and action portions of the rule would be
the same.
Furthermore, I think building a new scripting language is a non-starter
I think appending network object libraries to an existing scripting
language (e.g., Python) is much harder than just building a DSL. </jcs>

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Sun, 16 Aug 2015 22:56:34 -0700

> we either do something that
>
> (b) exposes even simple boolean expressions as complex collections
>      of YANG objects (leading to something way too complex to be
>      used for anything more serious than hello world examples), or
>

<jcs>
I definitely agree with (a).

I'm not sure about (b). If we look at draft-shaikh-rtgwg-policy-model-01,
then isn't this what we is there? Surely, if it is bad for SUPA, it should
be bad for the RTGWG. Of course, if the YANG in this example is
replaced by some scripting language, then maybe the problem goes
away, since the Boolean statements are encapsulated as objects,
which was the approach taken in draft-strassner-supa-info-model.

I agree with (c). If we define such strings, then if we don't at least
define the translation function, or (possibly exemplar) implementations
of the Policy Engine, then I don't see how this could result in
interoperable solutions.
</jcs>

...

> So the proponents of the other approaches need to explain how
> they are going to implement a simple policy like 'disable SNMP
> on all edge routers'.

<jcs>
I'm not sure I completely understand the scriptable approach, and
what you would use as a scripting language. If it is a traditional
scripting language (e.g., PERL, Python, JavaScript), then that
language doesn't understand networking concepts. Hence, I feel
that it would be better to build a networking DSL.

Which, of course, leads me to agree with your proposal :-)
</jcs>

-- 
regards,
John

---

From: Maxim Klyus <[email-masked]>
Date: Mon, 17 Aug 2015 07:41:53 +0000

Hi Michael,

My comments inline.

________________________________________
From: Supa [[email-masked]] on behalf of Scharf, Michael (Michael) [[email-masked]]
Sent: Saturday, August 15, 2015 9:22 PM
To: [email-masked]; 'John Strassner'
Cc: 'Juergen Schoenwaelder'; 'Romascanu, Dan (Dan)'; 'Eggert, Lars'; 'Benoit Claise'; 'Adrian Farrel'; [email-masked]
Subject: Re: [Supa] SUPA charter proposal

Hi Narasimha,

--snip---
ECA Policy:

   Action:

1) How does the YANG data policy model refer to "user's location"? Probably, user location could be a leaf in some YANG model, right?
[MK] I guess the term "VPC user's location is changed" doesn't actully mean we have some geolocation there, just like a solid-generic term. Yes location can be a parameter in some YANG models that's right, but I don't really see any connection here.

[MK] Like an example we just got an event with some parameter like an IP, and we can track location based on this IP, depending on our internal implementation, we even don't need to know exact location.
[MK] We just can see new VPC IP address 192.168.10.10 - ok this IP pool belongs SJ California, or even IP is the same like previously we can track IP+MAC Address available on other eqipment port now and equipment located in SJ California.
[MK] Usually such things tracked by OSS when network object geograficaly moved to other area. Or VPC subscriber can even inform us througth the portal....whatever.

[MK] I'm returning to your question each implementor can define by itself what does mean actually "VPC location changed", it means internaly in OSS we have some set of the rules (track IP, track MAC...whatever) but output result will be - event "VPC location changed"="%Network_object% location changed"
[MK] As you can see potentially we can say "VPC location changed" - solid term now, it does not matter how we track it. But what actualy does matter this event happend for particular network object.

[MK] I belive we are discusiing some concrete implementation here? Potentially we can find such example where we need to slect network objects by geo-location parameters for some batch-configuration purpose.
[MK] Each implemetor have a full freedom how to use policy based on internal mappings that's why SUPA define it like a generic.

[MK] Again "Condition: network_load(DC_old, DC_new) < threshold" can be potentially the solid generic term. We can have some internal logic how to map and handle this condition inside our implementation.

[MK] I'm not sure I understand your question well.  But here we need collect network objects like one VM also we need to take some appropriate YANG data model for let say OpenStack and build configuration snippets based on it. (activate new VM. decativate old VM)
[MK] Yes, DC managment and even SDN solution don't need Netconf/Restconf/YANG at all. Everything can be managed by scripts this is what Network/IT industry actually have now.
[MK] I'm especially pointing to E2E orchestration and administrative/management domain interacton wehere it is seems to be a big problem. The value of generic policy can be really costless.
[MK] If generic policy defined one administratve domain/managment domain can send policy to other domains for E2E orhcestration, however this generic policy can be converted by other administrative/managment domain particulary to own set of rules and this is awesome.
[MK] From one hand policy give us unification in e2e managment from other hand we have a freedom in implementation.

[MK] Will be some Error event. And potentially we can have another policy which handles these particular error events.

Thanks

Michael

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Mon, 17 Aug 2015 11:25:09 +0000

Regarding (b): draft-shaikh-rtgwg-policy-model only has to support a set of operators/expressions required for this specific domain. The same applies to the actions. It is clear that one can write a domain specific YANG data model for every type of policy. But to me it is hard to see what is “generic” in that case. Thus, if SUPA shall ship generic YANG data models, I’d really like to understand how SUPA wants to deal with arbitrary Boolean expressions therein (and other script language features, e.g., for the action list).

For instance, as mentioned elsewhere, unless I miss something solving use cases such as example 2 in draft-vadrevu-supa-applicability could require the support of an operator to compare geo-coordinates. This is a relatively advanced Boolean operator, but it could be broadly applicable. Where would SUPA draw the line between what subset of features of a complete script language is encoded in YANG, and what not?

If the design space for script languages was not well understood right now, the charter could foresee a re-chartering.

Michael

From: John Strassner [mailto:[email-masked]]
Sent: Monday, August 17, 2015 7:57 AM
To: Juergen Schoenwaelder; Andy Bierman; Scharf, Michael (Michael); John Strassner; Romascanu, Dan (Dan); Eggert, Lars; Benoit Claise; Adrian Farrel; [email-masked]
Subject: Re: [Supa] SUPA charter proposal

<jcs>

...

<jcs>

On Sat, Aug 15, 2015 at 1:22 PM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

+1

/js

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587<tel:%2B49%20421%20200%203587>         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103<tel:%2B49%20421%20200%203103>         <http://www.jacobs-university.de/>

--
regards,
John

---

From: John Strassner <[email-masked]>
Date: Mon, 17 Aug 2015 23:17:16 +0000

>> I'm not sure about (b). If we look at draft-shaikh-rtgwg-
>> policy-model-01, then isn't this what we is there? Surely,
>> if it is bad for SUPA, it should be bad for the RTGWG.

> Regarding (b): draft-shaikh-rtgwg-policy-model only has to
> support a set of operators/expressions required for this specific
> domain. The same applies to the actions.

<jcs2>
Sorry, you lost me. If the design is bad for one criterion, that is one
too many.
</jcs2>

> It is clear that one can write a domain specific YANG data model
> for every type of policy.

<jcs2>
Sure, but why would you do this? I don't follow your point here.
</jcs2>

> But to me it is hard to see what is “generic” in that case. Thus,
> if SUPA shall ship generic YANG data models, I’d really like to
> understand how SUPA wants to deal with arbitrary Boolean
> expressions therein

<jcs2>
This was my earlier point. Something as simple as a match-action
is now done multiple different ways in multiple different WGs.
The point of SUPA is to standardize the representation and
structure of a policy rule.
</jcs2>

> (and other script language features, e.g., for the action list).

<jcs2>
WHICH scripting language are you assuming? Or do you really
mean a DSL?
</jcs2>

regards,
John

John Strassner, Ph.D.
CTO, Software Laboratory, CRD

Futurewei Technologies
US R&D Center
2330 Central Expressway
Building A, office A2-2143
Santa Clara, California   95050

  Office:  +1.408.330.4923
  Email:   [email-masked]<mailto:[email-masked]>

From: Supa [mailto:[email-masked]] On Behalf Of Scharf, Michael (Michael)
Sent: Monday, August 17, 2015 4:25 AM
To: John Strassner; Juergen Schoenwaelder; Andy Bierman; Romascanu, Dan (Dan); Eggert, Lars; Benoit Claise; Adrian Farrel; [email-masked]
Subject: Re: [Supa] SUPA charter proposal

Michael

<jcs>

...

<jcs>

+1

/js

--
regards,
John

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 18 Aug 2015 00:16:20 +0000

Hi Maxim,

I think I understand how an OSS system can realize these kind of policies using internal logic. However, I do not understand how the solutions you explain for example 2 would indeed leverage a SUPA YANG model, and if so, how that YANG data model would look like if the implementations should be interoperable (e.g., if two different OSS systems shall understand the same policy).
 
So, I'll try once again to phrase my question: If the policy processing is entirely up to the implementer, as you seem to imply in your e-mail, what would actually be standardized in the YANG data model? Does this mean that you want SUPA to standardize something like:

--snip---
container supa-policy-events {
  leaf specification {
     description "Implementation-internal specification of event";
     type string;
  }
}
container supa-policy-conditions {
  leaf specification {
     description "Implementation-internal specification of conditions";
     type string;
  }
}
container supa-policy-actions {
  leaf specification {
     description "Implementation-internal specification of actions";
     type string;
  }
}
--snip--

If not, what other YANG data model would solve example 2 in draft-vadrevu-supa-applicability? How can this example 2 be done generically without somehow standardizing either a script language or the internal processing in the policy engine? I am really lost here.

Thanks

Michael

> From: Supa [mailto:[email-masked]] On Behalf Of Maxim Klyus
> Sent: Monday, August 17, 2015 9:42 AM
> To: Scharf, Michael (Michael); [email-masked]; 'John Strassner'
> From: Supa [[email-masked]] on behalf of Scharf, Michael
> (Michael) [[email-masked]]
> Similar to other examples, it is not clear to me how the examples
> mentioned in this document tie into the YANG data model that SUPA shall
> provide for ECA.
> 
> 1) How does the YANG data policy model refer to "user's location"?
> Probably, user location could be a leaf in some YANG model, right?
> [MK] I guess the term "VPC user's location is changed" doesn't actully
> mean we have some geolocation there, just like a solid-generic term.
> Yes location can be a parameter in some YANG models that's right, but I
> don't really see any connection here.
> 
> 2) What logic operators are needed to detect whether "user's location"
> has changed? For instance, does this policy need an operator that can
> compare geo-coordinates? If so, would that operator be somehow be
> defined in the generic YANG data model? (Well, many other policy could
> also leverage comparison of geo-coordinates, so providing it for all a
> generic base model could be a reasonable solution, right? Or not?)
> 
> [MK] Like an example we just got an event with some parameter like an
> IP, and we can track location based on this IP, depending on our
> internal implementation, we even don't need to know exact location.
> [MK] We just can see new VPC IP address 192.168.10.10 - ok this IP pool
> belongs SJ California, or even IP is the same like previously we can
> track IP+MAC Address available on other eqipment port now and equipment
> located in SJ California.
> [MK] Usually such things tracked by OSS when network object
> geograficaly moved to other area. Or VPC subscriber can even inform us
> througth the portal....whatever.
> 
> [MK] I'm returning to your question each implementor can define by
> itself what does mean actually "VPC location changed", it means
> internaly in OSS we have some set of the rules (track IP, track
> MAC...whatever) but output result will be - event "VPC location
> changed"="%Network_object% location changed"
> [MK] As you can see potentially we can say "VPC location changed" -
> solid term now, it does not matter how we track it. But what actualy
> does matter this event happend for particular network object.
> 
> [MK] I belive we are discusiing some concrete implementation here?
> Potentially we can find such example where we need to slect network
> objects by geo-location parameters for some batch-configuration
> purpose.
> [MK] Each implemetor have a full freedom how to use policy based on
> internal mappings that's why SUPA define it like a generic.
> 
> 3) Where does the parameters "network_load", "DC_old", and "DC_new"
> come from? For instance, does this require a lookup in a traffic matrix
> if there are more than 2 data centers, with corresponding indexes etc.?
> 
> [MK] Again "Condition: network_load(DC_old, DC_new) < threshold" can be
> potentially the solid generic term. We can have some internal logic how
> to map and handle this condition inside our implementation.
> 
> 4) How are the actions triggered? Note that DC management solutions may
> not necessarily have a NETCONF interface. So, does the action lists
> refer to external scripts? One script? Or several scripts?
> 
> [MK] I'm not sure I understand your question well.  But here we need
> collect network objects like one VM also we need to take some
> appropriate YANG data model for let say OpenStack and build
> configuration snippets based on it. (activate new VM. decativate old
> VM)
> [MK] Yes, DC managment and even SDN solution don't need
> Netconf/Restconf/YANG at all. Everything can be managed by scripts this
> is what Network/IT industry actually have now.
> [MK] I'm especially pointing to E2E orchestration and
> administrative/management domain interacton wehere it is seems to be a
> big problem. The value of generic policy can be really costless.
> [MK] If generic policy defined one administratve domain/managment
> domain can send policy to other domains for E2E orhcestration, however
> this generic policy can be converted by other administrative/managment
> domain particulary to own set of rules and this is awesome.
> [MK] From one hand policy give us unification in e2e managment from
> other hand we have a freedom in implementation.
> 
> [MK] Will be some Error event. And potentially we can have another
> policy which handles these particular error events.
> 
> To me, this type of use cases is clearly doable in whatever script or
> programming language. In YANG, it seems doable if Event, Condition, and
> Action all simply point to (highly domain-specific) scripts. But beyond
> that I am lost what the WG would actually standardize.
> 
> > Can you comment if this document elucidates a bit further or
> obfuscates
> > more?
> >
> > Thanks,
> > Narasimha
> >
> > From: Supa [mailto:[email-masked]] On Behalf Of Scharf,
> Michael
> > (Michael)

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 18 Aug 2015 00:34:11 +0000

John,

I am not assuming any script language or DSL. My question is simply whether SUPA would finally standardize a script language or DSL, or not. And the follow-up question is whether the presented use cases could indeed be realized w/o having the equivalent of a script language inside YANG. YANG mockups could perhaps help to answer my question.

Michael

From: John Strassner [mailto:[email-masked]]
Sent: Tuesday, August 18, 2015 1:17 AM
To: Scharf, Michael (Michael); John Strassner; Juergen Schoenwaelder; Andy Bierman; Romascanu, Dan (Dan); Eggert, Lars; Benoit Claise; Adrian Farrel; [email-masked]
Subject: RE: [Supa] SUPA charter proposal

<jcs2>

<jcs2>

<jcs2>

<jcs2>

regards,
John

John Strassner, Ph.D.

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

From: Supa [mailto:[email-masked]] On Behalf Of Scharf, Michael (Michael)
Sent: Monday, August 17, 2015 4:25 AM
To: John Strassner; Juergen Schoenwaelder; Andy Bierman; Romascanu, Dan (Dan); Eggert, Lars; Benoit Claise; Adrian Farrel; [email-masked]<mailto:[email-masked]>
Subject: Re: [Supa] SUPA charter proposal

Michael

From: John Strassner [mailto:[email-masked]]
Sent: Monday, August 17, 2015 7:57 AM
To: Juergen Schoenwaelder; Andy Bierman; Scharf, Michael (Michael); John Strassner; Romascanu, Dan (Dan); Eggert, Lars; Benoit Claise; Adrian Farrel; [email-masked]<mailto:[email-masked]>
Subject: Re: [Supa] SUPA charter proposal

<jcs>

...

<jcs>

+1

/js

--
regards,
John

---

From: John Strassner <[email-masked]>
Date: Tue, 18 Aug 2015 02:53:36 +0000

Michael,

In my opinion, the key problem is that an **isolated model**,
regardless of whether it is an info model or a data model or both,
is NOT able to solve any of these policies. Note that by "isolated",
I mean the use of a model without additional software. This has
been variously referred to as the "policy translation function" or
the Policy Engine in past emails and the drafts.

As Juergen pointed out, the rewritten charter does not include
work on this. So it is immaterial if it is a scripting language or a
custom DSL. I don't think we can implement interoperable policies
without such software.

Finally, if by "...the equivalent of a script language inside YANG"
you mean having a leaf reference a script, I fail to see how that
helps interoperability.

regards,
John

John Strassner, Ph.D.

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

From: Scharf, Michael (Michael) [mailto:[email-masked]]
Sent: Monday, August 17, 2015 5:34 PM
To: John Strassner; John Strassner; Juergen Schoenwaelder; Andy Bierman; Romascanu, Dan (Dan); Eggert, Lars; Benoit Claise; Adrian Farrel; [email-masked]
Subject: RE: [Supa] SUPA charter proposal

John,

Michael

<jcs2>

<jcs2>

<jcs2>

<jcs2>

regards,
John

John Strassner, Ph.D.

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

Michael

<jcs>

...

<jcs>

+1

/js

--
regards,
John

---

From: Maxim Klyus <[email-masked]>
Date: Tue, 18 Aug 2015 05:44:40 +0000

Hi Michael,

"processing is entirely up to the implementer" - this is exactly SUPA charter saying now "....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."

"what would actually be standardized in the YANG data model?" - POLICIES as INPUT: 1) how to build policies correctly based on infomodel 2) format of regular expressions for generic policies

--snip---
container supa-policy-events {
  leaf specification {
     description "GENERIC specification of event";
     type string;
  }
}
container supa-policy-conditions {
  leaf specification {
     description "GENERIC specification of conditions";
     type string;
  }
}
container supa-policy-actions {
  leaf specification {
     description "GENERIC specification of actions";
     type string;
  }
}
--snip--

The above rule will be valid for multiple management/administrative domains, but how this rule will be handled within each domain depends on a domain holder/implementer.

Let others correct me if I missed something.

Regards,
Max

________________________________________
From: Scharf, Michael (Michael) [[email-masked]]
Sent: Tuesday, August 18, 2015 3:16 AM
To: Maxim Klyus; [email-masked]; 'John Strassner'
Cc: 'Juergen Schoenwaelder'; 'Romascanu, Dan (Dan)'; 'Eggert, Lars'; 'Benoit Claise'; 'Adrian Farrel'; [email-masked]
Subject: RE: [Supa] SUPA charter proposal

Hi Maxim,

--snip---

Thanks

Michael

---

From: Andrew Veitch <[email-masked]>
Date: Tue, 18 Aug 2015 19:55:55 +0000

Hi Juergen et al,

I am confused by some of the discussion around scripting or a DSL and would appreciate any clarification.  I have written some comments and question around one of the emails earlier in the thread.

I hope this is clear, my apologies for any fuzziness.

Thanks very much,

Andy

On Aug 15, 2015, at 4:22 PM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

+1

<afv>
I think all comments have been in agreement that this makes no sense, though I am not sure exactly what you mean by “every type of policy”.

I would say that there do need to be data models for all domains, e.g. services, etc.  for which a policy is to be applied.  I am not sure if you would consider the cost of doing this to be too much.  For there to be interoperable policies, then the domains for the interoperable policies must be represented in well defined, unambiguous, complete and consistent data models.
</afv>

<afv>
Ok, are you saying that Yang is not a good modeling solution to represent policies?   Is this because it has too much syntax clutter and is hard to read or write or because it is too weak?  Do you believe there are limitations with what logical expressions Yang can represent, i.e. it is not complete (enough)?   If it is because of a Yang limitation, could that be addressed with an extension to Yang?
</afv>

<afv>

Agreed, this makes no sense.

</afv>

snippet embodied in the action.

<afv>

Including a config snippet in an action seems quite explicit and likely limits interoperability.  A general expression in the action section would be interoperable.
Additional models (or these could be within the domain data models) and the policy engine code could interpret the action expression in the Yang model to determine the appropriate configuration action.

</afv>

The condition needs to hook into the
meaningful complexity.

<afv>

Are you saying then that a scripting language should be a WG deliverable?  Is this a new language, or extensions to one that exists?

Are you saying that there would be specialized functions and operators within the language to represent the conditions (boolean expressions) and actions, e.g. as in a ECA policy?  Would there be any representation of conditions or actions in Yang data model itself?

Could you explain how the scripting is less complex than Yang data models?   Where does the complexity go?  If we are to represent policies in a generic way, then any scripting code must present the generic form and then see it translated to specific activities that rely on an understanding of how the information all maps together.

</afv>

But as said above, unfortunately Benoit's
proposed charter rules this option out. So the proponents of the other
approaches need to explain how they are going to implement a simple
policy like 'disable SNMP on all edge routers’.

<afv>

Offhand, I might create a model(s) that represents the syntax and semantics I need to process the action statements or simply the goal conditions to be achieved.  Also, much of this might be included in the domain data models for which the policy works.  My policy agent code could then use that to parse the action expression and with other context information to lead me to the right set of functions and parameters to achieve the goal - in my proprietary or open source code.  This would require vendors or open source projects to support the action descriptions.

Having said that, I am not a proponent of anything yet, other than doing what is possible to ensure interoperability and to keep things simple.  I realize defining the syntax/semantics for one or more statement in the action section of a policy data structure is not that different from defining a language, though with the Yang models, the representations are all modeled, not encoded.

</afv>

/js

---

From: Andrew Veitch <[email-masked]>
Date: Tue, 18 Aug 2015 14:11:57 +0000

Hi John et al,

I have some comments and questions below.

On Aug 17, 2015, at 10:53 PM, John Strassner <[email-masked]<mailto:[email-masked]>> wrote:

Michael,

I am not sure what you mean by “solving” a policy.

Do you mean implementing / deploying support for the policy?

When the term “policy translation function” is used, is the meaning of “translation” that the policy is translated into its implementation?  Or translation to some other model or models, perhaps ones closer to the infrastructure level?

Policy Engine means something that ultimately creates the tangible support for the policy in its domain, as I understand it.

More than that, the charter specifically calls out that the policy engine (or whatever application) that processes the policy definitions IS NOT to be defined by the WG.

When you write, “implement interoperable policies”, I do not understand why there is a dependency on the creation of the software (other than to mean that some application is needed to process and implement policies, whether interoperable or not.)

Based on what I have read on the SUPA threads, “interoperability” means that separate policy engines or applications will interpret policy definitions in the same way AND create implementations that support the policies consistently.  So interoperability depends upon a clear and unambiguous definition of the policy data models and the data models representing the set of domains relevant for those policies.

It is the creation of good data models, for policies, the domains of these policies (e.g. services, networks, devices) and the relationships among them that will drive the interoperability, not the software.

I do believe that it would benefit the SUPA group for there to be implementations in order to help identify problem areas, identify ways to improve the models, etc.  But these should not be WG deliverables.

regards,
John

John Strassner, Ph.D.

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

From: Scharf, Michael (Michael) [mailto:[email-masked]]
Sent: Monday, August 17, 2015 5:34 PM
To: John Strassner; John Strassner; Juergen Schoenwaelder; Andy Bierman; Romascanu, Dan (Dan); Eggert, Lars; Benoit Claise; Adrian Farrel; [email-masked]<mailto:[email-masked]>
Subject: RE: [Supa] SUPA charter proposal

John,

Michael

From: John Strassner [mailto:[email-masked]]
Sent: Tuesday, August 18, 2015 1:17 AM
To: Scharf, Michael (Michael); John Strassner; Juergen Schoenwaelder; Andy Bierman; Romascanu, Dan (Dan); Eggert, Lars; Benoit Claise; Adrian Farrel; [email-masked]<mailto:[email-masked]>
Subject: RE: [Supa] SUPA charter proposal

<jcs2>

<jcs2>

<jcs2>

<jcs2>

regards,
John

John Strassner, Ph.D.

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

Michael

From: John Strassner [mailto:[email-masked]]
Sent: Monday, August 17, 2015 7:57 AM
To: Juergen Schoenwaelder; Andy Bierman; Scharf, Michael (Michael); John Strassner; Romascanu, Dan (Dan); Eggert, Lars; Benoit Claise; Adrian Farrel;[email-masked]<mailto:[email-masked]>
Subject: Re: [Supa] SUPA charter proposal

<jcs>

...

<jcs>

+1

/js

---

From: John Strassner <[email-masked]>
Date: Wed, 19 Aug 2015 23:02:48 +0000

> I am not sure what you mean by “solving” a policy.

<jcs>
Sorry, I meant solving the solution implied by any of
these policies.
</jcs>

Do you mean implementing / deploying support for the policy?
<jcs>
More specifically, a data model defines data structures. It
doesn't define logic. This is why there was a Policy Engine
defined in draft-klyus (figure 1) and in my presentation
(slide 6 of IETF93).

Put another way, the best policy data model in the world
can NOT, by itself, be used to solve these problems.
</jcs>

When the term “policy translation function” is used, is the meaning of “translation” that the policy is translated into its implementation?  Or translation to some other model or models, perhaps ones closer to the infrastructure level?
<jcs>
Policy translation takes an operator-defined policy and
generates YANG configuration snippets.
</jcs>

Yuperooni!
</jcs>

regards,
John

John Strassner, Ph.D.

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

From: Andrew Veitch [mailto:[email-masked]]
Sent: Tuesday, August 18, 2015 7:12 AM
To: John Strassner
Cc: Scharf, Michael (Michael); John Strassner; Juergen Schoenwaelder; Andy Bierman; Romascanu, Dan (Dan); Eggert, Lars; Benoit Claise; Adrian Farrel; [email-masked]
Subject: Re: [Supa] SUPA charter proposal

Hi John et al,

Michael,

regards,
John

John Strassner, Ph.D.

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

John,

Michael

<jcs2>

<jcs2>

<jcs2>

<jcs2>

regards,
John

John Strassner, Ph.D.

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

Michael

<jcs>

...

<jcs>

+1

/js

---

From: Georgios Karagiannis <[email-masked]>
Date: Thu, 20 Aug 2015 15:22:46 +0000

Hi all,

Thanks to Benoit, Adrian, Robert and Dan, the updated charter is now addressing several issues that were raised during the SUPA BOF. One of these issues is related to the function required to convert (map, translate, transform, etc.) the policy to specific device-specific domain models.
Currently, the charter mentions that this converting function is out of the SUPA scope. I can agree with that, but it could be useful to at least provide (and implement) some examples that show how this conversion function could be realized.

Therefore, I propose to add text, similar to the one shown below, on the paragraph that refers to the applicability document:

Change from:
OLD:
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.

NEW (added a new sentence at the bottom of this paragraph):
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 applicability document will include examples to show how explicit instructions can be used in order to convert (map, translate, transform, etc.) the policy to specific device-specific domain models.

Best regards,
Georgios

> Sent: 07 August 2015 18:03
> To: [email-masked]
> Cc: Eggert, Lars
> 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
> understanding of policies that apply in different environments, will make the
> 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.
> 
> 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.
> 
> -   The specification of a new policy language. The YANG data models are to be
> policies in network elements (which are usually interpreted in isolation, and
> often at timescales that require optimization for specific purposes).
> 1) A document that explains the scope of the policy-based management framework
> and how it relates to existing work of the IETF.
> 
> 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.
> 
> 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

---

From: "Narasimha Rao Vadrevu" <[email-masked]>
Date: Thu, 20 Aug 2015 08:42:35 -0700

Comment in line

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Georgios Karagiannis
Sent: Thursday, August 20, 2015 8:23 AM
To: [email-masked]
Cc: Benoit Claise <[email-masked]>; [email-masked]
Subject: Re: [Supa] SUPA charter proposal

Hi all,

Change from:
OLD:

[Narasimha Vadrevu] Show examples and say these are out of scope. Not making much sense to me.

Best regards,
Georgios

> and will facilitate the rapid development of standards-based data models that include policy elements.
> 
> 
> orchestrator, a network
> element) that takes high-level, possibly network-wide policies as 
> policy, which can point to device-, technology-, and service-specific 
> YANG models of other working groups.
> 
> 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.
> 
> -   The specification of a new policy language. The YANG data models 
> embedded policies in network elements (which are usually interpreted 
> policy engine that maps a specific policy instance to actual configuration snippets.
> 
> List of work items:
> 
> paradigm, may be produced. These models will be designed to be generic and extensible.
> 
> relevant for network operators. The examples may tie into 
> configuration models or network service models developed by other working groups.
> 
> are re- used in future IETF specifications (and, ideally, 
> not impede work in other working groups while waiting for SUPA to produce its deliverables.
>

---

From: Georgios Karagiannis <[email-masked]>
Date: Sun, 23 Aug 2015 18:49:36 +0000

Dear all,

Please note that  I have been discussing my suggestion off-line and have been convinced that we do not need to make the change that I proposed below. 
I am happy with the charter text as currently posted.

Best regards,
Georgios

> Sent: 20 August 2015 17:23
> To: [email-masked]
> Cc: Benoit Claise; [email-masked]
> Thanks to Benoit, Adrian, Robert and Dan, the updated charter is now
> addressing several issues that were raised during the SUPA BOF. One of these
> issues is related to the function required to convert (map, translate,
> transform, etc.) the policy to specific device-specific domain models.
> Currently, the charter mentions that this converting function is out of the
> SUPA scope. I can agree with that, but it could be useful to at least provide
> (and implement) some examples that show how this conversion function could be
> realized.
> 
> Therefore, I propose to add text, similar to the one shown below, on the
> paragraph that refers to the applicability document:
> 
> Change from:
> OLD:
> network operators.
> network operators.
> The applicability document will include examples to show how explicit
> instructions can be used in order to convert (map, translate, transform, etc.)
> the policy to specific device-specific domain models.
> 
> Best regards,
> Georgios
> 
> 
> >
> > 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.
> >

---

From: joel jaeggli <[email-masked]>
Date: Sun, 23 Aug 2015 23:17:13 -0700

Thanks!

joel