Subject: [Supa] critical question #1 - distinct value of SUPA

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

Critical question #1 is:

-          What is the distinct value that the SUPA proposed scope of work brings?

In a few more words - what does SUPA do that other WGs in the IETF do not do? What does the IETF gain by chartering a SUPA WG? What will be lost by not chartering it?

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:02:51 +0200

> In a few more words - what does SUPA do that other WGs in the IETF do not do? What does the IETF gain by chartering a SUPA WG? What will be lost by not chartering it?

My take is that SUPA focuses on a generic policy infrastructure. If
SUPA is successful, we have a generic policy framework that can be
used to express policies based on top of arbitrary configuration data
models.

  Background: I am used to a policy configuration engine (for more
  than ten years) that we use to run our physical and our virtual
  machines. We are used to control things like the TCP congestion
  control algorithm we run on our machines, the configuration of our
  SSH daemons (disabling password or keyboard-interactive
  authentication mechanisms, the rules used to filter SYSLOG messages
  etc.) out of a central policy repository. I believe this is a rather
  common practice these days for system administrators. I would love
  to have a similar mechanism available to control how the network
  elements are setup. Unfortunately, network elements running
  proprietary software usually require manual or ad-hoc scripted
  control, something I personally would like to get rid of.

What will the IETF gain? If SUPA is successful, then the IETF will
have to produce less policy data models in the future (I am saying
less because there might still be special cases where hand-crafted
policy work is needed). What will the IETF loose? A chance to reduce
future work and to provide a consisten approach to automate policy
driven configuration of network elements and/or network services (for
me the boundary between configuring a network element and a network
service is blurry.)

/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: "Jun Bi" <[email-masked]>
Date: Tue, 12 May 2015 21:53:31 +0800

IMHO, SUPA will also illustrate the north bound API for policy abstraction
(between manager and controllers), in an environment that multiple
controllers (in different data center) involves.

Best Regards,
Jun

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Juergen Schoenwaelder
Sent: Tuesday, May 12, 2015 8:03 PM
To: Romascanu, Dan (Dan)
Cc: [email-masked]
Subject: Re: [Supa] critical question #1 - distinct value of SUPA

On Tue, May 12, 2015 at 11:38:09AM +0000, Romascanu, Dan (Dan) wrote:
> In a few more words - what does SUPA do that other WGs in the IETF do not
do? What does the IETF gain by chartering a SUPA WG? What will be lost by
not chartering it?

My take is that SUPA focuses on a generic policy infrastructure. If SUPA is
successful, we have a generic policy framework that can be used to express
policies based on top of arbitrary configuration data models.

What will the IETF gain? If SUPA is successful, then the IETF will have to
produce less policy data models in the future (I am saying less because
there might still be special cases where hand-crafted policy work is
needed). What will the IETF loose? A chance to reduce future work and to
provide a consisten approach to automate policy driven configuration of
network elements and/or network services (for me the boundary between
configuring a network element and a network service is blurry.)

/js

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

---

From: "Dacheng Zhang" <[email-masked]>
Date: Tue, 12 May 2015 22:07:22 +0800

+1

在 15-5-12 下午9:53， "Jun Bi" <[email-masked]> 写入:

>> -          What is the distinct value that the SUPA proposed scope of
>>work
>brings?
>> 
>> 
>>

---

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

> In a few more words - what does SUPA do that other WGs in the 
> IETF do not do? What does the IETF gain by chartering a SUPA WG?
> What will be lost by not chartering it?

I agree with Juergen's reply, and would like to add my own views (note that my background is more network management than system management). 

SUPA is creating a generic and extensible policy-based management
framework that is independent of language, protocol, repository,
and the level of abstraction of the content of the policy rule.

  - It is **generic**, in that it defines policy concepts
    independent of how those concepts are implemented.

  - It is **extensible**, in that it is built as a set of object-
    oriented information models that use a set of software patterns
    to represent common structures and behavior independent of
    what the policy rule is managing or how the policy rule is
    represented.

A generic policy management framework that is independent of
language, protocol, and repository does not exist in the IETF.
RFC3060 and RFC3460 are tightly bound to an **old** version of the
DMTF CIM. The CIM is not an information model (see RFC3198), since
it uses keys and weak relationships, both of which are relational
algebra concepts, and hence, a data model. Furthermore, the current
version of the CIM is very different than that defined in RFC3060
and RFC3460.

Currently, there are a **lot** of YANG data models. More are
undoubtedly coming. It is currently difficult to visualize how
a set of static data structures, such as those defined in YANG,
are translated to either monitoring or changing the configuration
of a network device. It is also currently difficult to express 
common concepts, such as different types of dependency
relationships, in YANG. Operators, administrators, and developers
(and probably end-users in some limited cases) would like better
abstractions to monitor and manage the configurations of their
network devices. Currently, policy management will fail, in that
there is no generic mechanism in place to be applied to this set
of diverse YANG models; this means that policy must be applied in
an individual, one-off manner, to each different YANG model that
exists. Similar problems exist for non-YANG environments (e.g., CLI
or TL1). If SUPA is successful, then the IETF will have an
extensible, technology-independent framework that can be used to define policy rules. To demonstrate the viability of this approach,
SUPA has proposed to work on a set of information and data models:

  - one generic information model that is independent of technology
    as well as the type of policy rule used
  - two information models, derived from the above, that represent
    event-condition-action (ECA) policy rules as well as 
    declarative, or intent-based, statements
  - two exemplary YANG data models, derived from the ECA and 
    declarative information models

The two types of policy management approaches (ECA and declarative)
are very different in syntax, semantics, and expressivity. This 
represents a good initial testing of the above policy framework.

By not chartering SUPA, then the IETF loses a promising mechanism for applying policy management techniques to manage network
elements and services. It also does not have an answer to how to
add policy to the (over 200) YANG models that currently exist.

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:03 AM
To: Romascanu, Dan (Dan)
Cc: [email-masked]
Subject: Re: [Supa] critical question #1 - distinct value of SUPA

/js

---

From: Masaki Fukushima <[email-masked]>
Date: Mon, 18 May 2015 18:50:54 +0900

>      independent of how those concepts are implemented.

I totally agree with John that the right level of generality is 
preferable because such a generic model allows us to share high-level 
understanding of concepts commonly observed in various services in our 
networks.

At the same time, if a model was overly generalized/abstracted, it could 
make the scope of the model somewhat ambiguous. For example, if a policy 
model is overly generalized, it could look like a policy for everything.

So, in order to convince those who are concerned that the scope of supa 
might be too broad, we need to clarify the scope/applicability of the model.

 From this viewpoint, I have a question.
What element in the generic model makes it a policy model for service 
(or something worth to be focused on in supa) and makes it distinct from 
a policy model for everything?

Thank you.
Masaki Fukushima

---

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

> a policy model for everything?

As long as we do not have a universally agreed definition of
'service', this question remains somewhat abstract.

/js

---

From: Tina TSOU <[email-masked]>
Date: Mon, 18 May 2015 15:53:14 +0000

Dear Juergen,

Can it refer to the service definition in WG L3sm?

Thank you,
Tina

> On May 18, 2015, at 7:05 PM, Juergen Schoenwaelder <[email-masked]> wrote:
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 18 May 2015 19:04:33 +0200

> Can it refer to the service definition in WG L3sm?

Such as?

/js

---

From: Tina TSOU <[email-masked]>
Date: Mon, 18 May 2015 17:44:17 +0000

Dear Juergen,

Since L3sm has service in the name, so I assume that the service definition is in the charter.
http://datatracker.ietf.org/wg/l3sm/charter/
Did not find it.

In https://tools.ietf.org/pdf/draft-l3vpn-service-yang-00.pdf
Did not find the direct definition.

However, there is something close.
3. Layer 3 IP VPN service model
A layer 3 LPVPN service is a collection of sites that are authorized to exchange traffic between each other over a shared IP infrastructure.

>From here, you can see service is the prior art.

Then have to look up wiki
http://en.m.wikipedia.org/wiki/Service

  *   The function provided by a server (computing)<http://en.m.wikipedia.org/wiki/Server_(computing)>
  *   Service (systems architecture)<http://en.m.wikipedia.org/wiki/Service_(systems_architecture)>, the provision of a discrete function within a systems environment:
     *   Service-oriented architecture<http://en.m.wikipedia.org/wiki/Service-oriented_architecture> (SOA), a design pattern in which application components provide services to other components via a communications protocol, typically over a network
     *   Service layer<http://en.m.wikipedia.org/wiki/Service_layer>, a conceptual layer within a network service provider architecture

Thank you,
Tina

On May 19, 2015, at 1:04 AM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

Such as?

/js

---

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

This is my point. What is the definition we use?

L3SM is about 'customer facing service models' - at least this is
how I read the charter text. And then there is a magic process to
translate the service model into device configurations.

In my little network, I have many non-customer facing policies in
order to control how I like to run the network. Little things like 'no
password logins', 'all unused ports are administratively disabled',
'all infrastructure boxes have basic static network config', ...

A generic policy framework should allow me to express all these little
things, regardless whether they are part of a 'customer facing service
model' or not.

That said, if most people think that restricting things to 'services'
of some vaguely defined kind, I will not object to it (and declare I
am providing a service to myself).

/js

---

From: "Natale, Bob" <[email-masked]>
Date: Mon, 18 May 2015 19:18:58 +0000

Since I was asked to comment on this topic, I would just like to note that the responses provided by John, Juergen, and Jun fully capture the value proposition as I see it.

The problem space is fairly obvious: Many existing (and future) data models that enable many specific management actions on many specific devices/resources/services with no standard means of automating a coherent management strategy that spans the myriad of cogent concerns (business value, security, performance, SLAs, etc.).

The questions was also asked "What's different today?" ... Well, nothing really needs to be different ... that we failed to solve a problem in the past is absolutely no excuse for not trying again (and again, if need be) ... but a lot is different ... more devices/resources/services ... more demand and consumption at a growing rate ... more regulation and competition ... more traffic and service innovation on the horizon ... etc. ... all at an ever faster rate. A new approach is required.

The only (minor) addition I would propose refers to John's note about two types of policy management approaches -- ECA ("procedural") and Intent ("declarative") -- and to his earlier work on the Policy Continuum (by whatever name today) ... I believe that the priority need is for the declarative approach ... we'll have to leave it to "many smart hands" to build out the procedural approach at many levels over time ... the declarative approach is probably much harder to standardize, ergo "risky", ergo we might fail again ... all the more reason why we should try now (the problem is not going to get any easier by waiting) ... we can mitigate the risk somewhat by drawing on the other "Intent-driven" standardization efforts underway in several of the NVF/SDN-related initiatives and return the favor by contributing to the critical mass of efforts in this respect.

Avanti,
BobN

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Tuesday, May 12, 2015 7:45 PM
To: Juergen Schoenwaelder; Romascanu, Dan (Dan); [email-masked]
Cc: [email-masked]
Subject: Re: [Supa] critical question #1 - distinct value of SUPA

> In a few more words - what does SUPA do that other WGs in the IETF do 
> not do? What does the IETF gain by chartering a SUPA WG?

SUPA is creating a generic and extensible policy-based management framework that is independent of language, protocol, repository, and the level of abstraction of the content of the policy rule.

A generic policy management framework that is independent of language, protocol, and repository does not exist in the IETF.
RFC3060 and RFC3460 are tightly bound to an **old** version of the DMTF CIM. The CIM is not an information model (see RFC3198), since it uses keys and weak relationships, both of which are relational algebra concepts, and hence, a data model. Furthermore, the current version of the CIM is very different than that defined in RFC3060 and RFC3460.

Currently, there are a **lot** of YANG data models. More are undoubtedly coming. It is currently difficult to visualize how a set of static data structures, such as those defined in YANG, are translated to either monitoring or changing the configuration of a network device. It is also currently difficult to express common concepts, such as different types of dependency relationships, in YANG. Operators, administrators, and developers (and probably end-users in some limited cases) would like better abstractions to monitor and manage the configurations of their network devices. Currently, policy management will fail, in that there is no generic mechanism in place to be applied to this set of diverse YANG models; this means that policy must be applied in an individual, one-off manner, to each different YANG model that exists. Similar problems exist for non-YANG environments (e.g., CLI or TL1). If SUPA is successful, then the IETF will have an extensible, technology-independent framework that can be used to define policy rules. To demonstrate the viability of this approach, SUPA has proposed to work on a set of information and data models:

The two types of policy management approaches (ECA and declarative) are very different in syntax, semantics, and expressivity. This represents a good initial testing of the above policy framework.

By not chartering SUPA, then the IETF loses a promising mechanism for applying policy management techniques to manage network elements and services. It also does not have an answer to how to add policy to the (over 200) YANG models that currently exist.

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:03 AM
To: Romascanu, Dan (Dan)
Cc: [email-masked]
Subject: Re: [Supa] critical question #1 - distinct value of SUPA

> In a few more words - what does SUPA do that other WGs in the IETF do not do? What does the IETF gain by chartering a SUPA WG? What will be lost by not chartering it?

My take is that SUPA focuses on a generic policy infrastructure. If SUPA is successful, we have a generic policy framework that can be used to express policies based on top of arbitrary configuration data models.

What will the IETF gain? If SUPA is successful, then the IETF will have to produce less policy data models in the future (I am saying less because there might still be special cases where hand-crafted policy work is needed). What will the IETF loose? A chance to reduce future work and to provide a consisten approach to automate policy driven configuration of network elements and/or network services (for me the boundary between configuring a network element and a network service is blurry.)

/js

---

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

如果您错误接收了该邮件，请通过电子邮件立即通知我们。[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.

Subject: Re: Re: [Supa] critical question #1 - distinct value of SUPA
From: Ying Cheng <[email-masked]>
To: "Natale, Bob" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 19 May 2015 07:43:10 +0800

+1

2015-05-19 

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

发件人： Natale, Bob 
发送时间： 2015-05-19  03:19:12 
收件人： [email-masked] 
抄送： 
主题： Re: [Supa] critical question #1 - distinct value of SUPA 
 
-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Tuesday, May 12, 2015 7:45 PM
To: Juergen Schoenwaelder; Romascanu, Dan (Dan); [email-masked]
Cc: [email-masked]
Subject: Re: [Supa] critical question #1 - distinct value of SUPA
Currently, there are a **lot** of YANG data models. More are undoubtedly coming. It is currently difficult to visualize how a set of static data structures, such as those defined in YANG, are translated to either monitoring or changing the configuration of a network device. It is also currently difficult to express common concepts, such as different types of dependency relationships, in YANG. Operators, administrators, and developers (and probably end-users in some limited cases) would like better abstractions to monitor and manage the configurations of their network devices. Currently, policy management will fail, in that there is no generic mechanism in place to be applied to this set of diverse YANG models; this means that policy must be applied in an individual, one-off manner, to each different YANG model that exists. Similar problems exist for non-YANG environments (e.g., CLI or TL1). If SUPA is successful, then the IETF will have an extensible, technology-independent framework
  that can be used to define policy rules. To demonstrate the viability of this approach, SUPA has proposed to work on a set of information and data models:
-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Tuesday, May 12, 2015 5:03 AM
To: Romascanu, Dan (Dan)
Cc: [email-masked]
Subject: Re: [Supa] critical question #1 - distinct value of SUPA
.

---

From: Ying Cheng <[email-masked]>
Date: Tue, 19 May 2015 09:31:58 +0800

Re-send with UTF-8

2015-05-19 

Ying CHENG  程莹

发件人： Ying Cheng 
发送时间： 2015-05-19  07:43:09 
收件人： Natale, Bob; [email-masked] 
抄送： 
主题： Re: Re: [Supa] critical question #1 - distinct value of SUPA 
 
+1

2015-05-19 

Ying CHENG  程莹

发件人： Natale, Bob