Dear Chris and ONAP community I understand and appreciate your leadership of this subcommittee to align different position and I would to clarify some points:
1- Yes the VFC is mentioned in the ONAP charter but without any explanation about the functionality of this component which to my knowledge it is not part of the Open-o and we have discovered it during the ONS 2017. Comparing to Ecomp, we have a clear documented white paper describing overall architecture and technical components. 2- Concerning the AT&T /China Mobile agreement, I would like to clarify that ONAP is a merge between the OpenEcomp project proposal supported by some members and the Open-O project and not an AT&T/China Mobile project. Phil and Kenny I would like you as LF to clarify this point as my understanding the ONAP project is governed by a clear charter and not by some company agreement or discussion. 3- I would like to remember the community that the TSC decision, during the last F2F meeting in China, was to approve the APPC, VFC and SO provisionally waiting an alignment from the architecture point of view : the TSC approved the VF-C (APPC/SO) Projects as an incubation projects within ONAP provisional on alignment with the overall architecture if such dependencies are identified http://ircbot.wl.linuxfoundation.org/meetings/onap-meeting/2017/onap-meeting.2017-06-08-01.38.log.html http://ircbot.wl.linuxfoundation.org/meetings/onap-meeting/2017/onap-meeting.2017-06-09-01.07.html 4- My expectation was to have a feedback from the architecture subcommittee to the TSC on this alignment and to have a final approval of these 3 projects. Phil and Kenny I would like to raise this question during the next TSC meeting and also to indicate in the wiki that these 3 projects are provisionally approved. 5- We have clearly identified an overlapping problem between APP-C, VF-C and between VF-C and SO (as VF-C is also an NFVO) and the conclusion was to wait Rel-2 or Rel-3 in order to find a solution. This will mean that we have a high risk to not deliver a useful Rel-1 and this risk was clearly viewed during the virtual meeting discussion on DCAE and SDC. 6- I think we have a time to converge rapidly our view by merging APPC and VFC and having one integrated orchestrator, as proposed by Vimal, before to be late. The industry is waiting our Rel-1 and unfortunately, as Justin Paul said in his Linkedin post, ONAP leads, but its not over 'til the fat lady sings... and we may not have any song ... https://www.linkedin.com/pulse/nfv-orchestration-onap-leads-its-over-til-fat-lady-sings-paul?trk=v-feed&trk=v-feed&lipi=urn%3Ali%3Apage%3Ad_flagship3_search_srp_content%3B19yY4VKdyLkiQWwvYF88Qg%3D%3D Regards Jamil De : onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] De la part de Christopher Donley (Chris) Envoyé : lundi 24 juillet 2017 23:40 À : Thomas Nadeau; Alla Goldner; Pasi Vaananen; onap-discuss@lists.onap.org Cc : onap-tsc Objet : Re: [onap-tsc] [onap-discuss] Architecture Progress Tom, I fully agree with your comments about top-down management. The architecture subcommittee is here to support and advise the projects, not command the projects. I also agree with your point about this being a desired target state. But I want to clarify that the projects have been involved in the creation of the long-term architecture. This has not been an isolated exercise. I'd like to provide more context on how we reached this point. During the merger process, AT&T and China Mobile reached agreement on an initial set of modules to be included in ONAP (8 from ECOMP and 3 from OPEN-O, including SO, APP-C, and VF-C, which have been challenging to integrate because of overlapping functionality). These are written into the ONAP Charter. A small group of people then negotiated an initial R1 architecture and presented it at ONS. It was also addressed in subsequent developer meetings prior to the formation of the architecture subcommittee. We are not diverging from that in the Amsterdam timeframe because we heard feedback from projects that their release plans were already based on the initial architecture, and divergence would add delay and risk into the release. Over the course of the last four weeks or so, the architecture subcommittee considered multiple proposals to resolve the overlap from multiple operators and from the affected projects. In the short term, there is a lot of divergence. Some operators prefer the APP-C approach and some prefer the VF-C approach (some want both). When we broke down each of the components and analyzed the functionality in each, a path for harmonization did appear, and is reflected in the R2 target that I shared. We saw variants of the consensus approach in multiple proposals, including the one Jamil referenced and one from the SO project. We heard favorable comments from other project teams, as well. Projects were engaged in the conversation. Now, this architecture is a high-level target, and there is more work to be done to get to the next level of detail (e.g., mapping projects into the structure, defining interfaces, and then looking at code). That work is being driven by the affected projects, and I can attest that several project-level meetings have occurred to start the conversation (in parallel with R1 work and prior to R2 planning). I feel strongly that this is the right approach, with the architecture subcommittee providing cross-project support, advice, and coordination, but the decisions regarding how best to align the projects with the framework are made by the projects themselves. Tom, to your point, the projects will come back to the architecture subcommittee after they have worked out some of the details, and we may need to iterate the architecture based on their findings. Chris From: onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org> [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Thomas Nadeau Sent: Monday, July 24, 2017 11:55 AM To: Alla Goldner <alla.gold...@amdocs.com<mailto:alla.gold...@amdocs.com>>; 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-tsc] [onap-discuss] Architecture Progress Hi, I've read through all the messages on this thread this afternoon, and have a few things to add from my past experiences with open source projects that might help level set things and also help clarify the confusion that I sense some people are experiencing in why this combined architecture isn't moving forward as swiftly as some would like it to. In my opinion, the answer to this is how open source projects often do not easily accept top-down management approaches, and how they more typically respond. In this case, an architecture has been created that is now shown to projects with the expectation that they will comply with it - whether or not the subordinate project agrees with the architecture, or has the time to do so. It is also important to observe that the merged architecture, objectively speaking is a *desired* architecture; it is not a picture of the existing project components. That is, it is one to aspire to at some point in the future, and not necessarily as part of the next release. It is this specific point that is giving people the most heartburn: the prospect of this picture not becoming reality in the next release. The reality is that the task of getting the subordinate projects to retool themselves in order to go along with a unified architecture is more challenging than writing an architectural document and telling the projects to follow it. I know many in this project would like the process here to be that straightforward, but it is turning out once again to not be. Understanding why and embracing this reality is the key to moving this project forward. Constituent projects need to get working and figure out how they will implement the merges in their code bases, and then figure out when/how this will be scheduled in the master release schedule for the project. This has to happen before people start building any new functionality including that that is likely needed to address the desired merged architecture for a number of components. No amount of wishful thinking or mandates is going to change this. I say this because I am observing that right now there are still discussions within projects about how to go about addressing their backlogs. This tells me that the blocking, tackling and scaffolding needs to be setup for projects to function before we talk about other things. This is an indication that it might just be a bit early to be asking projects to figure out how to exist within a merged architecture - or pay attention to the details of one. It might also turn out that after a phase of implementation, that the system architecture needs to be different that is postulated in the desired merged architecture. Its nice to start with a nice and detailed architectural plan for what everything is supposed to look like at the end of a project, but we have to be patient in how we get there and also understand that in modern software engineering, is rare to have it all figured out a priori. With that in mind, it appears that as of now that it is going to be difficult to see a way forward where all the lego blocks come together from each project, have been rewritten to accommodate the desired merged architecture and requirements, and do so in time for the next release. That also assumes that all of the projects agree on where they are going - which from what this thread sounds like is not exactly the case right now. One way less resistive path forward is to start by agreeing to disagree on certain portions of the architecture, while recognizing the portions of the architecture that do enjoy buy-in from a significant number of people. Next, do what we did in past projects: release multiple options simultaneously and let derivatives repackage as necessary downstream until such time as the developers are pushed in one way or the other. If some projects do have time to start down the road of the desired architecture, then great, but if they do not accept that and work on simply getting them out in as stable a form as possible. To this end, perhaps focus the integration teams on making sure that all the components build and can be tested to some degree and that the major functional "core" components work. Then as projects gradually build better successor components in the mold of the desired architecture, the old ones will be deprecated. This is decidedly not as clean as some would like it to be and will take time and patience for sure, but in the end I think will bring valuable implementation and deployment feedback to the party and that after some iteration and feedback, will help projects make better decisions on what to build going forward. It will also result in a project and components that are built to meet the goals of the project, which is what I hope and think we are all after. --Tom 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 AM 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@01D302C5.88CFF7E0] 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 _________________________________________________________________________________________________________________________ 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 https://lists.onap.org/mailman/listinfo/onap-discuss
