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] 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] > https://lists.onap.org/mailman/listinfo/onap-discuss
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
