Re: [Supa] SUPA questions

[Benoit Claise <[e-mail]>]

Thanks JF.

For the rest of the SUPA people, don't hesitate to jump in this discussion.

Regards, Benoit
> 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] 
>> <mailto:[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_
>>
>> 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). 
> 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 cha__rter (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), but 
> again, that’s an I2RS document.
>
> JF
>
>
>
>
>