Subject: Re: [Supa] Supa Digest, Vol 6, Issue 64

From: Marie-Jose Montpetit <[email-masked]>
Date: Thu, 29 Jan 2015 09:46:59 -0500

While I did not attend the WebEx meeting, I have reviewed the

https://datatracker.ietf.org/doc/draft-karagiannis-supa-problem-statement/ <https://datatracker.ietf.org/doc/draft-karagiannis-supa-problem-statement/>

I also consulted the minutes of the call and some of comments align with mine.

- I think the draft should be cut in 2:
- an informational track draft to clearly state the problem;
- a std track draft to talk about the solution
Right now both are there which is unusual.

- The use cases are operators and universities (the Scott Bradner use case) anything else? How about entities like Google or Netflix or Amazon which have their own either public and/or private networks and could be strong “recruits” when seeking support in the IETF. Also it is not clear from the use cases what is the problem addressed (the YANG models are not clearly linked to the use cases). The use cases should also be linked to the proposed work items.

Nit: the introduction mentions operators but the use case also has the university network problem - generalize the intro?

Marie-José

> On Jan 29, 2015, at 9:30 AM, [email-masked] wrote:
> 
> Send Supa mailing list submissions to
> 	[email-masked] <mailto:[email-masked]>
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.ietf.org/mailman/listinfo/supa <https://www.ietf.org/mailman/listinfo/supa>
> or, via email, send a message with subject or body 'help' to
> 	[email-masked] <mailto:[email-masked]>
> 
> You can reach the person managing the list at
> 	[email-masked] <mailto:[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: Review of draft-zhou-supa-framework-00 (Huangjing (A))
>   2. supa charter revision 2015-01-29 (Juergen Schoenwaelder)
>   3. Fwd: [Rtg-yang-coord] I-D Action:
>      draft-shaikh-rtgwg-policy-model-00.txt (JF Tremblay)
> 
> From: "Huangjing (A)" <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> To: Tina TSOU <[email-masked] <mailto:[email-masked]>>
> Date: January 29, 2015 at 3:52:31 AM EST
> Subject: Re: [Supa] Review of draft-zhou-supa-framework-00
> 
> 
> Hi, Tina,
>  
> IMHO, MA should do the work; one OAMA should talk to only one MA, and that MA should collaborate with other MAs if necessary.
> This will simplify the development work of MA.
>  
> BTW, recently I had some discussion with my colleagues, and I hear some different opinions on MAs:
> 1.       Will there be only one MA in a domain? If that is true, and in the charter it says we will focus on a single administrative domain for the time being – then can we say currently we only care about the scenario of one MA, and multiple MAs will not be considered?
> 2.       There will be multiple MAs in a domain, but each MA will have a single function, for example, one MA for monitoring, one MA for deployment.
> But, IMHO, there will be multiple MAs, and each MA will have all the necessary functions.
>  
> What do you think?
>  
> Best Regards
> James
>  
> From: Supa [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Tina TSOU
> Sent: Tuesday, January 27, 2015 4:44 PM
> To: [email-masked] <mailto:[email-masked]>
> Subject: [Supa] Review of draft-zhou-supa-framework-00
>  
> Dear authors et al,
>  
> I have read http://www.ietf.org/id/draft-zhou-supa-framework-00.txt <http://www.ietf.org/id/draft-zhou-supa-framework-00.txt>.
>  
> Some questions come up to my mind as following.
>  
> In Figure 1, assume one service, e.g. VPN, requires the collaboration of multiple MAs, and NEs under multiple MAs are involved, then who is going to align the work of these MAs?
>  
> Will Operation And Management Application (OAMA) figure out data models and send them to each MA respectively?
>  
> Or OAMA will work out just one set of data models, and send them to one MA; that MA will further figure out how to collaborate with other MAs?
>  
> If you intend to give the flexibility to OAMA, that’s also fine. At least some wording might be needed in the document.
>   
>  
> Thank you,
> Tina
>  
> 
> 
> 
> From: Juergen Schoenwaelder <[email-masked] <mailto:[email-masked]>>
> To: [email-masked] <mailto:[email-masked]>
> Date: January 29, 2015 at 9:27:31 AM EST
> Reply-To: Juergen Schoenwaelder <[email-masked] <mailto:[email-masked]>>
> Subject: [Supa] supa charter revision 2015-01-29
> 
> 
> Hi,
> 
> I took an action item to revise the charter text based on input
> received on the list and discussions we had on Monday. I have
> incorporated all the wording improvements submitted by Bob. To address
> James' concerns, I have replaced information model with the phrase
> 'generic policy model'. Perhaps we can leave it open to the WG whether
> an explicit information model is required or whether YANG models are
> sufficient. The key, I think, it to define an generic policy
> structure.
> 
> I have gone through JF Tremblay's comments and I incorporated many of
> his suggestions, but sometimes not literally. While working on the
> text (and shaking my head about how the parts fit together), I came to
> the conclusion that we may be talking about a layered topology model
> including available resources, a service model including service
> specific parameters and resource requirements, and a set of policy
> rules that actually drive the mapping of a service model to the
> network topology. I do not know whether this is the view of the people
> here on the list - so please speak up if not. But with this view in
> mind, it became much easier to edit the charter text (since the policy
> part now has a much more clearly defined function).
> 
> So, shoot your arrows at the 2015-01-29 edition of the charter text.
> 
> /js
> 
> -- 
> 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/ <http://www.jacobs-university.de/>>
> <charter-2015-01-29.txt>
> 
> 
> From: JF Tremblay <[email-masked] <mailto:[email-masked]>>
> To: [email-masked] <mailto:[email-masked]>
> Date: January 29, 2015 at 9:30:37 AM EST
> Subject: [Supa] Fwd: [Rtg-yang-coord] I-D Action: draft-shaikh-rtgwg-policy-model-00.txt
> 
> 
> FYI, considering the interest for policy models in supa. 
> 
> This one is limited to routing and more specifically to BGP policing, but it could be seen as a simpler alternative to  draft-wang-netmod-yang-policy-dm-00.
> 
> JF
> 
>> Begin forwarded message:
>> 
>> From: "Alvaro Retana (aretana)" <[email-masked] <mailto:[email-masked]>>
>> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> Date: January 24, 2015 at 7:57:12 AM EST
>> Subject: [Rtg-yang-coord] FW: I-D Action: draft-shaikh-rtgwg-policy-model-00.txt
>> 
>> FYI..
>> 
>> On 1/24/15, 2:11 AM, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> wrote:
>> 
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> 
>>> 
>>>       Title           : Routing Policy Configuration Model for Service
>>> Provider Networks
>>>       Authors         : Anees Shaikh
>>>                         Rob Shakir
>>>                         Kevin D'Souza
>>>                         Chris Chase
>>> 	Filename        : draft-shaikh-rtgwg-policy-model-00.txt
>>> 	Pages           : 27
>>> 	Date            : 2015-01-23
>>> 
>>> Abstract:
>>>  This document defines a YANG data model for configuring and managing
>>>  routing policies in a vendor-neutral way and based on actual
>>>  operational practice.  The model provides a generic policy framework
>>>  which can be augmented with protocol-specific policy configuration.
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-shaikh-rtgwg-policy-model/ <https://datatracker.ietf.org/doc/draft-shaikh-rtgwg-policy-model/>
>>> 
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-shaikh-rtgwg-policy-model-00 <http://tools.ietf.org/html/draft-shaikh-rtgwg-policy-model-00>
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>>> 
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/i-d-announce <https://www.ietf.org/mailman/listinfo/i-d-announce>
>>> Internet-Draft directories: http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html>
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>> 
>> _______________________________________________
>> Rtg-yang-coord mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord <https://www.ietf.org/mailman/listinfo/rtg-yang-coord>
>> 
> 
> 
> 
> _______________________________________________
> Supa mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/supa <https://www.ietf.org/mailman/listinfo/supa>

---

From: JF Tremblay <[email-masked]>
Date: Thu, 29 Jan 2015 10:20:38 -0500

> On Jan 29, 2015, at 9:46 AM, Marie-Jose Montpetit <[email-masked]> wrote:
> 

Let me second this again. (I mentioned it on the call this week). 

We shouldn’t introduce solution and framework elements in the problem statement. 

> - The use cases are operators and universities (the Scott Bradner use case) anything else? How about entities like Google or Netflix or Amazon which have their own either public and/or private netw…

Good points. 

One that come to mind is Google’s B4 inter-datacenter work (http://cseweb.ucsd.edu/~vahdat/papers/b4-sigcomm13.pdf <http://cseweb.ucsd.edu/~vahdat/papers/b4-sigcomm13.pdf>). Their goal was to optimize inter-datacenter link usage. While the paper discusses a lot of the datacenter deployment itself, it could be interesting for supa to concentrate on standardizing inter-datacenter interactions and how applications can use these functions (sections 3.3, 3.4 and 4. of the paper). 

> Nit: the introduction mentions operators but the use case also has the university network problem - generalize the intro?

Noted. Should improve this in the next version. 

Thanks for the review.

JF