Subject: [Supa] SUPA Status and potential next steps

From: Benoit Claise <[email-masked]>
Date: Thu, 21 May 2015 19:47:37 +0200

Dear all,

This morning, I went through the following exercise:
1. I read the charter proposal at 
http://cnds.eecs.jacobs-university.de/users/schoenw/supa/supa-charter-2015-05-08.txt
     Actually, I had to read some paragraphs multiple times, and I was 
still not sure what they meant.
2. I analyzed the mailing list answers on the two important questions: 
"distinct value of SUPA" and "relation with other policy modelling 
efforts ongoing in the IETF".
3. I re-read the charter.

Well, the two email threads helped me better understand what SUPA wants 
to achieve (thanks for that).
And the second time I read the charter, it was a little bit clearer.

In terms of next steps, I believe you should:

- First, your proposed charter text should better document the scope of 
your intended work, based on those discussions.

For example, I flagged a couple of key messages that should be better 
explained:

    - generic policy framework that can be
    used to express policies based on top of arbitrary configuration data
    models.
    - 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.
    - Our focus is still on the interface north of the controller and
       south of the service manager. Data models below that will use
       parts of the GPIM as necessary, along with other existing work.
    - We aren't writing data models for BGP, ACLs, etc. We are simply
       reusing models from other WGs, but fitting them into our own
       framework.

Back to the current charter:

    Policy-based management can be used to combine these two mechanisms
    into an extensible framework. This framework will consist of a set of
    information models that enable both different forms of policy, as well
    as policy that uses different abstractions, to be used by different
    users to monitor and control managed entities throughout the service
    development and deployment lifecycle.

    This working group introduces the concepts of multi-level (multiple
    levels of abstraction) and multi-technology (e.g., IP, VPNs, MPLS)
    network abstractions to address the current separation between
    development and deployment operations. Multiple levels of abstraction
    enable common concepts present in different technologies and
    implementations to be represented in a common manner. This facilitates
    using diverse components and technologies to implement a network
    service.

I'm sure different people would understand these 2 paragraphs differently.

- Second, draft-karagiannis-supa-problem-statement should do a better 
job to explain the situation.
Starting with the abstract:

    In this context,
    providing network operators with a set of standard generic YANG-based
    service and policy models that enable management and automation
    of services on their network is essential.

"generic YANG-based service models", not really. At least not in the 
sense that L3SM is an experiment for a generic service YANG model for L3VPN.
The bulk of the draft-karagiannis-supa-problem-statement is about use 
cases. Use cases is not the issue here. Yes, we need _one_ use case to 
validate the information model and data model work, to show that they 
are applicable, but basically, we don't need to list so many. In the 
end, as mentioned on the list, pretty much everything we can configure 
is a policy.

- Third, you can't expect every person, IESG and IAB members included, 
to be up to date with all the SUPA drafts, and all the discussions. I 
believe that you want to update the problem statement draft (dated March 
9th!), and/or, even better, have a WIKI with Q/A, for people would want 
to understand SUPA in 15 minutes. Typically people who would attend the BoF.
It should include concepts (Q/A) such as:

    - What is SUPA?
    - Why you need SUPA? John's answer is a good start:

        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.

    - What is the SUPA scope/applicability?
         What's new (to me at least) recently is that you want a generic
    policy framework for which "templates"
         can applied to services, resources, devices etc..
         Btw: framework is an overloaded term in the IETF.
    - Policy types?
         ECA and declarative
         What is the connection with "intent"?
    - Why do you focus on information model while the IETF goes with
    data model these days?
         I understood: to make the link with business level rules from
    different SDOs (DTMF CIM was mentioned)
         Btw, is this statement correct?
    - What is the connection with RFC 3060 and RFC3460?
       As explained by John

        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.

    - Example of SUPA applicability?

        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.

    - What is the connection with existing policies inside the IETF?
         Juergen's answer is a good start:

        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.

        See also the point 4 below
    - What if we don't charter SUP
    - Etc.
    You can guess the type question you would have in a BoF (and I can
    help futher with those)
    For example:
         - You want to link business logic with policy, but the IETF
    doesn't go in the business layer

On those Q/A, take into account that we don't need 10 pages answers. You 
should go to point.

- Fourth, as mentioned on the call, it's important to show how SUPA work 
with existing policy initiatives inside the IETF.
 From the meeting minutes:

BC: It would be great if you could present how this I-D works for
     routing, etc., so that they could say "Aha! If we had only
     had this, then our work would have been simpler." This would
     give us more confidence in attacking more difficult problems,
     or problems that we don't yet know about, such as security
     policy. Make sense?

- Fifth, assuming that all the above are done, you should prepare for a 
BoF at the next IETF.
I guess that you would prefer a WG forming BoF, right? From there, we 
could evaluate the community reaction.

Regards, Benoit

---

From: Georgios Karagiannis <[email-masked]>
Date: Fri, 22 May 2015 04:45:09 +0000

Hi Benoit,

Thank you very much for your comments.
Regarding the problem statement draft, please note that the last time that it was updated was before the IETF in Dallas.
We will use your comments and the ongoing discussions and update the problem statement draft accordingly.

Best regards,
Georgios

From: Supa [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: 21 May 2015 19:48
To: [email-masked]
Subject: [Supa] SUPA Status and potential next steps

Dear all,

This morning, I went through the following exercise:
1. I read the charter proposal at http://cnds.eecs.jacobs-university.de/users/schoenw/supa/supa-charter-2015-05-08.txt
    Actually, I had to read some paragraphs multiple times, and I was still not sure what they meant.
2. I analyzed the mailing list answers on the two important questions: "distinct value of SUPA" and "relation with other policy modelling efforts ongoing in the IETF".
3. I re-read the charter.

Well, the two email threads helped me better understand what SUPA wants to achieve (thanks for that).
And the second time I read the charter, it was a little bit clearer.

- First, your proposed charter text should better document the scope of your intended work, based on those discussions.

For example, I flagged a couple of key messages that should be better explained:

models.

  framework.

service.

- Second, draft-karagiannis-supa-problem-statement should do a better job to explain the situation.
Starting with the abstract:

   In this context,

"generic YANG-based service models", not really. At least not in the sense that L3SM is an experiment for a generic service YANG model for L3VPN.
The bulk of the draft-karagiannis-supa-problem-statement is about use cases. Use cases is not the issue here. Yes, we need one use case to validate the information model and data model work, to show that they are applicable, but basically, we don't need to list so many. In the end, as mentioned on the list, pretty much everything we can configure is a policy.

- Third, you can't expect every person, IESG and IAB members included, to be up to date with all the SUPA drafts, and all the discussions. I believe that you want to update the problem statement draft (dated March 9th!), and/or, even better, have a WIKI with Q/A, for people would want to understand SUPA in 15 minutes. Typically people who would attend the BoF.
It should include concepts (Q/A) such as:
- What is SUPA?
- Why you need SUPA? John's answer is a good start:

extensible, technology-independent framework that can be used to define policy rules.
- What is the SUPA scope/applicability?
    What's new (to me at least) recently is that you want a generic policy framework for which "templates"
    can applied to services, resources, devices etc..
    Btw: framework is an overloaded term in the IETF.
- Policy types?
    ECA and declarative
    What is the connection with "intent"?
- Why do you focus on information model while the IETF goes with data model these days?
    I understood: to make the link with business level rules from different SDOs (DTMF CIM was mentioned)
    Btw, is this statement correct?
- What is the connection with RFC 3060 and RFC3460?
  As explained by John

and RFC3460.

model.

   See also the point 4 below
- What if we don't charter SUP
- Etc.
You can guess the type question you would have in a BoF (and I can help futher with those)
For example:
    - You want to link business logic with policy, but the IETF doesn't go in the business layer
On those Q/A, take into account that we don't need 10 pages answers. You should go to point.

- Fourth, as mentioned on the call, it's important to show how SUPA work with existing policy initiatives inside the IETF.
From the meeting minutes:

    policy. Make sense?

- Fifth, assuming that all the above are done, you should prepare for a BoF at the next IETF.
I guess that you would prefer a WG forming BoF, right? From there, we could evaluate the community reaction.
Regards, Benoit

---

From: John Strassner <[email-masked]>
Date: Fri, 22 May 2015 20:28:29 -0700

Thank you Benoit for providing detailed feedback.

Attached is a revised charter to address your points. Some minor
clarifications follow:

1. Key messages. Your four key messages are addressed as follows:

 - generic policy framework -> paragraphs 1, 2, 3
 - a generic and extensible policy-based management -> paragraph 2
 - Our focus is still on the interface north -> paragraph 4
 - We aren't writing data models for BGP, ACLs, etc -> paragraph 3

2. Two paragraphs cited that people will read differently are both revised.

3. draft-karagiannis-supa-problem-statement was NOT addressed

4. Building a FAQ:

  - What is SUPA?
    <jcs> could add more to the charter from draft-strassner-.... but I
     personally think the charter is too long now </jcs>

  - Why you need SUPA? John's answer is a good start (elided)

  - What is the SUPA scope/applicability?  What's new (to me at least)
     recently is that you want a generic policy framework for which
     "templates" can applied to services, resources, devices etc..
     Btw: framework is an overloaded term in the IETF.
     <jcs> This is due to the need to have policies for monitoring and
     controlling both resources and services. I excised the term
     "framework" from the charter </jcs>

   - Policy types? ECA and declarative What is the connection with "intent"?
     <jcs> Declarative is a more descriptive term (imho) for intent </jcs>

   - Why do you focus on information model while the IETF goes with data
      model these days?  I understood: to make the link with business level
      rules from different SDOs (DTMF CIM was mentioned) Btw, is this
      statement correct?
     <jcs> The root problem is that there are too many data models that
     are defined as "data silos". They define the same or similar concepts
     differently, and it is difficult to use them together. An information
model
     defines a common vocabulary and set of concepts that enables
     different data models to interoperate. </jcs>

   - What is the connection with RFC 3060 and RFC3460? (elided)

   - Example of SUPA applicability? (elided)

   - What is the connection with existing policies inside the IETF? (elided)

   - What if we don't charter SUPA

<elided>

   - Fourth, as mentioned on the call, it's important to show how SUPA
     work with existing policy initiatives inside the IETF.
     <jcs> Still working on this </jcs>

   - Fifth, assuming that all the above are done, you should prepare for
     a BoF at the next IETF. I guess that you would prefer a WG forming
     BoF, right? From there, we could evaluate the community reaction.
     <jcs> I would vote for a WG-forming BoF </jcs>

On Thu, May 21, 2015 at 10:47 AM, Benoit Claise <[email-masked]> wrote:

> "distinct value of SUPA" and "relation with other policy modelling efforts
> ongoing in the IETF".
> "generic YANG-based service models", not really. At least not in the sense
> that L3SM is an experiment for a generic service YANG model for L3VPN.
> cases. Use cases is not the issue here. Yes, we need *one* use case to
> validate the information model and data model work, to show that they are
> applicable, but basically, we don't need to list so many. In the end, as
> mentioned on the list, pretty much everything we can configure is a policy.
>
> - Third, you can't expect every person, IESG and IAB members included, to
> be up to date with all the SUPA drafts, and all the discussions. I believe
> that you want to update the problem statement draft (dated March 9th!),
> and/or, even better, have a WIKI with Q/A, for people would want to
> understand SUPA in 15 minutes. Typically people who would attend the BoF.
> _______________________________________________
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa
>
>

-- 
regards,
John