Subject: [Supa] Agree on the approach

From: Tina TSOU <[email-masked]>
Date: Tue, 7 Jul 2015 13:35:16 +0000

Dear all,

There was an intensive discussions among some of the data model design team members, would the operators write the policy, then SUPA does the process; or the operators use the SUPA information/data models directly.

I visited a tier-1 Internet company today, their preferred approach is the former.

There are other topics discussed on the data model. I would encourage people to move the discussion to the mailing list, for broader audience.

Thank you,
Tina

---

From: Maoke <[email-masked]>
Date: Wed, 8 Jul 2015 17:35:11 +0900

hi Tina and all,

we anyway made the draft of the data model on time though there are a lot
of important issues to discuss.

as Tina suggested, the draft (
https://tools.ietf.org/html/draft-chen-supa-eca-data-model-00 ) could be
seen as a starting point for further discussion of a possible solution on
policy implementation.

to my humble understanding, we have approached the rough consensus as
follows:
1. a data model or policy module is needed to be designed so that policy
parameters are deployable
2. the format of the policy model can take the advantages of XPath,
NETCONF, and of YANG, being made as canonical  representation of policies.
3. the policy module should be reusable and transferable (definition is
needed through for the reusability and transferability).

we have at least the following open issues:
1. is the data model derived from information model or from the operators
with hand-coded configurations?
2. the former approach is more focused on a structure and the latter one is
something like script. for SUPA policy data model, what is the proper
expression format for it? (possibly something in-between)
3. the policy interface to the other components in the architecture.
etc.

* Tina, the discussion might contain a plenty of contents. so you have an
idea of organising it efficiently?

- maoke

2015-07-07 22:35 GMT+09:00 Tina TSOU <[email-masked]>:

> Dear all,
>
> There was an intensive discussions among some of the data model design
> team members, would the operators write the policy, then SUPA does the
> process; or the operators use the SUPA information/data models directly.
>
> There are other topics discussed on the data model. I would encourage
> people to move the discussion to the mailing list, for broader audience.
>
>
> Thank you,
> Tina
> _______________________________________________
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 8 Jul 2015 23:51:21 +0200

> with hand-coded configurations?

I do not understand the question. The data model should be derived
form the information model. And for me it is clear that operators
write the policy according within the infrastructure we provide.

> expression format for it? (possibly something in-between)

Yes, this is something the WG needs to work out. What I find valuable
is a framework that allows to write policies that can operate on
arbitrary YANG configuration data models. I want to be able to apply
policies how my network interfaces are configured without having to
write an interface policy data model first.

> 3. the policy interface to the other components in the architecture.

Not sure I understand the question.

-- 
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: Jon Saperia <[email-masked]>
Date: Wed, 8 Jul 2015 19:20:10 -0400

A couple of ideas to move the discussion along.
1. There are some good terms in the information model draft, but addition of some specific examples might help since we may not all mean the same things.  For example, the generic model in the picture that was added. A generic model lists technologies (e.g., routing, load balancing, security, etc.).  It could be express/illustrated a number of ways. I will provide some examples.  Similarly a specific data model is a concrete representation - lots of YANG examples of this. 
2. Some process examples would be helpful.  Once we agree on what is in the different components, showing a couple of flows of how all this fits together would be useful.  Even if we don’t agree, there is something concrete to work with.

Finally, I understand I was not at the previous discussions but there still seems some difference of opinion on the charter.  I will take a crack at making some suggestions.

/jon
> On Jul 8, 2015, at 5:51 PM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Thanks
/jon
------------------------------------
Jon Saperia
(mobil) 617-201-2655
[email-masked]

---

From: John Strassner <[email-masked]>
Date: Wed, 8 Jul 2015 23:51:21 +0000

Hi Maoke,

please see inline.

regards,
John

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]<mailto:[email-masked]>

From: Supa [mailto:[email-masked]] On Behalf Of Maoke
Sent: Wednesday, July 08, 2015 1:35 AM
To: Tina TSOU
Cc: [email-masked]
Subject: Re: [Supa] Agree on the approach

hi Tina and all,

we anyway made the draft of the data model on time though there are a lot of important issues to discuss.

as Tina suggested, the draft ( https://tools.ietf.org/html/draft-chen-supa-eca-data-model-00 ) could be seen as a starting point for further discussion of a possible solution on policy implementation.

to my humble understanding, we have approached the rough consensus as follows:
1. a data model or policy module is needed to be designed so that policy parameters are deployable
<jcs> What is a "policy parameter"? If this is an attribute of a policy, that won't do any good. The point of policy is that it is a reusable object that encapsulates a specified change in behavior (for ECA; for declarative policies, it expresses a goal to be achieved).

What does "deployable" mean? Policy has both design-time and run-time aspects. Just because it is deployed doesn't mean it did what you wanted it to do. :-) </jcs>

2. the format of the policy model can take the advantages of XPath, NETCONF, and of YANG, being made as canonical  representation of policies.
<jcs> These are three different things, and only YANG has a little to do with "format". The policy information model is independent of all of these; the policy data model is targeting YANG. </jcs>

3. the policy module should be reusable and transferable (definition is needed through for the reusability and transferability).
<jcs> What is the "policy module"? This phrase appears exactly twice in your draft, once in the ToC, and once as part of a title for Section 3. If you mean "model ietf-supa-policy" on page 12, please call it a YANG policy module. </jcs>

we have at least the following open issues:
1. is the data model derived from information model or from the operators with hand-coded configurations?
<jcs> It is derived (in your case) from the combination of the GPIM and the EPRIM. What you are asking (I think) is **how it is used**, which is why I changed Figure 1 of draft-klyus-supa-proposition-02, in order to provide two different examples of this. </jcs>

2. the former approach is more focused on a structure and the latter one is something like script. for SUPA policy data model, what is the proper expression format for it? (possibly something in-between)
<jcs> I assume you mean "data structure" for the former (otherwise, I don't understand your question). Please note that an information model is far more than "just" a specification of data structures. For example, it defines semantics.

The second part of your question goes back to the change in Figure 1 of draft-klyus-supa-proposition-02. As shown in that figure, there are in fact multiple ways that an operator could use SUPA. I personally think we SHOULD NOT mandate any one approach. However, if you look at Figure 1, then it shows three different interaction methods (writing data models, filling out a (for example) Web form, and running a script. </jcs>

The value of SUPA is that it is a framework that enables different approaches to be used to construct and use policy. I personally think that limiting this devalues SUPA. </jcs>

3. the policy interface to the other components in the architecture.
etc.
<jcs> I don't understand your question. Are you talking about an API or how policy is communicated? And what are the "other components" in your architecture? </jcs>

* Tina, the discussion might contain a plenty of contents. so you have an idea of organising it efficiently?

- maoke

2015-07-07 22:35 GMT+09:00 Tina TSOU <[email-masked]<mailto:[email-masked]>>:
Dear all,

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