Subject: [Supa] critical question #2 - relation with other policy modelling efforts ongoing in the IETF

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 12 May 2015 11:41:25 +0000

Critical question #2 is:

-          How does the SUPA proposed scope of work relate to the other policy modelling efforts ongoing in the IETF? Does it help, does it avoid duplication?

Please answer the question and suggest text for the charter proposal and/or for the *-supa-* I-Ds.

Thanks and Regards,

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 May 2015 14:16:14 +0200

> -          How does the SUPA proposed scope of work relate to the other policy modelling efforts ongoing in the IETF? Does it help, does it avoid duplication?

My understanding is that ongoing policy modeling efforts in the IETF
are technology specific. SUPA tries to define a generic policy
framework that can complement technology specific work or in the long
run make technology specific work superfluous. Note that some policy
enforcement requires specific data models.

A case to make the relationship clearer are (stateless) packet filters
(commonly called ACLs in the networking industry). Packet filters
essentially enforce policy and they are implemented in the data
path. SUPA is not going into that territory. However, once there is a
standard data model to configure ACLs (currently worked on in NETMOD),
then ideally SUPA can hook into this and it allows me to express rules
or goals that control how the ACLs are configured in my network. This
example shows that SUPA can add value on top of an existing policy
mechanism. Another example, mentioned in the other thread, is
controlling access to network elements. We usually do not have policy
models to express such rules but once there is a configuration data
model, SUPA can ideally express policies on top of the configuration
model.

If successful, SUPA may help to avoid reinventing the wheel in
different colors in the IETF in the future.

/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: Maxim Klyus <[email-masked]>
Date: Tue, 12 May 2015 12:49:38 +0000

Hi Dan,

I agree with current Juergen explanation and explanation was done by John before.

SUPA deals with intent based things - the information model describes what we want to do instead of how we do it (not includes some specific configuration rules and details).
So from one hand SUPA decoupling informational model from the technology data model, but from other hand we can align policy related data models.

Best Regards,
Maxim Klyus

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Tuesday, May 12, 2015 3:16 PM
To: Romascanu, Dan (Dan)
Cc: [email-masked]
Subject: Re: [Supa] critical question #2 - relation with other policy modelling efforts ongoing in the IETF

> -          How does the SUPA proposed scope of work relate to the other policy modelling efforts ongoing in the IETF? Does it help, does it avoid duplication?

My understanding is that ongoing policy modeling efforts in the IETF are technology specific. SUPA tries to define a generic policy framework that can complement technology specific work or in the long run make technology specific work superfluous. Note that some policy enforcement requires specific data models.

A case to make the relationship clearer are (stateless) packet filters (commonly called ACLs in the networking industry). Packet filters essentially enforce policy and they are implemented in the data path. SUPA is not going into that territory. However, once there is a standard data model to configure ACLs (currently worked on in NETMOD), then ideally SUPA can hook into this and it allows me to express rules or goals that control how the ACLs are configured in my network. This example shows that SUPA can add value on top of an existing policy mechanism. Another example, mentioned in the other thread, is controlling access to network elements. We usually do not have policy models to express such rules but once there is a configuration data model, SUPA can ideally express policies on top of the configuration model.

If successful, SUPA may help to avoid reinventing the wheel in different colors in the IETF in the future.

/js

_______________________________________________
Supa mailing list
[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: Maxim Klyus <[email-masked]>
Date: Tue, 12 May 2015 14:16:27 +0000

Juergen,

If you kindly let me to expand a bit your example.

Let say, we take this really basic and easy operation - like blocking some traffic in our network.
In terms of informational model it will be: rule blocking some traffic. But in fact this traffic blocking could be done in several ways:

1) ACL rules
2) route to null
3) excluding vlan from trunk
4) shutdown subinterface
5) and even VPN session / interface termination

However the result will be particular traffic blocking and what we can see above actually mapping to IETF data models - ACL, routing, etc...

Other words in terms of information model I can say to my network: "please block this traffic in routing context" and here will be connection to IETF data model to some specific technology.

Best Regards,
Maxim Klyus

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Tuesday, May 12, 2015 3:16 PM
To: Romascanu, Dan (Dan)
Cc: [email-masked]
Subject: Re: [Supa] critical question #2 - relation with other policy modelling efforts ongoing in the IETF

/js

---

From: John Strassner <[email-masked]>
Date: Tue, 12 May 2015 23:57:12 +0000

+1

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 Juergen Schoenwaelder
Sent: Tuesday, May 12, 2015 5:16 AM
To: Romascanu, Dan (Dan)
Cc: [email-masked]
Subject: Re: [Supa] critical question #2 - relation with other policy modelling efforts ongoing in the IETF

/js

---

From: Ying Cheng <[email-masked]>
Date: Tue, 19 May 2015 07:29:01 +0800

Hi all,

I agree with Juergen's answer.

In addtion, SUPA provides both a framework to represent policy in general as well as exemplar YANG-based implementations for DDC. Service configuration parameters are defined as objects in the SUPA policy data model. Moreover, traditional policy, such as that used in routing, uses pre-defined, static rules to (for example) control the path taken by data packets. SUPA can define rules that:

   1) do this explicitly, but with more flexibility, using ECA-style rules
   2) do the above, but with mechanisms to adjust the decision based on (for example) context, using metadata
   3) do either of the above, but using a declarative (intent-based) style

BR,
Ying

2015-05-19 

Ying CHENG  程莹
China Unicom Network Technology Research Institute 中国联通网络技术研究院
Tel: +86-10-68799999-7702
Mobile: +86-18601102971

发件人： Juergen Schoenwaelder 
发送时间： 2015-05-12  20:16:30 
收件人： Romascanu, Dan (Dan) 
抄送： [email-masked] 
主题： Re: [Supa] critical question #2 - relation with other policymodelling efforts ongoing in the IETF 
 
.

如果您错误接收了该邮件，请通过电子邮件立即通知我们。[email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。
If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked] if you want to unsubscribe from this mail. We will immediately remove your information from our sending catalogue.

---

From: "Natale, Bob" <[email-masked]>
Date: Wed, 20 May 2015 05:52:23 +0000

+2 ... outstanding explanation by Juergen!

Avanti,
BobN

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Tuesday, May 12, 2015 7:57 PM
To: Juergen Schoenwaelder; Romascanu, Dan (Dan)
Cc: [email-masked]
Subject: Re: [Supa] critical question #2 - relation with other policy modelling efforts ongoing in the IETF

+1

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Tuesday, May 12, 2015 5:16 AM
To: Romascanu, Dan (Dan)
Cc: [email-masked]
Subject: Re: [Supa] critical question #2 - relation with other policy modelling efforts ongoing in the IETF

/js

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Wed, 20 May 2015 06:10:17 +0000

Not sure if I should say +3 to follow in progression, but Juergen examples look really good to me.

Be goode,

On 20 May 2015, at 13:52 , Natale, Bob <[email-masked]<mailto:[email-masked]>> wrote:

Avanti,
BobN

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Tuesday, May 12, 2015 7:57 PM
To: Juergen Schoenwaelder; Romascanu, Dan (Dan)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Supa] critical question #2 - relation with other policy modelling efforts ongoing in the IETF

+1

regards,
John

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

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Tuesday, May 12, 2015 5:16 AM
To: Romascanu, Dan (Dan)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Supa] critical question #2 - relation with other policy modelling efforts ongoing in the IETF

/js

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

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

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