Dear Hui, First of all, let's assume that all people participating in the discussions do understand what they are talking about. I strongly believe such a respectful behavior will help to reach consensus, which is our common goal.
Secondly, let's look on the presentation provided by Vimal. There is a key difference between the slide 2 (current R2+ view) and the slide 3 (Desired Integrated view). This difference is in having an integrated "Standard & sVNFM Adaption Layer" on slide 3. I believe our discussion should be concentrated on this and other differences, their pros and cons, and overall involved modules' functionalities, depending on those architecture alternatives. I suggest we continue these discussions during next week's virtual meeting. Best regards, Alla Goldner Open Network Division Amdocs Technology [cid:image001.png@01D302F9.1840D290] From: denghui (L) [mailto:denghu...@huawei.com] Sent: Saturday, July 22, 2017 1:52 PM To: Alla Goldner <alla.gold...@amdocs.com>; Pasi Vaananen <pvaan...@redhat.com>; onap-discuss@lists.onap.org Cc: onap-tsc <onap-...@lists.onap.org> Subject: RE: [onap-discuss] Architecture Progress 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: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Alla Goldner Sent: Saturday, July 22, 2017 1:56 PM To: Pasi Vaananen <pvaan...@redhat.com<mailto:pvaan...@redhat.com>>; onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Cc: onap-tsc <onap-...@lists.onap.org<mailto:onap-...@lists.onap.org>> 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:image001.png@01D302F9.1840D290] From: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Pasi Vaananen Sent: Friday, July 21, 2017 11:15 PM To: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> 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, jamil.cha...@orange.com<mailto:jamil.cha...@orange.com> 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) <christopher.don...@huawei.com<mailto:christopher.don...@huawei.com>> 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: jamil.cha...@orange.com<mailto:jamil.cha...@orange.com> [mailto:jamil.cha...@orange.com] Sent: Friday, July 21, 2017 8:59 AM To: Christopher Donley (Chris) <christopher.don...@huawei.com<mailto:christopher.don...@huawei.com>>; onap-...@lists.onap.org<mailto:onap-...@lists.onap.org>; onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Cc: onap-...@lists.onap.org<mailto:onap-...@lists.onap.org> 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 : onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org> [mailto:onap-tsc-boun...@lists.onap.org] De la part de Christopher Donley (Chris) Envoyé : jeudi 20 juillet 2017 22:05 À : onap-...@lists.onap.org<mailto:onap-...@lists.onap.org>; onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Cc : onap-...@lists.onap.org<mailto:onap-...@lists.onap.org> 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 onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> 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 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 <https://www.amdocs.com/about/email-disclaimer>
_______________________________________________ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
