11:59:53 <kennypaul> #startmeeting July V-F2F-2017-07-25 11:59:53 <collabot> Meeting started Tue Jul 25 11:59:53 2017 UTC. The chair is kennypaul. Information about MeetBot at http://wiki.debian.org/MeetBot. 11:59:53 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic. 11:59:53 <collabot> The meeting name has been set to 'july_v_f2f_2017_07_25' 12:00:41 <SteveT> #info Stephen Terrill, Ericsson 12:03:45 <phrobb> kennypaul: please #chair myself and Stephen 12:08:11 <kennypaul> #chair SteveT 12:08:11 <collabot> Current chairs: SteveT kennypaul 12:08:23 <kennypaul> #chair phrobb 12:08:23 <collabot> Current chairs: SteveT kennypaul phrobb 12:08:28 <SteveT> #topic Volte Control loop 12:09:04 <alla> #info Alla Goldner, Amdocs 12:10:20 <SteveT> #info Yuan Liu presented the Volte use case control loop automation 12:13:41 <SteveT> #info A number of GAPs were identified in terms of templates, rules, etc 12:14:25 <SteveT> #info and API (policy - VFC-C, VFC-> Multivim) 12:17:13 <SteveT> #info Question was raised, eleborate on the scenario of the guest not sending a keep alive. The answer was the VIM is supposed to be sending an alert if it is not recieving a heartbeat. 12:17:41 <SteveT> #info question was recieved about "how does the VNF send the messages to dcae". The answer was via VES. 12:19:07 <SteveT> #info question was raised about whether the goal was to do the instantiation and closed loop. The answer was to do the closed loop for 1-2 VNFs. 12:19:45 <SteveT> #info it was noted that closed loop for all 10 VNFs may be aggresive from the time frame for R1. Great to do it, but also consider the open-loop as a first step 12:22:23 <SteveT> #info. it was suggested that Ron Shacham could also provide feedback on these slides. 12:24:05 <SteveT> #info Question about why onboarding holmes, it was answered that that is part of the platform deployment 12:28:50 <SteveT> #info a JSON file for holmes has been distributed today 12:32:07 <SteveT> #info the question was raised as to why doesn't DMaap used instead of REST-API for policy. Response was more the baseline. 12:41:06 <SteveT> #info some parts can be created in design time, also important to consider the design time 12:42:47 <SteveT> #info the request for the template for holmes was to enable the holmes project to know what else they may need to do 12:50:57 <SteveT> #info open actions are also discussed in the project weekly meetings 12:52:23 <SteveT> #info suggested to 1. collect feedback from PTLs 2. follow-up call next week. 12:53:31 <SteveT> #info There is a suggestion to make sure that there is a simple use case done in R1 12:56:12 <SteveT> #info rshacham presented the closed loop view. Starting from the CLAMP cockpit, describing the interaction with SDC, DCAE and policy. 13:07:47 <kennypaul> #info Blockers page created- Teams please utilize this to track issues still preventing progress- 13:07:52 <kennypaul> #link https://wiki.onap.org/display/DW/July+Virtual+Developers+Event+Blockers 13:12:02 <SteveT> #info The closed loop automation gaps that are noted will be replicated to the blockers page 13:13:17 <SteveT> #topic vCPE Use Case Review - Integration and Use case subcommittee 13:14:47 <SteveT> #info Kang Xi walked through the vCPE Use Case Review presentation 13:16:09 <SteveT> #info vDHCP, vAAA and vDNS+vDHCP are all opensource VNFs and will use the G VNFM approach 13:25:55 <SteveT> #info the presentation covered architecture, signalling flows, closed loop design and execution 13:28:09 <SteveT> #info There was a question about do we have all the required DCAE applications (microsevers)? It was responded that there may need some modeification but this is considered doable. 13:32:11 <SteveT> #info there was a quesetion of threshoulding, and the response was that for VoLTE UC, holmes is used, in vCPE its TCA (threshold crossing). 13:32:31 <phrobb> #info TCA == Threshold Crossing Alert 13:35:16 <SteveT> #info There was a question on the role of the vBNG. vBNG is the virtual broadand network gateway. The response was that it authenticates, agregates and passes the packets throught 13:38:23 <SteveT> #info there was a question a question about when the vLAN id between the vGMUX and vG1 is assigned. The answer was that at customer order time, and done by the SDN-C 13:40:31 <SteveT> #info all PTLs involved are OK, except for SDC. That meeting is planned. 13:45:11 <SteveT> #info still to looking into how to do tosca -> heat 13:45:55 <SteveT> #info that was the how to do the tosca->head in SO 13:46:58 <SteveT> #info there was a question about the creation of a link between the vG MUX and vG, and that needs to be taken as a follow-up 13:48:18 <SteveT> #info There was a question about why to convert tosca to heat. The answer (for runtime) was due to interfaceing the cloud via multi-vim 13:48:55 <SteveT> #info As more information, the multi-vim project only supports HEAT in release 1 13:55:23 <SteveT> #info there was a question about whether TOSCA is a more general representation, and that TOSCA is the direction also for alignment with multi-vim. it was a response that it is a more general approach. This has not been addressed by the architecture committee yet. 13:56:02 <SteveT> #info there was a question regarding whether the tosca orchestrator in SO is for service or per VNF or both. The response was that SO is trying to remain general, but could do both 13:58:35 <SteveT> Resume at 10 pas the hour 14:11:01 <SteveT> #topic VoLTE Service Design and Instantiation 14:11:31 <SteveT> #info VoLTE service design and creation was presented by Yang Xu 14:13:49 <SteveT> #info some elements picture in the use case are not under control of onap (e.g. eNB) but others are 14:22:46 <SteveT> #info there was a quesetion about which project supports the federated SDN, the response was the SDN-C 14:38:56 <SteveT> #info Licencing for commercial vnfs will be taken in local labs, re-using the licencing agreed between the operator and the vendors. 14:39:19 <SteveT> #info In a discussion about the equipment and devices. It was indicated if the HW is supposed to be in place by M2. The possibility of a plan B and Plan Cwas discussed, however the date to trigger that was not stated. 14:52:18 <SteveT> #info Yang asked whether SDC can inport the TOSCA VNF tempate. The response was that SDC onboards heat based templates only now. there is open-o seed code (model designer) supporting this, however it yet to be seen how these will be merged in time for R1. This was raised as a red flag. There was a discussion about the reality of the VNFs vendors providing TOSCA templates. It was confirmed that the vendors 14:52:18 <SteveT> were providing tosca templates. It was commented that it would be good to have options (fallbacks) as well. 14:53:08 <SteveT> #info Include also in the SDC question session, as well as put onto the blocking issues list 14:55:01 <SteveT> #info Can use the VID to choose which data center to depoloye each VNF 14:55:45 <SteveT> #info there was a question whether SDCN can work with WAN overlay/underlay connection with PNF resources. The response was that that functionality is supported, but detailed discussions is also required. 14:56:44 <SteveT> #info there was a question about letting the VID pick the PNFs and input parameters. Can these be put in at instaintiation time with the VID GUI. The response was yes, as long as they are in the model. 14:59:00 <SteveT> #info There was a question about whether SDC can put the two NS templates and DCI network templates together and create one E2E service template. The response was at the high level yes, however details need to be discussed. 14:59:45 <SteveT> #info There was a question on whether SO can parse the E2E service template (even a nested one). The response was that if its within the limits of the SO parsing, then this can be done. 15:04:21 <SteveT> #topic Architecture 15:04:36 <SteveT> #info Chris Donnley presented the Architecture slides 15:12:35 <SteveT> #info The colors on R2+ slide have not significance 15:13:57 <SteveT> #info Release 1 picture covers also the projects as well as the architecture 15:15:40 <SteveT> #info it is apprecicated to also have the project view 15:19:27 <SteveT> #info There was a question about where OPNFV would sit. it was clarified that it "below" ..... 15:21:59 <SteveT> #info there was a question whether this represents the concesous in the architecture committee, and teh answer was yes 15:25:04 <SteveT> #info there was a question about what the NFV-O NFV collector is, this is to collect the information from NFs. This is a legacy artifact and still open to discussion. 15:26:42 <SteveT> #info there was a question when the presentation would be turned in a real specification. The response was that we are not creating a specification, however yes descriptions of the modules and interfaces is to be done 15:28:32 <SteveT> #info there was a question about what are the differences between R1 and R2+. The response was a difference in R1 is more a two layer approach (SO - APP-C/VF-C) In R2+ a 3 layer approach is described. 15:30:05 <SteveT> #info question - ARchitecture does not include reference VNFs. The response was to take it offline to see how to consider 15:30:29 <SteveT> #info there was a quesetion about the mapping to ETSI, has that being dropped. The answer was no, its not. 15:31:51 <SteveT> #info There was a comment that it looks like policy and DCAE bi-passes the multivim, is that the intention. The response was not the intention is that they do not (actually policy doesn't go to the VIM layer anyway). 15:32:25 <SteveT> #info it was commented that the optimization framework was not included. The response was that this is a functional architecture, not representing all the projects. 15:33:52 <SteveT> #info there was a question about allowing APP-C and VF-C overlap for now. The answer was yes, for R1 that is the case. 15:34:14 <SteveT> #info the same question and answer applied for CCSDK 15:37:41 <SteveT> #info The interface block means that we are working out the interfaces between these functions 15:38:38 <SteveT> #info There was a question about what would be approach for naming the interfaces. This is yet to be discussed 15:41:26 <SteveT> #info There was a qusetion about the RO definition using ETSI, and removing ETSI maybe causing confusion. The response is that this is useful for definition, however it needs to be refined towards a better common definition 15:42:19 <SteveT> #info there was a question about whether this is a view produced outside the architecture committee. The answer was that this was developed in the architecture committee 15:43:25 <SteveT> #info there was a requestion to clarifiy the role of APP-C and gvnm. The answer is that if you use the ETSI terminology, they are different VNFMs. They are different implementation depends on supporting different operator needs 15:43:52 <SteveT> #info There was a question on high availabiilty. The answer was that this is not discussed in the functional view (so far). 15:45:17 <SteveT> #info There was a question about how can we avoid different API definitions for simular interface. The answer was that short term this may happen, in the long term the idea is to identify the interfaces, and the idea is to have a architectuer review between M2 and M3 15:54:55 <SteveT> #topic meeting logistics 15:55:15 <SteveT> #info about 126 participants and 18 panalists. 15:57:59 <SteveT> #endmeeting