Subject: [Supa] SUPA Monday (May 11) meeting notes

From: Maxim Klyus <[email-masked]>
Date: Tue, 12 May 2015 12:13:09 +0000

Hi all,

Here is supa meeting notes.
Please correct me if something wrong.

Regards,
Max Klyus

________________________________
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, 13 May 2015 03:18:58 +0000

Hi Maxim,

First, thanks for taking the notes!
Second, here is some additional information to supplement them:

> Dan:  The main question how this information model mapped to 
>       yang models

<jcs> Formally, a **model mapping** defines a transform from a
model at one level of abstraction to another model at a different
level of abstraction. This is illustrated on slide 7 of the PBSM
presentation at IETF 92. I will add a definition to 
draft-strassner-supa-generic-policy-info-model (SPGIM). </jcs>

> Benoit: I wonder If current SUPA policy framework service 
>         specific or it's generic? How does is fit into routing 
>         BGP and QoS policy framework and how it can be reused?

<jcs> The current SUPA policy framework, as defined in SPGIM, is
**independent** of the service that it is managing. That is, the
same policy framework can be used for QoS, traffic routing, 
monitoring congestion, or other functions. </jcs>

> (Notes about fitting SUPA to middleboxes, TAPS, and SPUD)

<jcs> One of the poster-child examples of policy management is 
defining policy rules to instruct which functions should be
applied to (for example) a packet or a flow in what context. The
same traffic could be handled differently based on context. For
example, the policy rule "Access to the source code server is only
allowed through the company intranet" would deny access over any
connection that does not use the company's intranet. This is
similar to the example that Maxim was saying earlier in "Critical reply #2. Another example is service function chaining - a policy can be used to inspect a packet and then apply a programmable set of services (or not) to that packet. </jcs>

> Dan: OK, 2 questions: 1) If the policies we are discussing here
>      always related to some service? 2) How we binding this 
>      generic policy abstraction? What are we missing without 
>      this generic framework?

<jcs> That was three questions. :-)
More seriously, I dislike saying that a policy is **always**
related to a service, because then everything becomes a service,
and that is too simplistic. For example, I could define a policy
that changes the marking of a packet based on the value of one or 
more counters (e.g., do one thing if I get a packet processing
error, but do a different thing if I get a dropped packet). I 
don't view either of these as **services**, but rather **actions
on a resource**. </jcs>

regards,
John

Dr. 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]

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Maxim Klyus
Sent: Tuesday, May 12, 2015 5:13 AM
To: [email-masked]
Cc: Tina TSOU
Subject: [Supa] SUPA Monday (May 11) meeting notes

Hi all,

Regards,
Max Klyus