Subject: Re: [Supa] Supa Digest, Vol 3, Issue 8

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 08 Oct 2014 05:47:04 -0400

I think there could still be what the IETF calls a bar-BOF: we find a room and meet to discuss the real BOF. In a way not to have a BOF is good since you only can have 2 of those before you need the WG to be approved. It gains the group time to put a better plan/charter together.

And yes the 1st answer to get is: who needs this and why before we go into details of the implmentation.

/mjm
On Oct 8, 2014, at 4:54 AM, [email-masked] wrote:

> Send Supa mailing list submissions to
> 	[email-masked]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.ietf.org/mailman/listinfo/supa
> or, via email, send a message with subject or body 'help' to
> 	[email-masked]
> 
> You can reach the person managing the list at
> 	[email-masked]
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Supa digest..."
> Today's Topics:
> 
>   1. Re: SUPA BoF not approved (Tina TSOU)
>   2. Re: SUPA BoF not approved (Liushucheng (Will))
> 
> From: Tina TSOU <[email-masked]>
> Subject: Re: [Supa] SUPA BoF not approved
> Date: October 8, 2014 at 4:42:48 AM EDT
> To: Parviz Yegani <[email-masked]>, Benoit Claise <[email-masked]>, Georgios Karagiannis <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> 
> 
> 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,
>  
> 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,
> 
> Who do we need in this call?
> I'm afraid that a call with 20 persons will not be efficient.
> 
> Regards, Benoit
> 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,
> 
> 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: "Liushucheng (Will)" <[email-masked]>
> Subject: Re: [Supa] SUPA BoF not approved
> Date: October 8, 2014 at 4:54:00 AM EDT
> To: Benoit Claise <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> 
> 
> 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,
> 
> 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.
> [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.
> 
> 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.
> [Will] IMHO, this extension requirement was introduced by the draft draft-voit-netmod-peer-mount-requirements.
> 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.
> [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?
> ’
> 
> 
> _______________________________________________
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa

---

From: Kostas Pentikousis <[email-masked]>
Date: Wed, 8 Oct 2014 12:03:31 +0200

Indeed, an excellent idea. A Bar-BOF would be a great to nail down f2f the critical aspects. The downside, of course, is that remote participation is not really possible.

Perhaps we could have a separate tele-bar-BOF prior to the physical bar-BOF, say the week before the meeting?

Best regards,

Kostas

Von: Marie-Jose Montpetit [mailto:[email-masked]]
Gesendet: Mittwoch, 8. Oktober 2014 11:47
An: [email-masked]
Betreff: Re: [Supa] Supa Digest, Vol 3, Issue 8

/mjm

---

From: Parviz Yegani <[email-masked]>
Date: Wed, 8 Oct 2014 10:44:56 -0700

Yes, arranging for a bar-BoF is a good idea. We have done it in the past
and it would really help if planned in advance.

Thanks,
Parviz

On Wed, Oct 8, 2014 at 2:47 AM, Marie-Jose Montpetit <[email-masked]>
wrote:

> I think there could still be what the IETF calls a bar-BOF: we find a room
> and meet to discuss the real BOF. In a way not to have a BOF is good since
> you only can have 2 of those before you need the WG to be approved. It
> gains the group time to put a better plan/charter together.
>
> *From: *Tina TSOU <[email-masked]>
> *Subject: **Re: [Supa] SUPA BoF not approved*
> *Date: *October 8, 2014 at 4:42:48 AM EDT
> *To: *Parviz Yegani <[email-masked]>, Benoit Claise <
> [email-masked]>, Georgios Karagiannis <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
>
>
> 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?
>
> *From:* Supa [mailto:[email-masked] <[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,
>
> 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)
> *From:* Benoit Claise [mailto:[email-masked] <[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,
>
> 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] <[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,
>
> After a lengthy discussion during the BoF coordination call, the IESG and
> IAB have decided not to approve the SUPA BoF.
> 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 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.
> 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 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).
> 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:
> 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: *"Liushucheng (Will)" <[email-masked]>
> *Subject: **Re: [Supa] SUPA BoF not approved*
> *Date: *October 8, 2014 at 4:54:00 AM EDT
> *To: *Benoit Claise <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
>
>
> 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] <[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,
>
> After a lengthy discussion during the BoF coordination call, the IESG and
> IAB have decided not to approve the SUPA BoF.
> 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 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.
> *[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.
>
> 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 have no idea why you would need
> NETCONF/RESTCONF protocol extensions here.
> *[Will] IMHO, this extension requirement was introduced by the draft
> draft-voit-netmod-peer-mount-requirements.*
>
> 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).
> *[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?*
> *’*
>
>

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