Re: [Supa] Existing policy initiatives inside the IETF

Maxim Klyus <klyus@NetCracker.com> Tue, 19 May 2015 07:42 UTC

Return-Path: <klyus@NetCracker.com>
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4B71ACDED for <supa@ietfa.amsl.com>; Tue, 19 May 2015 00:42:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.611
X-Spam-Level:
X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RW296zZdotzf for <supa@ietfa.amsl.com>; Tue, 19 May 2015 00:42:08 -0700 (PDT)
Received: from umail.netcracker.com (umail.netcracker.com [84.47.142.180]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 858BF1ACDDC for <supa@ietf.org>; Tue, 19 May 2015 00:42:07 -0700 (PDT)
From: Maxim Klyus <klyus@NetCracker.com>
To: Benoit Claise <bclaise@cisco.com>, "supa@ietf.org" <supa@ietf.org>
Thread-Topic: [Supa] Existing policy initiatives inside the IETF
Thread-Index: AQHQkYDlXFKYL6swlEW9qf05tCc3QJ2CdcrA
Date: Tue, 19 May 2015 07:42:04 +0000
Message-ID: <11D8792D50CD7F46BFBA62E9E61D5A3A9DAC4751@umaildb5.netcracker.com>
References: <555A07AA.2040803@cisco.com>
In-Reply-To: <555A07AA.2040803@cisco.com>
Accept-Language: en-US, ru-RU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/supa/ZE9iPPfqQKwHfvN9N708sEn9lAE>
Subject: Re: [Supa] Existing policy initiatives inside the IETF
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." <supa.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/supa>, <mailto:supa-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/supa/>
List-Post: <mailto:supa@ietf.org>
List-Help: <mailto:supa-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/supa>, <mailto:supa-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 May 2015 07:42:10 -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:supa-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: Monday, May 18, 2015 6:39 PM
To: supa@ietf.org
Subject: [Supa] Existing policy initiatives inside the IETF

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

_______________________________________________
Supa mailing list
Supa@ietf.org
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.