#onap-meeting: July V-F2F-2017-07-25

Meeting started by kennypaul at 11:59:53 UTC (full logs).

Meeting summary

    1. Stephen Terrill, Ericsson (SteveT, 12:00:41)

  2. Volte Control loop (SteveT, 12:08:28)
    1. Alla Goldner, Amdocs (alla, 12:09:04)
    2. Yuan Liu presented the Volte use case control loop automation (SteveT, 12:10:20)
    3. A number of GAPs were identified in terms of templates, rules, etc (SteveT, 12:13:41)
    4. and API (policy - VFC-C, VFC-> Multivim) (SteveT, 12:14:25)
    5. 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. (SteveT, 12:17:13)
    6. question was recieved about "how does the VNF send the messages to dcae". The answer was via VES. (SteveT, 12:17:41)
    7. 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. (SteveT, 12:19:07)
    8. 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 (SteveT, 12:19:45)
    9. . it was suggested that Ron Shacham could also provide feedback on these slides. (SteveT, 12:22:23)
    10. Question about why onboarding holmes, it was answered that that is part of the platform deployment (SteveT, 12:24:05)
    11. a JSON file for holmes has been distributed today (SteveT, 12:28:50)
    12. the question was raised as to why doesn't DMaap used instead of REST-API for policy. Response was more the baseline. (SteveT, 12:32:07)
    13. some parts can be created in design time, also important to consider the design time (SteveT, 12:41:06)
    14. the request for the template for holmes was to enable the holmes project to know what else they may need to do (SteveT, 12:42:47)
    15. open actions are also discussed in the project weekly meetings (SteveT, 12:50:57)
    16. suggested to 1. collect feedback from PTLs 2. follow-up call next week. (SteveT, 12:52:23)
    17. There is a suggestion to make sure that there is a simple use case done in R1 (SteveT, 12:53:31)
    18. rshacham presented the closed loop view. Starting from the CLAMP cockpit, describing the interaction with SDC, DCAE and policy. (SteveT, 12:56:12)
    19. Blockers page created- Teams please utilize this to track issues still preventing progress- (kennypaul, 13:07:47)
    20. https://wiki.onap.org/display/DW/July+Virtual+Developers+Event+Blockers (kennypaul, 13:07:52)
    21. The closed loop automation gaps that are noted will be replicated to the blockers page (SteveT, 13:12:02)

  3. vCPE Use Case Review - Integration and Use case subcommittee (SteveT, 13:13:17)
    1. Kang Xi walked through the vCPE Use Case Review presentation (SteveT, 13:14:47)
    2. vDHCP, vAAA and vDNS+vDHCP are all opensource VNFs and will use the G VNFM approach (SteveT, 13:16:09)
    3. the presentation covered architecture, signalling flows, closed loop design and execution (SteveT, 13:25:55)
    4. 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. (SteveT, 13:28:09)
    5. there was a quesetion of threshoulding, and the response was that for VoLTE UC, holmes is used, in vCPE its TCA (threshold crossing). (SteveT, 13:32:11)
    6. TCA == Threshold Crossing Alert (phrobb, 13:32:31)
    7. 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 (SteveT, 13:35:16)
    8. 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 (SteveT, 13:38:23)
    9. all PTLs involved are OK, except for SDC. That meeting is planned. (SteveT, 13:40:31)
    10. still to looking into how to do tosca -> heat (SteveT, 13:45:11)
    11. that was the how to do the tosca->head in SO (SteveT, 13:45:55)
    12. 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 (SteveT, 13:46:58)
    13. There was a question about why to convert tosca to heat. The answer (for runtime) was due to interfaceing the cloud via multi-vim (SteveT, 13:48:18)
    14. As more information, the multi-vim project only supports HEAT in release 1 (SteveT, 13:48:55)
    15. 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. (SteveT, 13:55:23)
    16. 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 (SteveT, 13:56:02)

  4. VoLTE Service Design and Instantiation (SteveT, 14:11:01)
    1. VoLTE service design and creation was presented by Yang Xu (SteveT, 14:11:31)
    2. some elements picture in the use case are not under control of onap (e.g. eNB) but others are (SteveT, 14:13:49)
    3. there was a quesetion about which project supports the federated SDN, the response was the SDN-C (SteveT, 14:22:46)
    4. Licencing for commercial vnfs will be taken in local labs, re-using the licencing agreed between the operator and the vendors. (SteveT, 14:38:56)
    5. 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. (SteveT, 14:39:19)
    6. 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 (SteveT, 14:52:18)
    7. Include also in the SDC question session, as well as put onto the blocking issues list (SteveT, 14:53:08)
    8. Can use the VID to choose which data center to depoloye each VNF (SteveT, 14:55:01)
    9. 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. (SteveT, 14:55:45)
    10. 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. (SteveT, 14:56:44)
    11. 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. (SteveT, 14:59:00)
    12. 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. (SteveT, 14:59:45)

  5. Architecture (SteveT, 15:04:21)
    1. Chris Donnley presented the Architecture slides (SteveT, 15:04:36)
    2. The colors on R2+ slide have not significance (SteveT, 15:12:35)
    3. Release 1 picture covers also the projects as well as the architecture (SteveT, 15:13:57)
    4. it is apprecicated to also have the project view (SteveT, 15:15:40)
    5. There was a question about where OPNFV would sit. it was clarified that it "below" ..... (SteveT, 15:19:27)
    6. there was a question whether this represents the concesous in the architecture committee, and teh answer was yes (SteveT, 15:21:59)
    7. 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. (SteveT, 15:25:04)
    8. 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 (SteveT, 15:26:42)
    9. 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. (SteveT, 15:28:32)
    10. question - ARchitecture does not include reference VNFs. The response was to take it offline to see how to consider (SteveT, 15:30:05)
    11. there was a quesetion about the mapping to ETSI, has that being dropped. The answer was no, its not. (SteveT, 15:30:29)
    12. 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). (SteveT, 15:31:51)
    13. it was commented that the optimization framework was not included. The response was that this is a functional architecture, not representing all the projects. (SteveT, 15:32:25)
    14. there was a question about allowing APP-C and VF-C overlap for now. The answer was yes, for R1 that is the case. (SteveT, 15:33:52)
    15. the same question and answer applied for CCSDK (SteveT, 15:34:14)
    16. The interface block means that we are working out the interfaces between these functions (SteveT, 15:37:41)
    17. There was a question about what would be approach for naming the interfaces. This is yet to be discussed (SteveT, 15:38:38)
    18. 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 (SteveT, 15:41:26)
    19. 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 (SteveT, 15:42:19)
    20. 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 (SteveT, 15:43:25)
    21. There was a question on high availabiilty. The answer was that this is not discussed in the functional view (so far). (SteveT, 15:43:52)
    22. 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 (SteveT, 15:45:17)

  6. meeting logistics (SteveT, 15:54:55)
    1. about 126 participants and 18 panalists. (SteveT, 15:55:15)


Meeting ended at 15:57:59 UTC (full logs).

Action items

  1. (none)


People present (lines said)

  1. SteveT (77)
  2. kennypaul (5)
  3. collabot (5)
  4. phrobb (2)
  5. alla (1)


Generated by MeetBot 0.1.4.