Re: [Supa] SUPA questions

[JF Tremblay <[e-mail]>]

Benoit, 
Let me try to answer some of your questions below. These are definitely not “finalized” answers and might not reflect the consensus of the whole group. 

This is an effort to move the discussion forward on the points you raised. Comments inline. 

JF


> On Feb 2, 2015, at 9:53 AM, Benoit Claise <[e-mail]> wrote:
> 
> I spent 2 hours preparing for this call today (reading some of the emails, some of the drafts, and the latest charter proposal). Here are some of my questions, posted to hopefully help structure the call, or follow up after the call.
> Apologies if some of the questions have been answered on the mailing or during one of the weekly calls.
> 
> Regards, Benoit

Thanks for taking the time to comment. 

> =============================
> 
> http://tools.ietf.org/html/draft-karagiannis-supa-problem-statement-04 <http://tools.ietf.org/html/draft-karagiannis-supa-problem-statement-04>
> 
> Same question as during the bar BoF: what is the connection with I2RS in terms of topology?
> When I spoke to Alia Atlas some months ago, she mentioned that the topology would be done in I2RS.

Right. Alia said I2RS was willing to continue this work, but: 
- This wasn’t discussed in Hawaii (it wasn’t on the agenda and draft-clemm-i2rs-yang-network-topo-01 was expired at that time)
- There’s been very little discussions on this topic on the I2RS list for the past year. 

The good news is that topology work is on the agenda for the I2RS interim next Thursday (see http://trac.tools.ietf.org/wg/i2rs/trac/wiki/TopologyDesignTeams <http://trac.tools.ietf.org/wg/i2rs/trac/wiki/TopologyDesignTeams>). Supa participants are willing to re-use the work of other groups such as I2RS, as long as a timely completion envisioned. 


> Btw, is this really a BUS? I thought it was RESCONF/NETCONF? Slide 4 shows RESTCONF/NETCONF

My personal opinion would be to remove the BUS terminology from these drafts. A bus in computer engineers terms usually refers to some level of parallelization or serialization (at least according to Wikipedia). I don’t see how these concepts apply here. 


> I don't quite get the change from "applications" to "AOMA "(what is this?), and "controller" to "management agent" from previous draft versions? 

This was discussed on the list and during interim calls. Juergen suggested getting back to more classic terms such as management application and controller. I agree.  Juergen also mentioned “management agent” could be confused with a component of SNMP. 

> I would be great if you could agree on a single set of terminology

Agreed. 


> - From your slide, do you target option 1 or option 2 for the charter?

As Tina mentioned, these more or less show the same thing with different levels of details, they shouldn’t be called options. This will be updated in the slides. 


> - I still don't understand what "Shared Unified Policy Automation" means
>     Shared between?
>     Unified between?
> Disclaimer: I recall proposing not to change the mailing list/draft names one more time ... but you would still need to explain what you mean.

As discussed yesterday, the list and the name are mostly placeholders at this point because the group wanted to avoid yet another renaming. 


> <ifgceied.png>
> Wrt the south-band interface, does SUPA limit its use cases to what I2RS can do? Btw, I2RS selected YANG.
> I was thinking to have NETCONF there.

Supa would not be limited to I2RS behaviors on the southbound, for sure. 


> It seems that you want to address the interface between an application and a controller?

Yes. 

> Does this top down approach work without also standardizing the device/protocol specific interface/YANG models? 

Good point. It’s entirely true that supa is all about a top-down approach. 

> Or maybe you want to base the use cases on what the vendor CLIs can do today? Then how do we solve the multi-vendor/proprietary issues?

I believe this is what the wording around “mapping” was about. Connecting the top-down approach to proprietary implementations is definitely not is scope here. It has to connect to common, inter-operable concepts. 


> Having a L3VPN services model is not complex IMO, but translating to the PE configurations is what make challenging, specifically when from different vendors. It seems that SUPA completely hides this complexity.
> IMO, this is however exactly where a SDO such as the IETF would add a lot of values.
> Look at the different discussions on standardizing the routing-related YANG models.

I’ve taken a look at draft-zhuang-l3vpn-yang-cfg, for example. My understanding was that supa would provide a protocol-agnostic layer above that and use a model like l3vpn-yang to configure in the southbound direction (I use “direction” here because it would probably talk to a controller and not to devices directly). 

The advantage of such an abstraction is to hide the implementation details, including the fact it’s an L3VPN, form the higher-level apps. In my mind, a supa interface consumer would only get a high-level abstract topology information and then provision network resources over that topology. I’m not sure this view is shared amongst all group participants, some discussions on this would be welcome. 


> Questions on the charter (next to the ones I asked above)
> - It seems that you discuss multiple use cases in different drafts but I don't see any in the charter as deliverable?
> How would you know if you are successful?
> On the other hand, I see in the charter text:
> The first use case that the working group will focus on will be VPN
> inter-datacenter traffic management, including the automated
> provisioning of site-to-site virtual private networks (VPNs) of
> various types (for example IPsec, tunnels, MPLS L2 and L3).
> "VPN, IPSEC, tunneles, MPLS L2 or L3", they look to me as multiple use cases, at least multiple distinct technolgies, and therefore as a huge piece of work

Agreed, this has to be clarified and boiled down to a single well defined action item. 

> -  "A set of policy rules is then defined to manage the service"
> I don't know what you mean by "policy rules"? A new language? A set of YANG models, depending on the use case (Policy-based routing, QoS rate-limiting policy, ACL drop policy, etc...), something else?      

The policy side is also unclear to me. But again, this would be a high-level top-down approach. I like what’s described in draft-hares-i2rs-info-model-policy-02 (and the related presentation at http://tools.ietf.org/agenda/90/slides/slides-90-i2rs-2.pdf <http://tools.ietf.org/agenda/90/slides/slides-90-i2rs-2.pdf>), but again, that’s an I2RS document. 

JF