Subject: [Supa] SUPA BoF not approved

From: Benoit Claise <[email-masked]>
Date: Fri, 03 Oct 2014 18:03:34 +0200

Dear all,

After a lengthy discussion during the BoF coordination call, the IESG 
and IAB have decided not to approve the SUPA BoF.
The work was not considered mature enough to allocate BoF time.

However, it doesn't not mean that you should stop working on SUPA.
Below are 5 starting points, which you should consider as positive remarks.
I'm committed to help on those points, potentially with a webex call.

1. I believe that you should do a better job explaining your problem 
statement and what you actually want to standardize, what the desired 
outcomes are.
The charter mentions (took some excerpts):

    The SUPA (Shared Unified Policy Automation) working group will work
    on the definition of such a standardized interface for applications
    and network services to communicate with network controllers of all
    types.

    In particular, SUPA will focus on service specific models that allow
    applications to request certain network services to be
    created/deleted/modified.

    The terms "UNIFIED" and "SHARED" used in the SUPA abbreviation,
    relate to the way the service policy model is generated, since it
    groups, unifies and shares the similar requirements imposed by a
    bulk of applications.
                         Benoit: I still have no idea what you mean here.

    SUPA will provide guidelines for mechanisms that can dynamically and
    in an interoperable manner, AUTOMATICALLY map services and policies
    defined on an abstract topology graph down to more detailed network
    graphs and specific network management and controlling policies.

    SUPA will work on defining vendor-neutral standardized interfaces
    based on the concept of network graph, an entity describing an
    arbitrary topology of nodes and links at any level of granularity.
                         Benoit: I still have no idea what you mean here.

    SUPA will ensure that in case any specific NETCONF/RESTCONF protocol
    requirements are identified
                         Benoit: I have no idea why you would need
    NETCONF/RESTCONF protocol extensions here.

It seems that you have all the buzzwords, and that's actually a 
drawback, because you are all over the map (including the use cases).
I've been trying to divide the problem and guide the discussion with my 
message to the list. For example,

             ---------------------
             |    applications   |
             ---------------------

                     | <--- service YANG models /NETCONF interface

             ---------------------

             |     controller    | <--- mapping services to topology

             ---------------------

              |      |      | <--- device/feature specific YANG models / 
NETCONF interface

             NE1    NE2   NEn

... but I'm not sure I've been successful.

2. Interaction with the different WGs must be explained/understood.
Coming back to the deliverables, I understand that you want a topology. 
How is this different than the topology being worked on in I2RS? (I see 
now that this was addressed on the mailing list recentl)

 From one of Georgios's email, I see this deliverable:

    2) The definition and standardization of a number of basic policy and data models using network graphs. These might include, but are not limited to L3VPNs, traffic engineering, implementation of IPv6 transition mechanism and their enforcement to users.

First of, these are very broad deliverables, but also, what is the 
connection with the BESS proposed WG at 
https://datatracker.ietf.org/wg/bess/charter/ . It mentions:

    - Data models for modeling, managing, and operating BGP-based services
    using SMI or YANG.

3. Are the deliverables not too much of a research type?
 From one of Georgios's email, can you actually standardize such a 
deliverable?

    3) Provide guidelines for mechanisms that can dynamically and automatically map services and policies defined on an abstract topology graph down to more detailed network graphs and specific network management and controlling policies.

4. You should get other people in your community to support this effort.

5. Open question: is there a willingness in the industry to standardize 
services models, knowing that all operators will have slightly different 
services?
In one of Tina's email, I see: "The IESG suggested network management 
services, especially distributed data center services, before Toronto.". 
I'm not too sure what you are referring to.

Regards, Benoit (OPS AD)

---

From: Tina TSOU <[email-masked]>
Date: Sat, 4 Oct 2014 00:21:45 +0000

Dear Benoit,

Thank you for your clear advice.

For point 5, it referred to Spencer's email to the list before Toronto meeting, about the IESG discussion on the APONF, suggestion it focus on network management applications e.g OSS, Distribution Data Center application.

When is the WebEx meeting?

Thank you,
Tina

On Oct 4, 2014, at 12:03 AM, "Benoit Claise" <[email-masked]<mailto:[email-masked]>> wrote:

Dear all,

After a lengthy discussion during the BoF coordination call, the IESG and IAB have decided not to approve the SUPA BoF.
The work was not considered mature enough to allocate BoF time.

1. I believe that you should do a better job explaining your problem statement and what you actually want to standardize, what the desired outcomes are.
The charter mentions (took some excerpts):
The SUPA (Shared Unified Policy Automation) working group will work on the definition of such a standardized interface for applications and network services to communicate with network controllers of all types.

In particular, SUPA will focus on service specific models that allow applications to request certain network services to be created/deleted/modified.

The terms "UNIFIED" and "SHARED" used in the SUPA abbreviation, relate to the way the service policy model is generated, since it groups, unifies and shares the similar requirements imposed by a bulk of applications.
                    Benoit: I still have no idea what you mean here.
SUPA will provide guidelines for mechanisms that can dynamically and in an interoperable manner, AUTOMATICALLY map services and policies defined on an abstract topology graph down to more detailed network graphs and specific network management and controlling policies.

SUPA will work on defining vendor-neutral standardized interfaces based on the concept of network graph, an entity describing an arbitrary topology of nodes and links at any level of granularity.
                    Benoit: I still have no idea what you mean here.

SUPA will ensure that in case any specific NETCONF/RESTCONF protocol requirements are identified
                    Benoit: I have no idea why you would need NETCONF/RESTCONF protocol extensions here.
It seems that you have all the buzzwords, and that's actually a drawback, because you are all over the map (including the use cases).
I've been trying to divide the problem and guide the discussion with my message to the list. For example,

            ---------------------
            |    applications   |
            ---------------------

            ---------------------

            ---------------------

             |      |      | <--- device/feature specific YANG models / NETCONF interface

            NE1    NE2   NEn

2. Interaction with the different WGs must be explained/understood.
Coming back to the deliverables, I understand that you want a topology. How is this different than the topology being worked on in I2RS? (I see now that this was addressed on the mailing list recentl)

First of, these are very broad deliverables, but also, what is the connection with the BESS proposed WG at https://datatracker.ietf.org/wg/bess/charter/ . It mentions:
- Data models for modeling, managing, and operating BGP-based services
using SMI or YANG.

>From one of Georgios's email, can you actually standardize such a deliverable?

5. Open question: is there a willingness in the industry to standardize services models, knowing that all operators will have slightly different services?
In one of Tina's email, I see: "The IESG suggested network management services, especially distributed data center services, before Toronto.". I'm not too sure what you are referring to.

Regards, Benoit (OPS AD)

---

From: Parviz Yegani <[email-masked]>
Date: Fri, 3 Oct 2014 23:48:06 -0700

Hi, Benoit,

Thanks for your detailed comments. Yes, it's a good idea to discuss the
issues you raised on the phone (a teleconf meeting). I've had problems with
WebEx lately and will be happy to provide the bridge facility for this call.

Please let me know when is a good time for you and others who want to join.

Thanks,
Parviz

On Fri, Oct 3, 2014 at 5:21 PM, Tina TSOU <[email-masked]>
wrote:

>  For point 5, it referred to Spencer's email to the list before Toronto
> meeting, about the IESG discussion on the APONF, suggestion it focus on
> network management applications e.g OSS, Distribution Data Center
> application.
>
> On Oct 4, 2014, at 12:03 AM, "Benoit Claise" <[email-masked]> wrote:
>
>  Dear all,
>
> After a lengthy discussion during the BoF coordination call, the IESG and
> IAB have decided not to approve the SUPA BoF.
> The SUPA (Shared Unified Policy Automation) working group will work on the
> definition of such a standardized interface for applications and network
> services to communicate with network controllers of all types.
>
> The terms "UNIFIED" and "SHARED" used in the SUPA abbreviation, relate to
> the way the service policy model is generated, since it groups, unifies and
> shares the similar requirements imposed by a bulk of applications.
> SUPA will provide guidelines for mechanisms that can dynamically and in
> an interoperable manner, AUTOMATICALLY map services and policies defined
> on an abstract topology graph down to more detailed network graphs and
> specific network management and controlling policies.
>
> SUPA will work on defining vendor-neutral standardized interfaces based
> on the concept of network graph, an entity describing an arbitrary topology
> of nodes and links at any level of granularity.
> It seems that you have all the buzzwords, and that's actually a drawback,
> because you are all over the map (including the use cases).
> How is this different than the topology being worked on in I2RS? (I see now
> that this was addressed on the mailing list recentl)
>
> _______________________________________________
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa
>
>

-- 
Dr. Parviz Yegani
(408) 759-1973 mobile
[email-masked]

---

From: Georgios Karagiannis <[email-masked]>
Date: Sun, 5 Oct 2014 08:15:52 +0000

Dear Benoit,

Thanks for the provided information.
Thank you also very much for willing to help us on working out the 5 listed remarks, by e.g., using webex calls.

Parviz, thank you very much for willing to provide the bridge facility for this call.

Best regards,
Georgios

From: Supa [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Friday, October 03, 2014 6:04 PM
To: [email-masked]
Subject: [Supa] SUPA BoF not approved

Dear all,

            ---------------------

            |    applications   |

            ---------------------

            ---------------------

            ---------------------

            NE1    NE2   NEn

Regards, Benoit (OPS AD)

---

From: Benoit Claise <[email-masked]>
Date: Mon, 06 Oct 2014 11:34:46 +0200

Gergios, Tina, Parviz,

Who do we need in this call?
I'm afraid that a call with 20 persons will not be efficient.

Regards, Benoit
> Thank you also very much for willing to help us on working out the 5 
> listed remarks, by e.g., using webex calls.
>
> *From:*Supa [mailto:[email-masked]] *On Behalf Of *Benoit Claise
> *Sent:* Friday, October 03, 2014 6:04 PM
> *To:* [email-masked]
> *Subject:* [Supa] SUPA BoF not approved
>
> Dear all,
>
> The SUPA (Shared Unified Policy Automation) working group will work on 
> the definition of such a standardized interface for applications and 
> network services to communicate with network controllers of all types.
>
> The terms "UNIFIED" and "SHARED" used in the SUPA abbreviation, relate 
> to the way the service policy model is generated, since it groups, 
> unifies and shares the similar requirements imposed by a bulk of 
> applications.
>     SUPA will provide guidelines for mechanisms that can dynamically
>     and in an interoperable manner, AUTOMATICALLY map services and
>     policies defined on an abstract topology graph down to more
>     detailed network graphs and specific network management and
>     controlling policies.
>
> Coming back to the deliverables, I understand that you want a 
> topology. How is this different than the topology being worked on in 
> I2RS? (I see now that this was addressed on the mailing list recentl)
>
> 5. Open question: is there a willingness in the industry to 
> standardize services models, knowing that all operators will have 
> slightly different services?
> services, especially distributed data center services, before 
> Toronto.". I'm not too sure what you are referring to.
>
> Regards, Benoit (OPS AD)
>

---

From: Parviz Yegani <[email-masked]>
Date: Mon, 6 Oct 2014 15:21:02 +0000

Hi Benoit,

Agreed, with a crowd of 20 people on the call we can't accomplish much. I'd suggest we invite only the folks who are
driving the discussion on the mailing list.  The agenda should focus on addressing the questions you raised (highlighted in red)
below. This is to help remove any confusion and try to converge on what we are trying to accomplish in SUPA.

Please send me names and a date/time for this call. I'll send an invite asap.

Thanks,
Parviz

From: Benoit Claise [mailto:[email-masked]]
Sent: Monday, October 06, 2014 2:35 AM
To: Georgios Karagiannis
Cc: [email-masked]; Parviz Yegani
Subject: Re: [Supa] SUPA BoF not approved

Gergios, Tina, Parviz,

Regards, Benoit
Dear Benoit,

Best regards,
Georgios

From: Supa [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Friday, October 03, 2014 6:04 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Supa] SUPA BoF not approved

Dear all,

            ---------------------

            |    applications   |

            ---------------------

            ---------------------

            ---------------------

            NE1    NE2   NEn

Regards, Benoit (OPS AD)

---

From: Tina TSOU <[email-masked]>
Date: Wed, 8 Oct 2014 08:42:48 +0000

Dear Benoit,

> 5. Open question: is there a willingness in the industry to standardize services models, knowing that all operators will have slightly different services?

SUPA wanted to work on service specific abstractions and non-trivial mappings.

Thank you,
Tina

From: Supa [mailto:[email-masked]] On Behalf Of Parviz Yegani
Sent: Monday, October 06, 2014 11:21 PM
To: Benoit Claise; Georgios Karagiannis
Cc: [email-masked]
Subject: Re: [Supa] SUPA BoF not approved

Hi Benoit,

Thanks,
Parviz

From: Benoit Claise [mailto:[email-masked]]
Sent: Monday, October 06, 2014 2:35 AM
To: Georgios Karagiannis
Cc: [email-masked]<mailto:[email-masked]>; Parviz Yegani
Subject: Re: [Supa] SUPA BoF not approved

Gergios, Tina, Parviz,

Regards, Benoit
Dear Benoit,

Best regards,
Georgios

Dear all,

            ---------------------

            |    applications   |

            ---------------------

            ---------------------

            ---------------------

            NE1    NE2   NEn

Regards, Benoit (OPS AD)

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Wed, 8 Oct 2014 08:54:00 +0000

Dear Benoit,

Thank you very much for your guiding. Your figure and comments really helped us a lot in refining this work.  I have some quick questions to your first comment, to make sure that we understood you correctly. Please see below inline start with [Will]

Regards,
Will

From: Supa [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Saturday, October 04, 2014 12:04 AM
To: [email-masked]
Subject: [Supa] SUPA BoF not approved

Dear all,

The terms "UNIFIED" and "SHARED" used in the SUPA abbreviation, relate to the way the service policy model is generated, since it groups, unifies and shares the similar requirements imposed by a bulk of applications.
                    Benoit: I still have no idea what you mean here.
[Will] We will try to modify the wording here. One quick question, is the unclear of the above three sentence due to the misuse or misunderstanding of the three key words: service/network service, application and policy?
SUPA will provide guidelines for mechanisms that can dynamically and in an interoperable manner, AUTOMATICALLY map services and policies defined on an abstract topology graph down to more detailed network graphs and specific network management and controlling policies.

[Will] IMHO, this extension requirement was introduced by the draft draft-voit-netmod-peer-mount-requirements.

            ---------------------

            |    applications   |

            ---------------------

            ---------------------

            ---------------------

            NE1    NE2   NEn

[Will] Regarding your previous email about this figure, 'Device/Feature YANG models  /NETCONF? Yes, for sure, and we should do this full speed', do you think we could put this into the scope of SUPA, if part of this 'Device/Feature YANG models' is not done by NETMOD?
'