Subject: [Supa] Existing policy initiatives inside the IETF

From: Benoit Claise <[email-masked]>
Date: Mon, 18 May 2015 17:39:22 +0200

Dear all,

As discussed today in our call, here are existing policy drafts
- http://datatracker.ietf.org/doc/draft-shaikh-rtgwg-policy-model/,
- 
https://tools.ietf.org/html/draft-asechoud-netmod-diffserv-model-01#section-5.3, 

- http://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/
- BGP (I understand that those two drafts will be merged soon):
     http://datatracker.ietf.org/doc/draft-shaikh-idr-bgp-model/
     http://datatracker.ietf.org/doc/draft-zhdankin-idr-bgp-cfg/

Regards, Benoit

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 18 May 2015 20:24:13 +0200

> - http://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/

Why is this a policy draft?

I mean, if this is policy, is NACM not also policy? Is not pretty much
everything I can configure policy then?

/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: "Natale, Bob" <[email-masked]>
Date: Mon, 18 May 2015 19:36:52 +0000

Right. ACLs are a policy implementation mechanism for the access control domain.

That ACLs (like many other domain-specific policy implementation mechanisms) often have to pass as a policy expression mechanism often leads to misalignment between network behavior and policy-makers' original intent.

A policy makers intent might best be expressed thusly "Customers shall have no access to billing data between midnight and 6:00am on national holidays" ... translating that to a set of conforming ACLs involves much intermediary knowledge -- some of a potentially dynamic nature -- and several intermediary translations.

Standardizing how to express policies at the "policy maker" level is a necessary first step to a rational streamlining of the intermediary stuff. Attempting to accomplish the same outcome starting from the other direction cannot work (as we should see now from many decades of doing it that way, IMHO).

Avanti,
BobN

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Monday, May 18, 2015 2:24 PM
To: Benoit Claise
Cc: [email-masked]
Subject: Re: [Supa] Existing policy initiatives inside the IETF

I mean, if this is policy, is NACM not also policy? Is not pretty much everything I can configure policy then?

/js

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 18 May 2015 18:50:38 -0700

> everything I can configure policy then?

It is possible for all config to be policy-driven.
Actually, ACL and NACM are 2 modules likely to be part
of a policy implementation.

Connecting policy models to config and operational models
is an interesting topic to me. How much can be done
with automation tools, and what meta-data is needed in
the YANG to enable those tools?

> /js

Andy

---

From: Maxim Klyus <[email-masked]>
Date: Tue, 19 May 2015 07:42:04 +0000

Dear SUPA,

I apologize, I would like to pay more attention to this SUPA discussion but I don't able at the moment, so in short.

IMHO, we have this misunderstanding because current generic-policy model is very abstract and there are no any reference materials inside or outside this draft to define mapping with existing IETF work.
I will try to simplify my explanation as much as possible, because we already have cognitive dissonance about SUPA caused by the topic complexity, so kindly excuse me if some/many details will be missed.

1) If we still trying to map existing data models to generic-policy informational model in service context:

https://tools.ietf.org/html/draft-strassner-supa-generic-policy-info-model-01#section-5.4

"A SUPAPolicyComposite class represents a SUPA Policy as a
   hierarchy of Policy objects, where the hierarchy contains
   instances of a SUPAPolicyAtomic and/or SUPAPolicyComposite
   object."

In my understanding service supposed to be a service if something joins service resources and I guess it should be the Composite Policy.
As we can see from the above definition Composite Policy can be the joint point for service resources because it can refer to other Policies which refer to data models or another Composite Policies which refer to resource data-models.
To be more concrete I would like to take L3VPN example and our focus will be existing policy data models highlighted by Benoit.

                 +-------------L3VPN Service---------------------+
                 |                                                                      |
L3VPN resources                                         L3VPN Composite policy
   |        |          |                                                |                 |              |
   |        |          |                                                |                 |              |
   |        |       ACL data-model <---> Security Policy       |              |
   |        |                                                                               |              |
   |     QoS  data-model<-----------------------------> SLA Policy       |
   |                                                                                                         |
 BGP <----------------------------------------------------> Traffic Management Policy

On the above diagram left part responsible for service resource configuration and service deployment, right part responsible for service integrity, operation and management (direct management or intent based things).
In practice left part data-models can be used for low level (less intelligent) Network Controllers and right part can be used by high-level (intelligent) Network Controllers in hierarchy cases or orchestration (below diagram).

                          Orchestrator
                                   or
                            High-Level
                    Network Controller
                     /                             \
                   /                                 \
          Low-level                       Low-level
Network Controller        Network Controller
  |           |          |                  |          |           |
NE1      NE2     NEx            NE1      NE2     NEx

And may be current misunderstanding caused by really high-level abstraction of generic-policy model.
Actually there are no such definitions like Security Policy, SLA Policy or Traffic Management Policy inside this generic framework, but I believe it should be defined, maybe outside?
If it will be done in generic draft framework we can call it SubClasses of the Root Policy Class? Lets John correct me if I'm wrong. Anyway I think we have an option it can be done.

2) If we want to map exiting data models to generic-policy informational model in resource context:

Security Management Policy  <-------------+                                                      +-------------> ACL
                                                                         |                                                      |
Traffic Management  Policy <---------------+----> Network Resources<-------+-------------->BGP
                                                                         |                                                      |
SLA Management Policy <--------------------+                                                      +-------------->QoS
                                                                         |                                                      |
Whatever Policy  <-----------------------------+                                                      +-------------->Interfaces
                                                                                                                                 |
                                                                                                                                 +-------------->Whatever resource data models

On above diagram Policy on the left can be Composite or Atomic so it could refer to one or several resource data-models on the right.

Summary:
My proposal - to define functional policies inside or outside generic policy framework so it could be clearly mapped to existing IETF data models.
As described earlier, I see as minimum 3 significant functional contexts - Security, SLA, Traffic Management.

Any arguments and comments appreciated.

PS1. Similar topic already was discussed on L3SM earlier where I was mentioned the only service aspect - SLA.
Imho, if we discussing something in service context such things like policy should be defined in other case we discussing resources configuration related to some service.
Or we need to define clearly what actually word "service" means, like was pointed by Juergen previously, to be agreed at this point.

PS2. It will be great to discuss the Policy topic as simple as possible (with examples/use cases) to understand clear direction we are going to move and value and benefits SUPA can brings.

Best Regards,
Maxim Klyus

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Monday, May 18, 2015 6:39 PM
To: [email-masked]
Subject: [Supa] Existing policy initiatives inside the IETF

Dear all,

Regards, Benoit

________________________________
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: John Strassner <[email-masked]>
Date: Wed, 20 May 2015 11:21:56 -0700

I agree with Bob and Juergen.

The purpose of an ACL is to select traffic that meets some criteria. In
addition, it may perform a set of actions. As such, it represents a
mechanism to be used by policy, but is not itself policy, because there is
no decision being made. For example, an ACL could be used as the condition
part of an ECA policy rule - in this case, the ECA policy rule is doing the
decision making.

In draft-strassner-supa-generic-policy-info-model-01, section 3.2.2.1:

    SUPAPolicy is defined generically as a means to monitor and
    control the changing and/or maintaining of the state of one or
    more managed objects.

regards,
John

On Mon, May 18, 2015 at 12:36 PM, Natale, Bob <[email-masked]> wrote:

> That ACLs (like many other domain-specific policy implementation
> mechanisms) often have to pass as a policy expression mechanism often leads
> to misalignment between network behavior and policy-makers' original intent.
>
> A policy makers intent might best be expressed thusly "Customers shall
> have no access to billing data between midnight and 6:00am on national
> holidays" ... translating that to a set of conforming ACLs involves much
> intermediary knowledge -- some of a potentially dynamic nature -- and
> several intermediary translations.
>
> Standardizing how to express policies at the "policy maker" level is a
> necessary first step to a rational streamlining of the intermediary stuff.
> Attempting to accomplish the same outcome starting from the other direction
> cannot work (as we should see now from many decades of doing it that way,
> IMHO).
>
> Avanti,
> BobN
>

-- 
regards,
John