Hui Deng I would like to remind you that the VFC and APPC are provisionally accepted pending the architecture alignment. The final acceptance should be discussed in the TSC. This kind of answer will not resolve the problem of overlapping between the 2 streams and if we maintain this position will be have a useless Rel-1 and I recommend you to give a augmented answers. Regards jamil
De : [email protected] [mailto:[email protected]] De la part de denghui (L) Envoyé : dimanche 23 juillet 2017 10:24 À : Pasi Vaananen; Alla Goldner; [email protected] Cc : onap-tsc Objet : Re: [onap-tsc] [onap-discuss] Architecture Progress Just clarify one important thing here, GNVFM is in the scope of ONAP, no on the side of VNF vendors. Inline please == > From: Pasi Vaananen [mailto:[email protected]] Sent: Saturday, July 22, 2017 8:53 PM To: denghui (L) <[email protected]<mailto:[email protected]>>; Alla Goldner <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: onap-tsc <[email protected]<mailto:[email protected]>> Subject: Re: [onap-discuss] Architecture Progress I respectfully disagree, at least based on what has been said / presented in the meetings and written down on the present documents: "Interface between VNF and ONAP is quite simple :" Given that this has been under discussion for multiple years now, I would not say there is anything simple about it. Interface to VNFs is also not limited to templates only - it also includes all run-time APIs and other interfaces towards "G-VNFM" style functionality (i.e. in support of VNF and VNFCI LCM operations). Collectively, VNF package and *all* artifacts thereof, as well as all interfaces that are exercised by the VNF and its associated component instances towards ONAP form the "interface" between ONAP and VNF vendor. As the majority of functions related to these interfaces and descriptors is implemented in the APP-C or VF-C, if we have single set of these, then both need to do the same thing, or functionality would need to be somehow split between the two. Right now, as already documented in Chris's email, most of the VNF LCM operations between the APP-C and VF-C have full overlap. == > as said in the beginning, GVNFM is in the scope of ONAP, its south bound interface (interface with VNF) is not matter with architecture. "Heat(ECOMP)" Heat is primarily interface to specific VIM, i.e. OpenStack. It is true that current APP-C uses Heat Orchestration Templates. However, the discussion is not the past state but on the future direction of the system, including direction of descriptors and APIs, and their implementation or at this point implementations. The current approved APP-C project proposal here<https://wiki.onap.org/pages/viewpage.action?pageId=3246996> states: * APPC model will be based on ONAP TOSCA and Yang containing a dependency model, LCM recipes, configuration templates, policies etc. * APPC provides multi-protocol southbound plugins, including support for NETCONF, Chef via a Chef Server, and Ansible and ability to operate through vendor specific VNFM/EMS via adaptation through a plugin. At least the "ONAP TOSCA" (VNFD), Yang, potentially policies, and "etc.", Chef/Ansible, and S-VNFM interfaces from the above list are "interfaces" or touch-points that VNF vendors would need to integrate with (in addition to DCAE metrics/events interfaces which indirectly ultimately are associated with policy / controller actions as well). == > If you are strongly believing in one interface to VNF, then you could go to VNF requirement or VNFSDK project, and strongly suggest to remove Heat support over there. As far as I can tell from the project description, there is currently no implementation of the "sideways" APIs of ETSI architecture reference model between the VNF/EM and the "G-VNFM" function equivalent of APP-C, beyond of the indirect actions that can be taken through events received through e.g. VES/DCAE. For example, there is no implementation of ETSI SOL style API for VNF to directly call to request "scale some component group out to level 'x'". However, there is "NBI" APIs for these operations, but it is not clear (at least from description) whether those are allowed to be invoked by the VNFs themselves (and if so, how) or ONAP internal subsystems only (if it is set of REST APIs, those could be exposed to VNFs as well, but whether that is not very clear from the current APP-C context diagram). "TOSCA(OPEN-O)" Obviously, the Open-O implementation came with their definition of TOSCA artifacts, in this context for VNFDs, and I am aware that those have been brought as input to ONAP along with the seed code to support implementation. However, from the approved VF-C project proposal here<https://wiki.onap.org/pages/viewpage.action?pageId=3246989> VF-C does for the VNFM LCM functions: * support VNF lifecycle management based on the ONAP tosca and yang data model and workflow * VNFM Component, * compliant with ETSI NFV MANO architecture and information model * providing full life cycle management and FCAPS for VNFs which do not require a vendor VNFM, * providing interface and work with DCAE and Policy for Close Loop Automation. * How does this align with external standards/specifications? * VF-C takes the following specifications as a reference. * APIs/Interfaces: ETSI NFV IFA 007, ETSI NFV IFA 008, ETSI NFV SOL 005 - additional API may be required * Information/data models: ETSI NFV IFA 015, ETSI NFV SOL 001, ETSI NFV SOL 004 - additional API may be required == > I am defensing here how VNF vendor will be influenced only, if you have discussion about VFC, would better goto VFC projects. thanks "it has nothing with architecture discussion" I think that we have different understanding what the architecture discussion is, or should be about. The discussion as far as I can tell so far has been about the merging of the codebases as well as their future direction. As far as I am concerned, this is part of that discussion. I would also say that discussion is not only restricted to architecture calls. I am pointing out that there is large overlap on implementations, and unless fully addressed this will lead to divergency between the overlapping parts (in addition to wasted resources on synchronization, development, testing, integration, support, alignment and backwards compatibility maintenance of the associated codebases). This problem is also not limited to descriptors alone like you seem to think based on your response, but also to their underlying implementation details, and also any other descriptors/models, and run-time interfaces between VNFs and ONAP as related to VNF LCM operations. == > people have different understanding based on their seedcode, how could I know what is correct based on reading only if I am not coding anything here. My email is only discussing VNF interface, architecture discussion should go to architecture call. Thanks DENG Hui Regards, Pasi On 07/22/2017 06:52 AM, denghui (L) wrote: Hi all I guess that people are confusing about the interface of VNF with ONAP architecture, Interface between VNF and ONAP is quite simple : Heat(ECOMP) or TOSCA(OPEN-O), it has nothing with architecture discussion. I agree with Chris's suggestion here, either you need to understand the implementation or join architecture call. Best regards, DENG Hui From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Alla Goldner Sent: Saturday, July 22, 2017 1:56 PM To: Pasi Vaananen <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: onap-tsc <[email protected]><mailto:[email protected]> Subject: Re: [onap-discuss] Architecture Progress Hi Pasi, Jamil, Chris, all, I fully agree with Pasi's view. When we started this work ,the assumption was that whatever our merged architecture will look like internally, we should deliver a single set of interfaces between the VNFs and ONAP. And this is not what we are having right now with R1 proposed architecture. Also, indeed, if we allow interfaces' divergence for R1, it is going to be hard to reverse later. One possible outcome is that some of VNF vendors would want to wait until the divergences are resolved. The other possible outcome is that we continue proceeding with 2 different tracks within ONAP - one coming from Open-O and the other one coming from ecomp, and each one of VNF vendors making a decision which track they want/need to support, in some cases having a need to support both thus doubling the effort. The latter is clearly not the optimal way forward, and not what we want to achieve with ONAP, we should try to see how we avoid it at least in a longer term, in my view. The former may be significantly improved and timelines may be shortened, if we manage to work on it effectively now and provide the shortest path to get there from the current state - and Vimal's proposal of target merged architecture looks like a great step towards it, preserving all functionality coming from APPC and VF-C, but making a single set of external interfaces. I think we should give a very high priority to those discussions and handle them now, in parallel to R1 work. Best regards, Alla Goldner Open Network Division Amdocs Technology [cid:[email protected]] From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Pasi Vaananen Sent: Friday, July 21, 2017 11:15 PM To: [email protected]<mailto:[email protected]> Subject: Re: [onap-discuss] Architecture Progress Hi Jamil, In ONAP F2F in New Jersey, there was what I thought was "agreement" that there is to be only one set of VNFDs / interfaces for ONAP. If that is strictly enforced (like I think it should be, as these collectively form the "interface" between the VNF vendors and ONAP - if the overlap would be e.g. on NS level descriptors, it would not be as bad, as those could be considered to be system internal and therefore not as much of inter-operability problem), then having two parallel implementations means that they would need to do exactly the same things, and be essentially "indistinguishable" from each other even on their behaviors associated with these descriptors and interfaces. Obviously, strict enforcement of this would imply about 100% overlap on the associated development, testing, etc. activities (minus any sharing of code between the teams). And, in addition, coordination between the two teams to accomplish the required level of agreement in absence of the independent / detailed specification that is to be implemented, which would further slow things down. If ONAP community chooses to allow divergence here for r1, it is going to be hard to reverse later (assuming that someone would pick sides and actually deploy the result - more likely outcome is that VNF vendors would want to wait until the divergences are resolved, i.e. R2 at the earliest per current "plan"). It is also going to be difficult to "push back" on e.g. ETSI and OASIS on descriptors etc. if ONAP community itself cant get into one opinion on what to push. I like Vimal's "Target Merged Architecture" slide #3 at high level - what is the shortest path to get there from the current state ? Regards, Pasi On 07/21/2017 03:09 PM, [email protected]<mailto:[email protected]> wrote: Hi Chris I have participated partially to the last 2 meetings, my position was represented by Vimal. We need time to analyse the output before to take a position and as you know the subcommittee is consultative and we need to discuss the output in the TSC. I think we have clearly Identified overlap between 2 approches and there is a high risk to not have a useful Rel-1 as we have many changes on the technical components in addition to 2 different VNF guidelines. Regards Jamil Cordialement Jamil Le 21 juil. 2017 à 20:17, Christopher Donley (Chris) <[email protected]<mailto:[email protected]>> a écrit : Dear Jamil, I'd like to invite you to participate in our ARC calls. We generally meet Tuesdays from 1400-1600 UTC (but we'll have to adjust next week due to the developer meeting). We have considered multiple presentations over the last four weeks (including the one you referenced), and after careful discussion, we aligned on the release 1 and release 2 functional architecture I shared. I held consensus checks on each of the last two calls and did not hear dissenting opinions from the high level approach. The version of the diagram that I shared represents the community consensus from Tuesday's call. If you have concerns, please share them during the meeting. I'll be happy to reserve a slot on the agenda. Chris From: [email protected]<mailto:[email protected]> [mailto:[email protected]] Sent: Friday, July 21, 2017 8:59 AM To: Christopher Donley (Chris) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: RE: Architecture Progress Dear Chris Thank you for your work and the presentation, we can say that this is a first step but we have not agreed on the architecture mentioned in your slide as Vimal presented another architecture (consigned by AT&T, Amdocs and Orange). Regards Jamil De : [email protected]<mailto:[email protected]> [mailto:[email protected]] De la part de Christopher Donley (Chris) Envoyé : jeudi 20 juillet 2017 22:05 À : [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc : [email protected]<mailto:[email protected]> Objet : [onap-tsc] Architecture Progress Dear ONAP Technical Community, I'd like to update you on progress from the Architecture Committee. * For Amsterdam, we agreed to use the current architecture, as discussed since ONS. This is to reduce risk of late changes to the project teams, who have built their plans based on the current baseline. * Longer-term, starting with Release 2, we reached consensus on an approach to resolve the APP-C/VF-C challenge. We are developing a three-layer orchestrator/controller functional architecture, with service orchestration/resource orchestration/controllers. Note that this functional architecture does not imply a project structure. Between now and the beginning of the R2 planning cycle, the team will drill down to the next level of detail on interfaces and project alignment, and then the projects will map code into the architecture to guide R2 plans. Cross-project discussions have already begun, and will continue over the coming weeks. Meeting logistics will be sent to the ONAP-discuss email list for those who are interested in participating. I have attached a set of diagrams that we reviewed in the Architecture Committee to illustrate both the R1 and R2 architecture. Note that in the R2 slide, since we are focused on the functional architecture and not the projects, we removed some of the boxes listing projects that support ONAP, but don't provide interfaces or data flows through the system. For those interested in more detail, we will discuss this during the developer meeting next week. Chris _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ onap-discuss mailing list [email protected]<mailto:[email protected]> https://lists.onap.org/mailman/listinfo/onap-discuss This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at https://www.amdocs.com/about/email-disclaimer _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ ONAP-TSC mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-tsc
