Subject: [Supa] Proper figure that should be in the value proposition I-D

From: Tina TSOU <[email-masked]>
Date: Fri, 19 Jun 2015 08:05:58 +0000

Dear all,

This is to initiate the discussion at the list, about proper figure that should be in the value proposition I-D.

Please make comment or propose updated figure.

Thank you,
Tina

---

From: Tina TSOU <[email-masked]>
Date: Sat, 20 Jun 2015 14:54:46 +0000

Dear all,

To facilitate the discussion, I use Juergen's figure and description on SUPA components:

+-------------+
| supa info   |
| model       |
+-------------+
       $
       $
       v
+-------------+
| supa policy |
| data model  |
+-------------+
       $
...... $ ........................................................
       $
       v       +---------------+
  policies --> | supa function | ---> configuration snippets
               +---------------+   (based on device YANG models)

- supa info model (written once, standards track)
- supa data model (written once, standards track)
- policies (written by operators according to the data model)
- supa function translating policies into configuration snippets
- configuration snippets (that conform to YANG data models and can be
 pushed to devices using NETCONF / RESTCONF

The upper half is happening at design time, the bottom part is
happening at runtime.

Thank you,
Tina

On Jun 19, 2015, at 4:17 PM, Tina TSOU <[email-masked]<mailto:[email-masked]>> wrote:

Dear all,

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

---

From: John Strassner <[email-masked]>
Date: Sat, 20 Jun 2015 15:17:08 -0700

I assume that you are comparing Juergen's figure to Figure 1 in the
proposition draft.

First, I propose that we change "supa info model" to "Generic Policy
Information Model", which is in the charter and the proposition draft.

Second, I don't know what "supa policy data model" is. The charter
does not define this term. The proposition draft says that "A set of
Generic Policy Data Models are then created from the GPIM. These
YANG data model policies...". The important differences are:

   1) these aren't any type of data models, they are YANG data models
   2) there isn't ONE data model, there are a SET of data models

Third, I don't understand the symbology. What is wrong with the
symbology proposed in the proposition draft?

Ignoring for the moment the question of the Service Management Data
Model, Juergen's figure now looks like this:

   +-------------------+
   |   Generic Policy  |
   | Information Model |
   +-------------------+
            D
            D
           \ /
   +-----------------+
   | Generic Policy  |
   |   Data Model    |
   +-----------------+
            D
 .......... D ...................................................
            D
           \ /      +---------------+
        policies -->| supa function | --> configuration snippets
                    +---------------+  (based on YANG data models)

Now comes the fun part :-)

<jcs> Agreed </jcs>

 - supa data model (written once, standards track)
<jcs> Disagree. I think that the overall structure is written once.
However, there are many different applications; some can use the
same data model, while some need specific data models. What is
common to this, from the SUPA point-of-view, is the generic
structure of a policy (whether it is ECA or declarative). What
cannot be fully captured are the different components of policy.
For example, in an ECA policy rule, how many different types of
conditions are there? RFC3460 defined 23 variable classes and 8
value classes, which can be combined to define the condition or
action clauses of a CA policy rule (RFC3460 did not define an ECA
policy rule).

The point is that the above 31 classes clearly do not define all
possible variables and values that could be used to form a
condition or an action. Hence, the data model is more correctly
viewed as a template for defining the overall structure of a
policy, and applications will extend that. The fundamental reason
for using an information model in the first place is to enable
the extensions to be defined in a standard way.

- policies (written by operators according to the data model)
<jcs> Disagree. The most general tool for the operator would be to
write policies according to the GPIM, not the data model. There is
no reason to exclude operators using the GPIM, the ECA data model,
and/or the declarative data model. </jcs>

<jcs> I agree that this is a preferred first objective. I disagree
that it is the **only** objective.

I personally have been building model-driven systems for well over a
decade. A model-driven system is one in which the developer can
build new objects out of existing objects (e.g., modify the system
at runtime without having to reload databases, recompile, redeploy,
etc.). The SUPA GPIM is constructed to allow this. Note that I did
**not** say **mandate**. I simply want to leave this possibility
open, at least for the time being. Indeed, this is the path that
the TMF ZOOM project is taking (both courses, not one or the other).

To Max's original point, and why the Service Management Data Model
is in Figure 1 of the Proposition Draft:

   - one of the principal objectives when we started SUPA was to
     define policies to manage network services. Note that the
     charter still says "The GPIM can represent different types of
     policy rules for controlling managed entities throughout the
     service development and deployment lifecycle."
   - The charter says: "SUPA will be designed to work together
     with network service models." I don't see a "service model"
     in Juergen's picture.
   - The charter says: "In particular, the creation of a network
     service instance should be able to trigger the execution of
     SUPA policies, ..." How can this be done if there is no
     service model? :-)

I could go on, but I hopefully have made my point. I would suggest
that we add the "supa function" to the Proposition Draft in Figure 1.
I do **not** think that we should replace Figure 1 with Juergen's
picture, at least until someone explains to me what I am missing
and answers the above objections.

regards,
John

On Sat, Jun 20, 2015 at 7:54 AM, Tina TSOU <[email-masked]>
wrote:

> On Jun 19, 2015, at 4:17 PM, Tina TSOU <[email-masked]>
> wrote:
>
>  Dear all,
>
> [email-masked]
> [email-masked]

-- 
regards,
John

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 29 Jun 2015 15:34:34 +0200

> Information Model", which is in the charter and the proposition draft.

yep
 
> symbology proposed in the proposition draft?

It is full of 'noise' that is not needed. Why is there a 'Service
Management' box? What is the 'Service Management Data Model'? What
exactly are the 'Network Manager / Controller'? More important, where
is the policy interpreter function that SUPA is about (given the
charter text)? I was trying to produce a _functional_ drawing.
 
> Model, Juergen's figure now looks like this:

Accoring to the above text, this should be:

s/Data Model/YANG Data Models/

>  .......... D ...................................................

We have one generic data model for network interfaces and still we can
support N different types of interfaces. YANG deals with this via
annotations that can extend a core model.
 
> and answers the above objections.

See, Figure 1 is not a _functional_ figure, it is a specific use case
figure or an applicability figure. Singe it appears in the framework
document and section, I think it should be a functional figure.

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