Topics

OPEN-O Architecture Meeting Notes


Cas Majd
 

All,

Please find below the notes for this week’s OPEN-O TSC Meeting. Note that starting this week, the Technical Steering Committee (TSC) and the Architecture Committee (ARC) conduct separate meetings, on Tuesdays and Wednesdays respectively. This is the report for the TSC meeting.

 

TSC Meeting Venue:  The OPEN-O TSC Meeting Conference Call took place on Tuesday June 14th, 2016 from 7:00am to 8:00am PST. 30 people from 7 organizations participated.

 

Summary:

1.       Chris D. gave a summary report on last week’s achievements, reviewed open items (Uri’s email), gave a walk-through the Wiki tools, and discussed the process for developing governance and policy documents.

a.       Charter has been approved and is posted on Wiki. The Charter governs our behavior as the TSC, defines officers and describes the organizational structure.

b.      Elections held with following results:

                                                               i.      Chris Donley was elected at Chair of the TSC.

                                                             ii.      Uri Elzur as the Chair of Architecture Committee group and Vice Chair of the TSC.

                                                            iii.      Voted to open the TSC meetings to everyone in community with the exception of executive sessions, which will be made know in advance.

                                                           iv.      The TSC members may delegate alternatives in case the voting TSC member cannot attend

c.       Release Plan discussed and posted on Wiki

                                                               i.      Targeting release end of 2016

                                                             ii.      Internal release date set for Nov 3rd; this date will not be publicized externally. We are looking for additional feedback from board on both the release plan and the use case. So the release date may change in near future.

d.      Four projects proposal have been approved. There were open items on each project proposal. Uri has been documenting those open items in an email.

                                                               i.      NFV-O

                                                             ii.      SDN-O

                                                            iii.      GS-O

                                                           iv.      Common Service

                                                             v.      Two additional project proposals are in the pipeline that will be reviewed in coming weeks when we do the planning process through the remainder of this month.

e.      SLACK tool is a conferencing note taking for the community. People feel free to take notes and conduct discussions on the SLACK.

                                                               i.      Link for SLACK: open-o-tsc.slack.com

f.        Gildas Lanilis was introduced as the OPEN-O Release Manager. 15+ years of experience in telco software development.

g.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Some participants could not join the GoToMeeting meeting due to cap on number of people that can participate. Volunteers were asked to drop off.

                                                             ii.      The team has been borrowing OPNFV tools so far. Linux Foundation will be asked this week to come up with resolution. The group will need a larger conference bridge.

                                                            iii.      All content of the presentations is put on the Wilki.

                                                           iv.      What template to use for the project planning? Please continue using the existing project proposal PowerPoint templates that we have used last week and at our Seed Code meeting. It is posted on the Wiki this week. The Project Lifecycle Document still needs to be written. A rough outline of the release plan is on the Wiki.

                                                             v.      Can we use the ODL template for project planning? OPEN-O projects have slight differences in the information that we need compared to ODL. There are a couple of additional questions related to the architecture that we would like to cover in our project plans. So, please use our existing project plans.

                                                           vi.      To make best use of our time during the planning phase, in tomorrow’s architecture call we will continue to review project proposals and talk about OPNFV MANO project (draft slides available)

2.       Uri E. gave a walk-through some of the open items from last week.

a.       The review is structured in two sections with three types of comments:

                                                               i.      Brief commentary, which project owners/participants need to take a look at and comment

                                                             ii.      Decisions (very few)

                                                            iii.      Open issues where actions are needed (this is the largest category)

b.      Decisions that we agreed are:

                                                               i.      Readjust each proposal’s scope depending on how the whole project comes together.  Coordinate adjustments between different proposals.

                                                             ii.      Creating a long term architecture proposed in parallel (not gating) that will include reference to areas that are out of scope so that we have at least a discussion on how they relate to or impact our projects (examples are OSS/BSS, migration issues, etc.)

                                                            iii.      Each project and the main project will have a document about the “problem being solved”. So that we have the same for the whole OPEN-O project and each sub-project. The individual projects may have to adjust according to the overall problem being solved.

                                                           iv.      For release 1, the drivers are separate will be integrated into respective project of NFVO and SDN-O.

c.       Questions:

                                                               i.      NFV-O was the first sub-project reviewed. But at the same time, this helps address many questions related to the Open-O wide project as well.

                                                             ii.      Started commenting slide-by-slide on Lingli’s project proposal on NFV-O, so that we make sure we are all on the same page and can finalize the project proposal.

                                                            iii.      First Question: Slide# 3 makes a general reference to NS. The O-Commons project also refers to VNF on-boarding. There is also a reference to on-boarding during the design phase.

1.       Question: Are we talking about NS of NFV or are we talking about NS of pNFV, vNFV and the corresponding VNFFG, etc.?

a.       Answer: NFV-O is responsible only for VNF Network Service. The E2E NS that includes VNF and legacy devices, it is to GS-O to do E2E orchestration. 

2.       Question: What do you expect to get? Do you expect to get NSD?

a.       Answer: NFV-O supports 5 different lifecycle management operations (CRUD Operations). Each operation we expect to receive different things. The first operation step is about NS template design. For input to the design you may need software image and a package of NSD, VNFD, VNFFG and other artifacts.

d.      The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Not all TSC members had received Uri’s email and were not ready to really participate in the discussion.

                                                             ii.      Uri’s email and review was too lengthy to be covered in the TSC meeting. People will review and respond via email. Discussions will follow in smaller teams and continued in the larger TSC meeting only if it concerns the larger end-to-end solution.

                                                            iii.      From the Common TOSCA perspective, there are many integration points between the components. We need to do joint engineering work and shared design to ensure that all touch points and overlaps are covered. Joint design would facilitate proper project planning.

                                                           iv.      We should work on this offline through Wiki, email, SLACK, and other tools. We should work off-line asynchronously. Wiki would be a better choice for this discussion to capture all the documentation. SLACK is more for online discussions. The content on SLACK needs to be copied over to the Wiki.

                                                             v.      Will have follow up design session between various groups. Should each group have these discussions separately? If the integration point is just between two teams, feel free to do it in a smaller group. If it relates the overall project, then bring it to the TSC. Try to make progress over email and if email is not enough, we will have smaller group meetings.

3.       Chris D. gave a walk-through the Wiki pages.

a.       Link is: https://wiki.open-o.org. It is still under development. Use it for new project proposals, for discussions, for alignment between projects, and to share information between different people.

b.      Starting to populate things. The conf bridge info is in the “Meeting Times”.

c.       Release Plan currently just has the milestones. It should become similar to ODL sites, containing much more details.

d.      Kick-off Meeting Outcome contains the resolutions from last week.

e.      Approved Project Page is not populated yet. As we move forward and have more artifacts, we can have individual pages for each project. Those would be pages similar to what Uri created.

f.        The TSC Governance Document page contains the TSC Charter v6 that is approved. This has pdf and full Wiki version.

g.       TSC Policies. We have not reached consensus on yet. Will send out emails this week to the board members to reach consensus.

h.      Project Lifecycle Documents has not been started yet. It will be similar to OPNFV and ODL. ODL defines 4 steps and OPNFV defines 5 steps. We will start with 4 and expand as needed. Volunteers are needed to work on the document.

i.         The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Currently the Wiki registration uses Google services. It will cause problems for people in China

                                                             ii.      Somebody outside of China can do the registration work for people in China. If people in China have problem, first reach out to people from your company outside china. If it does not help, then reach out to Chris for help.

                                                            iii.      Meeting notes shall go to the Wiki as well. There will be a page for TSC meeting and a page for notes by date. People prefer to use Wiki for meeting notes and slack for common discussions.

                                                           iv.      Put project proposal on the Wiki. Feel free to use the Approved Projects page for release plans.

                                                             v.      There is a bottom for watching important pages. Intent to use our calls for the next few weeks for the project proposals and do the document related work through the email list.

                                                           vi.      The self-service link for the mailing list sign up is: http://lists.open-o.org/mailman/listinfo

                                                          vii.      Will add a link to the Wiki for the mailing list sign up.

 

 

1.       Action Items:

a.     Everybody is asked to make sure that their name is added to the TSC and ARC mailing lists. Link is: open-o-technical-formation@...

b.      Everybody to review Uri’s email and provide comments/answers to finalize the project planning

c.       Everybody to familiarize with the Wiki and TSC document

d.      Volunteers are needed to work on the Project lifecycle Document

 

 

 

From: Casem Majd
Sent: Wednesday, June 01, 2016 10:58 PM
To: Casem Majd; open-o-technical-formation@...; Christopher Donley (Chris); Michael McBride
Cc: Marc Cohn
Subject: RE: OPEN-O Architecture Meeting Notes

 

All,

Please find below the notes for this week’s OPEN-O Architecture Meeting.

 

Meeting Venue:  The OPEN-O Architecture Meeting Conference Call took place on Wednesday June 1th, 2016 from 6:30am to 7:55am PST. 27 people from 10 organizations participated.

 

Summary:

1.       Olga presented Four Service Modeling Roles needed for supporting OPEN-O Use Cases. This was a summary report of the Beijing meeting.

a.        Outline of the talk:

                                                               i.      Defined the role of four different “Service Designers” for various layers of OPEN-O service stack; defined the relevant terminology, defined the ownership of descriptors for each layer, and defined the proper abstraction for each layer.

                                                              ii.      Defined the service design use case

b.       Role #1) GS-O Global “Service Designer”

                                                               i.      This is the top most service designer with the end-to-end view

                                                              ii.      It is the Designer for the global Network Service. It understands the end-to-end service at the global layer (business layer?) and manages NSDs in the GS-O service catalogue.

c.       Role #2) NFV-O Network “Service Designer”

                                                               i.      It is the Designer for the Network Service in a specific NFV-O domain. It manages the NSDs for a single NFV-O domain in the NFV-O service catalogue.

d.      Role #3) SDN-O Network Connectivity “Service Designer”             

                                                               i.      It is the Designer for the network connectivity service in the specific SDN-O domain. It manages NCSDs in the SDN-O service catalogue.

e.      Role #4)  “VNFD Designer”

                                                               i.      It is the Designer for VNF Descriptors that can either create new VNFDs or import vendor VNFDs in the VNFD Catalogue.

f.        The ownership of the descriptors (NSD, VNFFGD and VNFD), as well as the level of abstraction and ownership are as follows:

                                                               i.      It is a business decision as to what is owned by GS-O, NFV-O and SDN-O and what needs to be abstracted by NFV-O and SDN-O and what is visible to GS-O.

                                                             ii.      NFV-O and SDN-O ownership of descriptors:

1.       Based on the separation of catalogue into GS-O, NFV-O and SDN-O, the ownership is split based on what is business (GS-O) and what domain/technology policy (NFV-O/SDN-O)

                                                            iii.      NSDs or VNFFGD at the NFV-O layer:

1.       Descriptors needed as they have some additional attributes that must be filled in by service designer and are not present in VNFFGD. Example: designer, version, lifecycle management scripts, deployment flavor, security, etc.

2.       The service descriptors differ by different levels of abstraction, but are based on a shared model.

                                                           iv.      VNFDs visibility at the GS-O layer:

1.       There are different layers, some VNFDs may be visible at GS-O layer (e.g. vCPE business decision), some can be visible at the individual domains (e.g. vFW always by default, or policy, only if it is not business decision). Architecture must be flexible to support different business organizations.

2.       Abstraction at different layers needed, GS-O does not need to be aware of all VNFDs, VNFs and fully expanded forwarding graphs  (VNFFGD and VNFFG)

3.       GS-O has its own abstraction and view of the network service

4.       NFV-O has visibility into the graph for its domain

5.       SDN-O has visibility into all layers of connectivity

e.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      There were objections to the use of “Business Layer” for the GS-O layer. OPEN-O is not a BSS. It is n OSS. GS-O deals with customer-oriented services, not the business layer.

                                                             ii.      Are roles #1 and #4 the same? More discussion is needed at the next face-to-face meeting to clarify the roles and details of GS-O. We need to define the functionalities and roles and derive from that the interface requirements for each layer. Need to close differing points of view among the team members.

                                                            iii.      Our design needs to be flexible enough to support different business decisions on ownership.

                                                           iv.      Open questions that need to be discussed at the next meeting:

1.       NFV-O Network Service Designers per NFV-O Domain?

2.       Catalogue per NFV-O Domain?

3.       VNFDs either in the GS-O Domain or NFV-O Domain?

4.       Separate SDN-O designer per technology?

5.       No agreement yet on the terminology for SDN-O descriptors (NSD is used by ETSI, TMF/ONF/MEF uses Specification/ Descriptors/ Templates)

2.       Marc Cohn presented planning for next week face-to-face meetings in Shenzhen

a.       So far, the membership data are as follows:

                                                               i.      Premier Members are CMCC, Huawei, Intel, PCCW and ZTE. Gigaspaces is also very likely.

                                                             ii.      General Members are Canonical, Cloudbase Solutions, Infoblox and Raisecom. RedHat is also very likely.

                                                            iii.      Deadline for submission of membership applications is tonight

                                                           iv.      The official list will be sent Wednesday 2 June to members only.

b.      OPEN-O Kickoff is scheduled for June 7-9 in Shenzhen

                                                               i.      The meeting Venue in The Ritz-Carlton, 116 Fuhua San Road, Futian District Shenzhen 518048, P. R. China.

c.       Refer to Jessie Liu's emails for details on hotel reservations.

                                                               i.      Contact Jessie for help with hotel bookings.

                                                             ii.      Jessie coordinated marketing activities

d.      Agenda is 3-days

                                                               i.      Day 1 (June 7th): Premier Founding Members only

1.       Board Meeting (9am – 1pm)

2.       TSC Meeting (2pm – 5pm)

3.       Board and TSC meeting are non-overlapping to accommodate those individuals who need to be in both

4.       Evening: Board / TSC Dinner (to enable the Board & TSC to get to know one another)

                                                            ii.      Day 2 (June 8th):

1.       Joint Board/TSC meeting to shape responsibilities (open only to Premier Board/TSC members) (morning)

2.       TSC Meeting #2- Assuming TSC passes a motion in advance of TSC #2, this meeting will be open to all (afternoon)

3.       Marketing Meeting #1- In parallel with the TSC Meeting #2

4.       Evening: Social Event to encourage everyone to get to know one another, and celebrate the launch of OPEN-O

                                                          iii.      Day 3 (June 9th):

1.       TSC Meeting #3- As agreed during TSC Meeting #2, assuming TSC passes a motion in advance of TSC #2, this meeting will be open to all

2.       Marketing Meeting #2- As needed, In parallel with the TSC Meeting #2

3.       Breakout session (decide on during the Kickoff; two rooms booked for this purpose)

                                                           iv.      Marc is recording/prioritizing a comprehensive list of Board actions required, to guide the Board meeting agenda

                                                             v.      OPEN-O Governance Document stipulates that Board action is required to approve the nomination/election procedures for: General Member Board Rep, OPEN-O Board Officers (Chairman, Treasurer, and Secretary), and Marketing Chair

                                                           vi.      Marc agreed to verify with the LF the best practices for holding votes and elections prior to the Board meeting

e.      The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Uri requested that we determine an approach to conduct the General Member Board Rep prior to the Kickoff/Board meeting (so that the new General Member Board Rep can attend the Board meeting)

                                                             ii.      Priority is to ensure that elections happen as soon as possible, but the sequence is complex.

                                                            iii.      We need to find a quick method to elect the general member representative for the Board Of Directors.

                                                           iv.      Received request from Yale University and two Chinese Universities that they are interested to support SDNC and SDNO, and would like to contribute some code to our solution. There is a request to that our kickoff meetings on the 8th and 9th be open for individual contributors to attend the discussions as the associate member. Limit 1 per each university.

                                                             v.      Marc commented that as long as the TSC passes a motion at the first meeting (June 7th) to open up the TSC meetings, which he would expect to pass, then we can invite others interested in participating in the OPEN-O TSC meetings/ technical discussions. We better not make the distribution too broad, as there is a finite limit to the space.

                                                            vi.      Marc proposed that we impose the same limit that we did at the Seed Code Workshop (no more than 6 technical individuals per organization)

 

3.       Chris made a short walk-through the TSC Charter

a.       The OPEN-O TSC Charter is mainly based on ODL Charter

b.      The ODL charter is augmented by OPEN-O specific bylaw

c.       Unique points are the

                                                               i.      TSC subcommittee for the Architecture Team

                                                             ii.      Project roles are different

d.      The charter will be approved at the board meeting

 

 

4.       Action Items:

a.       Marc is working on the agenda for the Board meeting, joint Board/TSC meeting, and Marketing meeting #1

b.      Chris agreed to coordinate with the TSC members on an agenda for the TSC #1 meeting. Chris will prepare a proposal for the TSC agenda. Premier members should help Chris to create the TSC agenda.

c.     For next week’s meeting in Shenzhen, an agenda has been sent to the formation email group. Marc will send additional details this week

d.     Everybody to read and comment on the TSC Charter document. Deadline is next Wednesday (6/8)

 

Regards,

 

Cas

 

From: Casem Majd
Sent: Thursday, May 26, 2016 11:33 AM
To: Casem Majd; open-o-technical-formation@...; Christopher Donley (Chris); Michael McBride
Cc: Marc Cohn
Subject: RE: OPEN-O Architecture Meeting Notes

 

All,

Please find below the notes for this week’s OPEN-O Architecture Meeting.

 

Meeting Venue:  The OPEN-O Architecture Meeting Conference Call took place on Wednesday May 25th, 2016 from 6:30am to 7:30am PST. 22 people from 6 organizations participated.

 

Summary:

2.       Deng Hui (CMCC) presented an assessment of current OPEN-O budget

a.       A breakdown of the current budget has been presented, by

                                                               i.      Marketing

                                                             ii.      Developer collaboration

                                                            iii.      Legal

                                                           iv.      Others

b.      Budget estimation seems to be lower than expected. Suggest going through the budget again. (Consensus)

c.       List of tasks for the next face-to-face meeting on June 6th

                                                               i.      Anti-trust (LF program manager)

                                                             ii.      Election of BoD from general members (LF PM) (to be done before June 6th)

                                                            iii.      Elections for board officers, TSC chairs. (LF PM)

                                                           iv.      Authorization Board and LF about agreement and membership (LF PM)

                                                             v.      Proposal for our project officers based on our budget (Deng Hui Volunteer)

                                                           vi.      Budget  (Volunteer needed)

                                                          vii.      Marketing committee build up (Volunteer needed)

                                                        viii.      User Advisory Group document (Uri, Deng Hui, Marc volunteered)

                                                           ix.      TSC charter (Volunteer needed)

3.       Olga presented the summary report on the OPEN-O discussions from Beijing

a.       Approach 1:

                                                               i.      Use ARIA as bases for GSO and NFVO;

                                                             ii.      China Telecom + CMCC for SDN-O;

b.      Approach 2:

                                                               i.      This approach will be based on micro-services.

                                                             ii.      Take all modules that are in Java (ZTE, Huawei, CMCC) for GSO and NFV-O;

                                                            iii.      Huawei and China Telecom for SDN-O.

                                                           iv.      (GS-O NFV-O and ARIA for the parser in Common Functions)

                                                             v.      Workflow and Catalog under Common Services

c.       Approach 3:

                                                               i.      ManageIQ for GSO and NFV-O

                                                             ii.      Huawei + China Telecom for SDN-O

d.      Approach 1.5: 

                                                               i.      Approach 2 (GSO NFVO) and ARIA for the parser in Common Functions. ZTE for common services.

                                                             ii.      Aria Parser and Execution Engine will be used in GS-O and NFV-O

                                                            iii.      Re-use of Aria Parser and Execution Engine. Aria Parser and Execution Engine in Common-O to be reused by multiple projects.

                                                           iv.      Aria Execution engine will invoke business logic by other partners

                                                             v.      SDN-O REST API will be specified in the GS-O Service Template and the REST request will be sent by Aria execution engine

                                                           vi.      ManageIO will be the VIM and fill in some missing functions. This is the optimum solution to bring as much code as possible.

e.      The following considerations, concerns, comments, and questions were raised from the audience:

                                                          vii.      SDN-O and GS-O interaction. Do not expose TOSCA parser to all details of YANG. Only expose necessary details to TOSCA via REST.

                                                        viii.      Hierarchical layering may be supported in SDN-O.

                                                           ix.      May not use ETSI terminology, but instead using MEF, etc.

                                                             x.      We may need to continue this discussion at the next f2f meeting.

                                                           xi.      The interface between SDN-O and GS-O needs to be defined and solidified for release 1.

                                                          xii.      ManaegIQ was not mentioned in the details. Are there any opportunities to include ManageIQ. Consensus is that ManageIQ can fit into release 1.5 for doing tasks such as discovery, collecting information, monitoring, managing drivers, …

                                                        xiii.      Red Hat to work with GigaSpaces on defining the NBI and integrating to ARIA parser

4.       Jessie gave an update on pre-marketing committee and other marketing activities

a.       Members so far: CMCC, Intel, Huawei, ZTE (still open to other members)

b.      PR for official founding, covering message, high-level architecture, and call for participation.

c.       OPEN-O Mini Summit in Berlin. Agenda proposal.

d.      Submission of presentations for mini summit. Proposed selection criteria are:

                                                               i.      Strong relevance to OPEN-O

                                                             ii.      Attractive to audience

                                                            iii.      Speaker title and impact

e.      Sample suggestions for presentations:

                                                               i.      Invite potential operators to give a speech. 

                                                             ii.      Call on vendors to work with OPEN-O for on boarding

f.        The following considerations, concerns, comments, and questions were raised from the audience:

                                                            iii.      Do we have enough material to fill one-day’s worth of content (Brendan)

                                                           iv.      Code release is in November. We may not be able to disclose much. (Deng)

                                                             v.      How many developers can travel to the event given the short time (Chris)

 

 

Action Items:

1.       Red Hat to work with GigaSpaces on defining integration interface between ARIA and ManageIQ (Dave & Amir)

2.       Identify location of next face-to-face meeting (Marc C)

3.       Add the PR for the list of marketing activities for the mini summit. (Jessie)

4.       Everybody provide comments on the accuracy of OPEN-O description to Jessie (by May 27th)

5.       Call for submission of presentations for the mini summit before May 27th.

6.       Invite AT&T to give speech on ECOMP monitoring and analytics

7.       Election of BoD from general members (LF PM) (to be done before June 6th)

 

Regards,

 

Cas

 

From: Casem Majd
Sent: Friday, May 13, 2016 6:21 PM
To: Casem Majd; open-o-technical-formation@...; Christopher Donley (Chris); Michael McBride
Cc: Marc Cohn
Subject: RE: OPEN-O Architecture Meeting Notes

 

All,

Please find below the notes for this week’s OPEN-O Architecture Meeting. Thanks to Olga and Brendan for their contributions.

 

Meeting Venue:  The OPEN-O Architecture Meeting Conference Call took place on Wednesday May 11th, 2016. Meeting started at 6:30am PST and ended at 9:30am PST (~1.5 hours). 32 people from 8 organizations participated. We had two invited guests from our partner projects MEF LSO and OpenDaylight.

 

Summary:

5.       ManageIQ Presentation & Discussion

a.       Geert Jansen from Red Hat presented ManageIQ Functional Architecture Slides, especially addressing the discussions around MicroServices. The main question discussed was “why ManageIQ does not use MicroServices?”

                                                               i.      ManageIQ was developed using 30-40 years of experience in building management systems

                                                             ii.      ManageIQ does not take the MicroServices approach – It takes a platform approach – platform as a service.

                                                            iii.      To build a rich management platform, Red Hat advocates platform driven approach versus MicroServices approach.

                                                           iv.      A platform-based approach suits management applications that are tightly coupled by data.

                                                             v.      There are several services in the platform; It uses Ruby object model.

                                                           vi.      ManageIQ will be available as a container to aid integration.

                                                          vii.      One single virtual appliance can have 100 copies

                                                        viii.      Appliance can be bound to the region and to zone. They have multiple roles, one or more roles maps to the processes in the appliance

                                                           ix.      Red Hat wants to demonstrate the power of the ManageIQ platform at the OPNFV and show why one would use platform approach versus MicroServices approach – Red Hat is preparing a demo for OPNFV 2016.

b.      The reasons ManageIQ does not use MicroServices are:

                                                               i.      MicroServices is not the right approach for a management platform. MicroServices has some good things – separation (each MicroServices has independent APIs), performance/scale – but it is not the correct architecture. It is not the only way to do things.

                                                             ii.      The ManageIQ Platform got through acquisition and was built before MicroServices time

                                                            iii.      MicroServices approach is still not a well proven approach in the industry. MicroServices have not been proven to be a better architecture than a platform-based approach.

                                                           iv.      Management of resources has special requirements, where we need tighter coupling than in other domains.

                                                             v.      It is not clear that MicroServices can be efficient in Data Model driven systems

                                                           vi.      MicroServices has a large cost, Red Hat believes cost is not worth the benefit

c.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      DengHui – Advocates for MicroServices. MicroServices allow easier integration of components from multiple companies that use diverse technologies. MicroServices facilitates the integration of different components that come from different companies with different code base. ManageIQ is coming late to OPEN-O, and more analysis is needed.

                                                             ii.      Uri – Why would MicroServices be a better approach than other alternatives? How would MicroServices allow easier integration? Is REST the main advantage?

                                                            iii.      DengHui – OpenStack is an example for implementing MicroServices with success. MicroServices allows plug-and-play model, where each module is independent of the message bus, allowing each module to be integrated independently.

                                                           iv.      Geert – OpenStack is impressive, but it took 6-7 years with thousands of developers to develop. MicroServices comes at a cost, not sure if it is justified.

                                                             v.      Dave – Wants to discuss platform versus point-to-point integration more. He prefers platform versus MicroServices, because it will be more costly to define all individual p2p interfaces.

                                                           vi.      DengHui – Some existing code such as Aria needs to be integrated within this year, it cannot work with a platform that is based on another language.

                                                          vii.      Geert – ManageIQ has advantages over Aria. ManageIQ has broader functionality, except for the TOSCA parser. Using multiple languages may not be the fastest way to build a community.

                                                        viii.      Its service model may currently not be ideal but it has a good service catalogue

                                                           ix.      Deng Lingli – ManageIQ is a Cloud Manager, it has major (functional) gaps as an orchestrator. How much effort is needed to use ManageIQ as NFV-O? What effort is needed to fill the gaps?

                                                             x.      Geert – ManageIQ is a generic manager, not just a Cloud Manager. ManageIQ is not ready for use as NFV-O, but the platform provides most of the primitives.

                                                           xi.      ManageIQ has many re-usable components, activation engine, governance, federation, data model, and SDN.

                                                          xii.      The platform can be easily changed to fill any gaps for OPEN-O

                                                        xiii.      Geert – The ManageIQ core team will not be able to attend the Beijing meeting. Please do not make any decisions until you have seen our OPNFV demo.

                                                        xiv.      DengHui – RedHat should propose which module could be used. Red Hat can propose something for the platform driven approach.

                                                         xv.      The ManageIQ issues will be discussed by email. We can discuss more next week in Beijing.

                                                        xvi.      Chris – No decisions will be made at the Beijing meeting. Decisions cannot be made until June when TSC is formed. Meanwhile we can just make suggestions.

 

 

6.       MEF LSO Reference Architecture

a.       Andy Mayer, as a guest participant from a partner project, presented MEF LSO Reference Architecture. His presentation covered the following points:

                                                               i.      History of MEF Lifecycle Service Orchestration Reference Architecture

                                                             ii.      Definition of LSO and LSO RA

                                                            iii.      Drivers-on-Demand and Agile Services

                                                           iv.      Definition of Orchestration

                                                             v.      MEF Engineering Methodology

                                                           vi.      LSO-related MEF activities

                                                          vii.      LSO Reference Architecture

                                                        viii.      LSO Operational Threads

                                                           ix.      LSO Management view abstractions

                                                             x.      Examples of data transferred on each interface

                                                           xi.      LSO example with SDN and NFV

                                                          xii.      LSO RA phase 2 plans

b.      The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Uri – Which requirements are imposed on controllers by Presto?

                                                             ii.      Andy – We are working with ONF on Presto requirements for Service Chaining. Phase 2 will investigate more use cases and interactions.

                                                            iii.      Amir – GigaSpaces has already demonstrated at the LSO Hackathon the Legato and Presto interfaces using TOSCA. (Demonstrated Legato API using Tosca).

                                                           iv.      Uri – Is the Presto interface defined? How MEF addresses SDN-O and NFV-O – Presto + network functions and network services? There are still discussions whether Service Orchestration goes directly to VNFM or NFVO?

                                                             v.      Andy – An early draft is available.

                                                           vi.      Uri – Has LSO been adopted by any BSS groups?

                                                          vii.      Andy – We are working with open source communities.

                                                        viii.      Olga – Has MEF discussed Presto with ETSI NFV? The question is about Legato vs. ETSI API.

                                                           ix.      Andy – We have been working with ETSI NFV (still work in progress). We hope to develop use cases with ETSI.

7.       Seed Code Meeting Presentation

a.       Chris presented the Seed Code meeting charts, covering the following points:

                                                               i.      Workshop goals

                                                             ii.      Agenda

                                                            iii.      Architecture Map

                                                           iv.      Potential metrics

b.      Chris – We should add 2 new metrics. Ability to deliver this year, and effort needed to fill gaps.

c.       Marc – I have discussed the metrics with Phil Robb from OpenDaylight. Phil can share his expertise.

d.      Phil – The current list looks good. Contributors who have overlaps should discuss differences in functionality and differences in approach. Phil will join us next week in Beijing, he has experience in ODL.

e.      Phil – proposed that those who have multiple seed code contributions to have joint meetings to understand and assess each other’s proposals, overlaps and gaps

f.        Lingli – presented arrangements for the meeting in Beijing. It is important to register at the North gate on the first day.

g.       Geert – The ManageIQ core team will not be able to attend the Beijing meeting next week.

h.      The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Uri – We need a high-level description of the functionality and the APIs.

                                                             ii.      Chris – We will have sessions in Beijing for detailed discussions.

                                                            iii.      Uri – We need basic definitions of each component. For the proposed functionality and APIs, we need the description and requirements for the OPEN-O blocks, so that we can match OPEN-O requirements to APIs and provided functionality of the contributions

                                                           iv.      Deng Lingli – Each contributor should answer the above questions during their presentation.

                                                             v.      Chris – Each contributor should address all of these metrics.

                                                           vi.      Deng Lingli – We should add a metric for compliance to standards such as ETSI or MEF.

                                                          vii.      Uri – MEF will not be relevant outside SDN.

                                                        viii.      Chris – We can use the email list to discuss which standards may be relevant.

                                                           ix.      Corona Wei or Fengjie – Made some comments about MEF and will share her ideas by email

                                                             x.      Uri – Functionality in each block is still unclear.

                                                           xi.      Dave – It may be good to have a “bake-off” where sample use cases are used to evaluate each contribution.

 

 

Action Items:

8.       Forward the MEF LSO slides to the email list. (Chris D)

9.       Share the current Presto draft. (Andy M)

10.   Send a list of confirmed attendees for next week’s face-to-face meeting in Beijing (Lingli Deng)

11.   Red Hat will not be able to attend Beijing meeting, but they will try to communicate through presentations (Uri E)

12.   Share the slides for the section on “Seed Code Meeting” (Chris D)

13.   Add best practices for code selection (Mark C)

 

Regards,

 

Cas

 

From: Casem Majd
Sent: Thursday, May 05, 2016 2:56 PM
To: Casem Majd; open-o-technical-formation@...; Christopher Donley (Chris); Michael McBride
Cc: Marc Cohn; Casem Majd
Subject: RE: OPEN-O Architecture Meeting Notes

 

All,

Please find below the notes for this week’s OPEN-O Architecture Meeting. Thanks to Dave again for his help.

 

Meeting Venue:  The OPEN-O Architecture Meeting Conference Call took place on Wednesday May 4th, 2016. Meeting started at 6:30am and ended at 7:30am PST. 23 people from 8 organizations participated.

 

Summary:

8.       Review conference participation/feedback (ETSI NFV, OpenStack, MEF, etc.)

                                                   i.      We had an event report from the face-to-face last week at OpenStack Summit

                                                 ii.      Report on ETSI NFV meeting

                                                iii.      Report from MEF

b.      ETSI NFV Update

                                                   i.      Marc C from Linux Foundation mentioned that they had been invited to meet with the ETSI NFV MANO group this week in Atlanta to talk about possible collaboration.

                                                 ii.      ETSI NFV panel went well, which opens the door to further cooperation.

1.       Chris and Marc presented Open-O at the ~150 members ETSI panel (special session on open source orchestration, where OPEN-O and OSM were showcased in a single session)

2.       Additionally, we participated in a panel discussion

                                                iii.      Amir Levy from GigaSpaces presented ARIA hierarchical model-driven orchestrator (TOSCA/YANG). 

                                               iv.      OSM team also presented their story.

                                                 v.      Questions from the ETSI participants around how we plan to use their specs and common information/data models/VNFs.

1.       ETSI is particularly interested in OPEN-O converging on a common Information Model with OSM, and compliance with the ETSI NFV Architectural Framework.

2.       ETSI wants us to provide ETSI NFV IFA-compliant interfaces

                                               vi.      Also questions about participating in standards versus open source.

                                              vii.      Discussed the possibility of convening an OPEN-O/OPNFV/OSM session at the OPNFV Summit in June. ETSI also offered to share a tutorial on the ETSI IFA-defined interfaces.

                                            viii.      AT&T also presented ECOMP earlier in the week.  Marc said that they were hinting that they’re working on an open source strategy, but it didn’t sound like a separate community. They are asking a lot of questions about Open-O. We need to keep engaging with them.

c.       MEF Forum Update

                                                   i.      Brendan H talked about the interest for Open-O that he had encountered at the MEF forum.

                                                 ii.      SDN-O integration is important for the MEF use-cases.

                                                iii.      MEF forum asked a lot of questions about Open-O.

                                               iv.      We will invite MEF to present to the OPEN-O architecture team in May

 

9.       Work Plan

a.       Marc reviewed the plan for the next few weeks. 

b.      Marc is refining the spreadsheet, and will send an update this week.

c.       Several companies announced intention to participate in the face-to-face in Beijing: Intel, Huawei, ZTE, China Mobile, China Telecom, GigaSpaces (maybe others).

d.      Parties are asked to send the seed code map to Chris by 5/10

e.      Parties are asked to register for the event by 5/10

f.        Parties are asked to notify Marc if they are planning to join Open-O, and at what level (even prior to formally signing the membership document). We need to start planning launch activities.

10.   Architecture

a.       HA is put in the “Common Service” box and not the “O-common” box, HA is a common requirement for all the components inside OPEN-O, not only those inside the orchestration layer.

b.      Uri asked about EMS/OSS/BSS interfaces.  Deng Hui referred him to the YouTube video of our OpenStack talk.  We will discuss on a future call.

11.   Discussed preparations for the May 17-19 meeting

a.       Reported on seed code release progress and planning for face-to-face meeting in Beijing

b.      Who is bringing seed code

c.       What are the expectations for companies bringing seed code

d.      Question raised whether there were guidelines on meritocracy of operation

e.      Some organizations feel it is important to understand the meritocracy before the meeting, to inform the discussion and decision process.

12.   Red Hat ManafeIQ Presentation

a.       For the last 15 minutes, Red Hat (Geert Jansen) presented ManageIQ.

b.      Red Hat proposes that ManageIQ

c.       Red Had open sourced this code base in 2014.

d.      Code base started in 2006 and uses the Apace 2.0 license. Code is written in Ruby on Rails.

e.      It is a service catalog for on boarding of VNF

f.        Provisions the VNF via standard provisioning workflows

g.       Support of VNF lifecycle management via service models

h.      Provides event-driven automation via control

i.         Supports delegated control via service model

j.        We did not have a lot of time for questions, but there were a number of people who said that they wanted to follow up with questions.

k.       Agreed to continue the discussion via email.

 

Action Items:

14.   Parties are asked to send the seed code map to Chris by 5/10

15.   Parties are asked to register for the event by 5/10

16.   Parties are asked to notify Marc if they are planning to join Open-O, and at what level

17.   Invite MEF to present at the OPEN-O architecture team in May

 

Regards,

 

Cas

 

From: Casem Majd
Sent: Monday, May 02, 2016 5:36 PM
To: Casem Majd; open-o-technical-formation@...; Christopher Donley (Chris); Michael McBride
Cc: Marc Cohn
Subject: RE: OPEN-O Architecture Meeting Notes

 

All,

Please find below my notes for this week’s OPEN-O Architecture Meeting. Thanks to Dave Neary for his valuable contributions to this week’s meeting notes.

 

Meeting Venue:  The OPEN-O face-to-face Architecture Meeting took place in Austin, TX at the end of the OpenStack Summit on Friday April 29th, 2016. Meeting started at 9:00am and ended at 3:00pm. 18 people from 9 organizations participated.

 

Summary:

1.       Sivan and Arthur B from GigaSpaces presented a tiered or hierarchical service model proposal

a.       The proposed hierarchical model consists of two levels of abstractions

b.      TOSCA is used for the end-to-end service abstraction, with extension nodes that contain YANG models, which are used for the network and device abstraction.

                                                               i.      TOSCA extensions capabilities are used to add new node types and develop a common composite model made from TOSCA, YANG, and other plug-ins

                                                             ii.      The top-level abstraction describes what is needed for the service, and the lower-level abstraction specifies the implementation details of each network component (e.g. YANG models for ODL or ONOS network domains)

                                                            iii.      The model is used to create functions out of building blocks and chain those functions to create services.

                                                           iv.      One example presented: Modeling DNS - node type Bind9, with some connected resources (such as a GW FW, security groups) - some of which are external to the VNF

                                                             v.      The example demonstrates TOSCA as a description language, including its extensibility

                                                           vi.      Relationship between YANG and TOSCA? Sometimes some things are better expressed with YANG, and the proposed solution (ARIA) has a possibility to wrap these pieces in TOSCA to orchestrate

c.       The model covers the service lifecycle, from installation, provisioning, configuration and deployment through monitoring of the application or service in order for the system to take reactive or proactive actions, such as healing and scaling based on custom triggers, or other actions to be performed as part of a lifecycle.

d.      The models come with policy and workflow components. Pre-defined events are specified in the policy templates for certain conditions or threshold violations. The policy defines which events to track, what threshold conditions to watch for, and what corrective actions to take in case of violation of those thresholds. Examples are scale-out based on pre-set capacity utilization thresholds.

                                                               i.      Separation of policy, workflow, and execution/event handling

                                                             ii.      The policy templates specify when to react,

(Policy: If event, then mitigation (start a mitigating workflow))

                                                            iii.      The ensuing workflow specifies the sequence of actions (what to do) to perform in case the policy is violated, and

(Workflow: Actions to be executed - potentially more than one - to apply policy)

                                                           iv.      The implementation logic specifies how to react

(Execution: Event triggers policy execution, which runs through workflow)

e.      The solution would consist of a model parser and an execution engine.

                                                               i.      ARIA is a TOSCA parser and orchestrator. Every time a new node type is added, the parser needs to be aware of them, and validate them.

                                                             ii.      Q: Is it better to have a separation of parser and orchestrator? R: Opinion is that parser and orchestrator are related - similar to UI and model, hard to write a UI without awareness of underlying model

                                                            iii.      Perhaps runtime binding of an alternative orchestrator would be possible

                                                           iv.      Extensive discussion about whether it makes sense to have the parser tied to one orchestrator, and how separation would be possible

                                                             v.      ARIA is open source, and there is a desire of GigaSpaces to have multiple vendors collaborate on it - extension and collaboration could happen in ARIA

f.        The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Need to plug-in to ETSI, and try to define common models that align with ETSI

                                                             ii.      What is the relationship with ETSI NFV MANO? Will there be a common model with the industry? We should align with what is being used in OSM for the information model to converge on an industry norm (best effort attempt).

                                                            iii.      How and to what extend would the proposed models support the complete lifecycle of the service, including model-driven service assurance and inventory schema (allowing new inventory item types to be added dynamically based on models).

                                                           iv.      Is a tiered model necessary for service modeling? Doesn’t it introduce unnecessary complexity? The relevance of the model should be demonstrated with the vCPE use case implementation, and show what was extensions were made to the standard TOSCA or YANG.

2.       Olga H from Huawei reviewed the OPEN-O functional architecture

a.       The team reached consensus on the existing OPEN-O architecture. Minor modifications were made to the architecture diagram, e.g.,

                                                               i.      Adding HA function to the O-Common,

                                                             ii.      Adding EMS/NMS driver to the southbound

b.      Separation of some common services unrelated to Orchestration use-cases (logs, workflow, message bus, etc) and common services with orchestration focus (template management, lifecycle management framework, model driven framework). The main components of the architecture are:

                                                               i.      Common Services, which consist of generic applications that are independent of orchestration. These are system-wide functions.

                                                             ii.      O-Common, which consists of orchestration specific services and functions

                                                            iii.      SDN-O, which provides abstraction for masking network complexities.

                                                           iv.      NFV-O, which models VNFs and applications. It would preferably be aligned with ETSI models.

                                                             v.      What about intent? - intent parsing needs to be in global service orchestration, but also for rendering intents, southbound of SDN-O for the SDN controllers. Consensus is that both SBI and NBI will support intent.

                                                           vi.      As presented, separation of driver layer for different VIMs, SDN controllers, VNFM drivers, which are independent of the model design and resource management layers.

c.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      It is not clear if the software architecture (and its corresponding data model architecture) is aligned with the OPEN-O architecture diagram. This needs more discussion.

                                                             ii.      There is a concern of having to deal with too many modules and too many interface points between them, which would slow us down! Is there a generic VNFM interface?

                                                            iii.      Relationship with Tacker, OPNFV, etc?

                                                           iv.      Using standard open source components for common services, even if there is not a vendor at the table.

3.       The team discussed one open architectural item – HA

a.       How to provide HA? Should it be a platform function or a module-specific function?

b.      We agreed that it belonged as a common function, and updated the architecture diagram accordingly (adding HA to O-Common)

c.       Support of HA would not be within the scope of release 1.

d.      The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Open-O is going to implement Micro-Service architecture

                                                             ii.      HA and scalability should be common requirement for each micro-service (Perhaps on O-Common - HA service?)

                                                            iii.      HA as a common requirement has the potential consequence that the modules may have to be stateless. More work needs to be done to clarify.

 

4.       The participation at OPNFV Summit has been discussed

a.       China Mobile offers their booth space at the OPNFV Summit in Berlin for free to host the Open-O demos

                                                               i.      There will be a small/narrow space, with 2 demo spaces

                                                             ii.      So far, there are six demos prepared and proposed by different vendors (Red Hat, ZTE, etc.)

                                                            iii.      Intention is to cast the demos into a broader and more consistent story that highlight the main OPEN-O capabilities. It should not be a scattered set of demos. They all should tell a consistent end-to-end storyline.

b.      OPEN-O will be presented at OPNFV for the first time under its own name as an independent entity, and not through any specific organization.

                                                               i.      China Mobile / Huawei will be doing a joint presentation.

c.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Need to finalize the OPNFV demos during the next face-to-face meeting in May 2016.

5.       Discussion on Seed Code contributions

a.       Vibrant discussion on who plans to bring seed code to the May meeting:

                                                               i.      Organizations will be invited to contribute seed code. So that we can make most effective use of the face-to-face, every party will fill up a map that shows to what module it intends to contribute code?

                                                             ii.      Expression of intent for contributing seed code is currently not binding. Partner organizations can declare their intents for contributing code without any concerns about legal obligations. As long as TSC has not been formed, no decision will be made on what code to include and what to exclude to/from the base code.

                                                            iii.      It is preferred for organizations to come to the meeting with open source code. However, if organizations intend to submit open source seed code, but have not cleared their code yet, they may just make presentations at the next meeting in order to avoid legal complications. Organizations should not disclose their code if they don’t have the required open-sourcing approvals.

                                                           iv.      Requirement to open source code in advance of the OPNFV Summit hackfest, but not necessarily in advance of the meeting in Beijing. Marc Cohn confirms that we will not be doing any NDAs or similar - if code is not open sourced, then only publicly available information can be presented.

                                                             v.      Bringing code does not guarantee that the code will be included

                                                           vi.      The team will define the criteria and the meritocracy rules for accepting or rejecting code contributions to the code base. Linux Foundation will share its current Best Practices to all participating organizations. The team will make a group decision based on suggested best practices.

1.       The decision criteria for how seed code will be chosen will be documented before the meeting

b.      Proposed process for consolidating code:

                                                               i.      We will send the detailed architecture diagram to participating organizations and ask how their intended seed code contribution would fit into the OPEN-O module landscape.

                                                             ii.      Organizations will fill up a map that shows to what module they intent to contribute code to.

                                                            iii.      We will create a consolidated mapping table that maps each contributing code to each functional architecture block and identify a leader for each category

                                                           iv.      The goal of this planning is to gather expressions of interest to bring code to the table.

1.       The intent to participate - with an understanding that things will evolve, as we start to work on it, and refine functional block definitions.

                                                             v.      In May, we will discuss, with a level playing field, which components will be part of the initial release

                                                           vi.      The TSC, after formation, will own and validate the architecture and project operation - the architecture discussion group provides input into that discussion

                                                          vii.      Participation will be open - it is possible that people who have not been involved in the formation discussions will participate

                                                        viii.      If people express an intent to join, they can participate in the mailing list and May meeting.

c.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Question whether seed code must be open source? All seed code must be open source before the launch.

 

6.       Preparation for next face-to-face meeting in China from May 17th to May 19th 2016

a.       The review and consolidation of the contributing seed codes is the main objectives of the next face-to-face meeting in May 2016.

                                                               i.      The next face-to-face meeting to be held at China Mobile facilities in Beijing, China from May 17th to May 19th 2016.

                                                             ii.      Place: Meeting Room 908, Level 9th, China Mobile Research Institute, Beijing, China

b.      We will wait to see what code contributions we will receive and then decide how to organize the meeting (structure, number of sessions, mission for each session, etc.)

                                                               i.      The current consensus is to start with an end-to-end architecture session, followed by a set of parallel module-specific code review sessions.

1.       Day 1: Presentation of seed code

2.       Day 2: How we operate as a community, how meritocratic decision making works, and how we make seed code easier to consume

3.       Day 3: Convergence on who will participate in the project at which functional blocks, scope and goals for 1st release

                                                             ii.      There are concerns about

1.       How to coordinate the work between overlapping SDN-O and NFV-O tracks?

2.       How to take the results and consolidate them? How to take and consolidate meeting notes?

                                                            iii.      The final agenda for the May meeting is moved to the mailing list

c.       The goals of the May meeting are:

                                                               i.      Companies participating will have an opportunity to present their seed code, show how they fit into the architecture, and demo their projects

                                                             ii.      Review contributing codes, assess how contributions fit together

                                                            iii.      We will try to resolve conflicts between code which is functionally overlapping

                                                           iv.      Define a realistic scope for release 1

                                                             v.      Create a project plan for TSC

                                                           vi.      Partners should come to the meeting with their USB keys and code.

d.      Before the meeting, create a consolidated mapping table that shows how each contributing code maps to one of the following functional blocks of the architecture and identify a leader for each category:

                                                               i.      SDN-O and its drivers

                                                             ii.      NFV-O and its drivers

                                                            iii.      GS-O

                                                           iv.      Tools / Commons

                                                             v.      We will identify track leaders before the May meeting for break-out sessions on each of the main functional blocks.

e.      The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      There are certain visa and travel restriction concerns

                                                             ii.      It is understood that the meeting is short notice for some participants. However, the meeting should not be later - because of time pressure for OPNFV.

                                                            iii.      Concern expressed that if we start with a broad and ambitious scope, we will have trouble converging to a first release. We do not want to lock in a plan in May before we have a technical community created and working together. We may be able to start working on seeding project plans in the May meeting, even if it will take a few weeks to get a TSC.

                                                           iv.      Is there a separate track on architecture, planning, components? Someone needs to keep the overall view/big picture in mind

 

7.       Mark C presented the plan of work for the next 3 months

a.       Major milestones were presented

b.      The plan will be distributed next week

c.       Companies to introduce representatives for various committees (TSC, etc.)

d.      Launch planned for June 1st

e.      First Board Meeting in June

f.        First code release for end of year

 

Action Items:

18.   Provide a concrete example (preferable vCPE use case) that shows the need for a 2-level abstraction model (TOSCA-YANG). Show how and why the proposed hierarchical model is superior. And preferably layout the details of a use cases that would benefit from hierarchical TOSCA/YANG models. (GigaSpaces, Arthus B)

19.   Continue the discussion via mailing list on how the proposed model would support complete lifecycle for model-driven service assurance and inventory (Arthus B, Olga H)

20.   Show how to map the proposed models to the OPEN-O architecture diagram (GigaSpaces, Arthur B)

21.   Show more specifically a SBI for legacy EMS/NMS by adding an EMS/NMS driver to the architecture diagram. (Olga H)

22.   Update OPEN-O architecture diagram to include HA function in O-Common box (Chris D)

23.   Identify who in the industry has tools or applications that would fall within the scope of OPEN-O Common Services. The search should also include those companies that are currently not involved in OPEN-O. (Dave N)

24.   Send the detailed architecture diagram to participating organizations to see how their intended seed code contributions would fit into the OPEN-O module landscape. Organizations will fill up a map that shows to what module they intent to contribute code to? (Chris D)

25.   Coordinate the activity for creating a consolidated mapping table that maps each contributing code to each functional architecture blocks and identify a leader for each category; Emails to be sent out by May 3rd for collecting information. Mapping table to be created by May 10th.  (Mark C; Chris D)

26.   In order to define the criteria and the meritocracy rules for accepting or rejecting code contributions to the code base, Linux Foundation will share its current Best Practices by May 5th. Post it on Etherpad. (Mark C)

27.   Organize OPEN-O activities (demos, presentations, etc.) related to OPNFV summit in Berlin. Consolidate the six OPNFV demos into common groups such that they fit into a broader storyline and better highlight core OPEN-O capabilities. Every demo will be mapped to a supporting organization. Create a game plan for the OPNFV demos. (Deng Hui)

28.   Organize the logistics of the next face-to-face meeting in China. List of attendees. Who does what? Define when and where we will meet? (Deng Hui)

29.   Send out instructions on logistics of the May meeting, what to bring to the meeting, rules, etc. (Mark C, Chris D)

1.       Participant to send their information (name, email, phone, and food preferences) to China Mobile

2.       Participants to bring their passport to the meeting. Passport registration is required at China Mobile

3.       Participant to bring their USB keys with code

4.       Organizations to bring their developer experts to the meeting that can present code.

30.   Incorporate latest feedback/corrections to the whitepaper, add a paragraph about how to interact with OSS/BSS, and release the 5th version of the Whitepaper to Linux Foundation for final editing and publication. Each company has to provide an author name for the whitepaper. (Cas M; Harshad T; Deng Hui)

31.   Invite MEF to make an LSO presentation at one of our OPEN-O architecture meetings. Focus on describing what is LSO and how does it relate to OPEN-O? (Chris D)

 

Regards,

 

Cas

 

From: Casem Majd
Sent: Thursday, April 21, 2016 10:48 AM
To: open-o-technical-formation@...; Christopher Donley (Chris)
Cc: Casem Majd; Marc Cohn
Subject: OPEN-O Architecture Meeting Notes

 

All,

Please find below the notes for this week’s OPEN-O Architecture Meeting.

 

Meeting Venue: OPEN-O Architecture Conference Call on Wednesday April 20th, 2016

 

Summary:

1.       Marc Cohn went through the current launch details.  The charter and membership agreement have been sent out for review. Prospective members must return signed documents by June 1 to be considered founders.  The launch date will be June 1.

2.       Plan of work:

a.       Chris, Marc, and Chengli will create a (2-3 month) plan document for pre-launch activities, which will encompass the timeline and ownership of the following milestones, formation documents, tasks, and launch items;

                                                               i.      Official launch

                                                             ii.      Founding Member review and

                                                            iii.      User Advisory Group

                                                           iv.      Targeted recruitment

                                                             v.      Design and sign-off of a Logo

                                                           vi.      Design and launch of the Web site

                                                          vii.      Brief and white paper publication

                                                        viii.      Target architecture

                                                           ix.      Coordinated release of seed code

b.      The 2-page Brief is a pre-formation document, not an official document. LF to be the official author to make its publication easier.

c.       LF compiled draft of Formation Committee and Membership Agreement; Date of joining is early May, which is moved to June 1st so that additional members can sign up.

                                                               i.      Membership Agreements have been sent out to some

                                                             ii.      Founding Members to be formed

d.      LF to issue PR with Founding Members later in May. Being reviewed and collecting executive quotes form member organizations.

e.      User Advisory Group has to be formed before official formation (End User Group?)

3.       Release of seed code

a.       Huawei seed code going through final internal approval and should be released to git in mid May (quietly). It will be publicly announced in June, coordinated with other partners. The seed code is currently available for review under NDA

b.      China Mobile also will release seed code; Date not confirmed!

c.       China Mobile suggests having an informal 2-3 days of seed code review in mid May in China. The topic will be taken to mailing list to gain critical mass and finalize time and location.

4.       Plan to finalize the target architecture and use cases (cloud VPN and model stacks) at the face-to-face meeting in Austin, TX

5.       OPEN-O Whitepaper:

a.       The current 4th version of the whitepaper to be sent out for review on 4/20.

b.      Whitepaper will be handed off to Marc for final editorial review.  Publication will be timed to support the Open-O launch (target- Mid-May).

c.       Publication of the whitepaper will be put up after signing of Joining Agreement and formation of Founding Members.

d.      The final version will include Founding Members’ names as contributors.

6.       The following module names were agreed for OPEN-O: GS-O (Global Service Orchestrator); SDN-O; and NFV-O. The name NFV-O is maintained to show alignment with ETSI.

7.       Olga had a short discussion on the model stack.

a.       China Telecom to add a SDN controller for the enterprise in the Cloud VPN use case

b.      Open questions:

                                                               i.      Which module decides on VNFs: the NFV-O or the GS-O?

                                                             ii.      Which module owns SFC: the SDN-O or the NFV-O?

c.       China Telecom will send more details on underlay versus overlay connectivity and their orchestration

d.      Use cases to be finalized at next week’s architecture meeting. The discussion to be continued via mailing list.

8.       Members were asked to provide feedback on the agenda of next week’s face-to-face meeting. The agenda is on Etherpath. https://openo-arch.titanpad.com/4

 

 

Action Items:

32.  Chris, Marc, and Chengli will create a plan document for the next three months.

33.  Incorporate community feedback and release the 5th version of the White Paper by mid May.

34.  Define the when and where of 2-3 days long seed code review meeting (mailing list)

35.  Gigaspaces will present on data modeling at the face-to-face meeting

36.  China Telecom use case to be finalized by 4/29.

37.  Each company to provide an author name for the whitepaper

38.  Qiong Sun to send specific details on the Cloud VPN use case for the whitepaper

39.  Next week’s face-to-face meeting will be in Austin, TX (at OpenStack Summit) on Friday 4/29

 

 

Regards,

 

Cas

 


Lingli Deng <denglingli@...>
 

Hi Cas,

 

Thanks for taking the notes.

 

Chris, I volunteer working on the project life cycle document draft for further TSC discussion.

 

Thanks and Regards,

Lingli

 

From: open-o-technical-formation@... [mailto:open-o-technical-formation@...] On Behalf Of Casem Majd
Sent: 2016
615 10:37
To: Casem Majd <cas.majd@...>; open-o-technical-formation@...; Christopher Donley (Chris) <Christopher.Donley@...>; Michael McBride <Michael.McBride@...>; openo-tsc@...; openo-discuss@...
Cc: Marc Cohn <mcohn@...>
Subject: RE: OPEN-O Architecture Meeting Notes

 

All,

Please find below the notes for this week’s OPEN-O TSC Meeting. Note that starting this week, the Technical Steering Committee (TSC) and the Architecture Committee (ARC) conduct separate meetings, on Tuesdays and Wednesdays respectively. This is the report for the TSC meeting.

 

TSC Meeting Venue:  The OPEN-O TSC Meeting Conference Call took place on Tuesday June 14th, 2016 from 7:00am to 8:00am PST. 30 people from 7 organizations participated.

 

Summary:

1.       Chris D. gave a summary report on last week’s achievements, reviewed open items (Uri’s email), gave a walk-through the Wiki tools, and discussed the process for developing governance and policy documents.

a.       Charter has been approved and is posted on Wiki. The Charter governs our behavior as the TSC, defines officers and describes the organizational structure.

b.       Elections held with following results:

                                                               i.      Chris Donley was elected at Chair of the TSC.

                                                             ii.      Uri Elzur as the Chair of Architecture Committee group and Vice Chair of the TSC.

                                                           iii.      Voted to open the TSC meetings to everyone in community with the exception of executive sessions, which will be made know in advance.

                                                           iv.      The TSC members may delegate alternatives in case the voting TSC member cannot attend

c.       Release Plan discussed and posted on Wiki

                                                               i.      Targeting release end of 2016

                                                             ii.      Internal release date set for Nov 3rd; this date will not be publicized externally. We are looking for additional feedback from board on both the release plan and the use case. So the release date may change in near future.

d.       Four projects proposal have been approved. There were open items on each project proposal. Uri has been documenting those open items in an email.

                                                               i.      NFV-O

                                                             ii.      SDN-O

                                                           iii.      GS-O

                                                           iv.      Common Service

                                                             v.      Two additional project proposals are in the pipeline that will be reviewed in coming weeks when we do the planning process through the remainder of this month.

e.       SLACK tool is a conferencing note taking for the community. People feel free to take notes and conduct discussions on the SLACK.

                                                               i.      Link for SLACK: open-o-tsc.slack.com

f.        Gildas Lanilis was introduced as the OPEN-O Release Manager. 15+ years of experience in telco software development.

g.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Some participants could not join the GoToMeeting meeting due to cap on number of people that can participate. Volunteers were asked to drop off.

                                                             ii.      The team has been borrowing OPNFV tools so far. Linux Foundation will be asked this week to come up with resolution. The group will need a larger conference bridge.

                                                           iii.      All content of the presentations is put on the Wilki.

                                                           iv.      What template to use for the project planning? Please continue using the existing project proposal PowerPoint templates that we have used last week and at our Seed Code meeting. It is posted on the Wiki this week. The Project Lifecycle Document still needs to be written. A rough outline of the release plan is on the Wiki.

                                                             v.      Can we use the ODL template for project planning? OPEN-O projects have slight differences in the information that we need compared to ODL. There are a couple of additional questions related to the architecture that we would like to cover in our project plans. So, please use our existing project plans.

                                                           vi.      To make best use of our time during the planning phase, in tomorrow’s architecture call we will continue to review project proposals and talk about OPNFV MANO project (draft slides available)

2.       Uri E. gave a walk-through some of the open items from last week.

a.       The review is structured in two sections with three types of comments:

                                                               i.      Brief commentary, which project owners/participants need to take a look at and comment

                                                             ii.      Decisions (very few)

                                                           iii.      Open issues where actions are needed (this is the largest category)

b.       Decisions that we agreed are:

                                                               i.      Readjust each proposal’s scope depending on how the whole project comes together.  Coordinate adjustments between different proposals.

                                                             ii.      Creating a long term architecture proposed in parallel (not gating) that will include reference to areas that are out of scope so that we have at least a discussion on how they relate to or impact our projects (examples are OSS/BSS, migration issues, etc.)

                                                           iii.      Each project and the main project will have a document about the “problem being solved”. So that we have the same for the whole OPEN-O project and each sub-project. The individual projects may have to adjust according to the overall problem being solved.

                                                           iv.      For release 1, the drivers are separate will be integrated into respective project of NFVO and SDN-O.

c.       Questions:

                                                               i.      NFV-O was the first sub-project reviewed. But at the same time, this helps address many questions related to the Open-O wide project as well.

                                                             ii.      Started commenting slide-by-slide on Lingli’s project proposal on NFV-O, so that we make sure we are all on the same page and can finalize the project proposal.

                                                           iii.      First Question: Slide# 3 makes a general reference to NS. The O-Commons project also refers to VNF on-boarding. There is also a reference to on-boarding during the design phase.

1.       Question: Are we talking about NS of NFV or are we talking about NS of pNFV, vNFV and the corresponding VNFFG, etc.?

a.       Answer: NFV-O is responsible only for VNF Network Service. The E2E NS that includes VNF and legacy devices, it is to GS-O to do E2E orchestration. 

2.       Question: What do you expect to get? Do you expect to get NSD?

a.       Answer: NFV-O supports 5 different lifecycle management operations (CRUD Operations). Each operation we expect to receive different things. The first operation step is about NS template design. For input to the design you may need software image and a package of NSD, VNFD, VNFFG and other artifacts.

d.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Not all TSC members had received Uri’s email and were not ready to really participate in the discussion.

                                                             ii.      Uri’s email and review was too lengthy to be covered in the TSC meeting. People will review and respond via email. Discussions will follow in smaller teams and continued in the larger TSC meeting only if it concerns the larger end-to-end solution.

                                                           iii.      From the Common TOSCA perspective, there are many integration points between the components. We need to do joint engineering work and shared design to ensure that all touch points and overlaps are covered. Joint design would facilitate proper project planning.

                                                           iv.      We should work on this offline through Wiki, email, SLACK, and other tools. We should work off-line asynchronously. Wiki would be a better choice for this discussion to capture all the documentation. SLACK is more for online discussions. The content on SLACK needs to be copied over to the Wiki.

                                                             v.      Will have follow up design session between various groups. Should each group have these discussions separately? If the integration point is just between two teams, feel free to do it in a smaller group. If it relates the overall project, then bring it to the TSC. Try to make progress over email and if email is not enough, we will have smaller group meetings.

3.       Chris D. gave a walk-through the Wiki pages.

a.       Link is: https://wiki.open-o.org. It is still under development. Use it for new project proposals, for discussions, for alignment between projects, and to share information between different people.

b.       Starting to populate things. The conf bridge info is in the “Meeting Times”.

c.       Release Plan currently just has the milestones. It should become similar to ODL sites, containing much more details.

d.       Kick-off Meeting Outcome contains the resolutions from last week.

e.       Approved Project Page is not populated yet. As we move forward and have more artifacts, we can have individual pages for each project. Those would be pages similar to what Uri created.

f.        The TSC Governance Document page contains the TSC Charter v6 that is approved. This has pdf and full Wiki version.

g.       TSC Policies. We have not reached consensus on yet. Will send out emails this week to the board members to reach consensus.

h.       Project Lifecycle Documents has not been started yet. It will be similar to OPNFV and ODL. ODL defines 4 steps and OPNFV defines 5 steps. We will start with 4 and expand as needed. Volunteers are needed to work on the document.

i.         The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Currently the Wiki registration uses Google services. It will cause problems for people in China

                                                             ii.      Somebody outside of China can do the registration work for people in China. If people in China have problem, first reach out to people from your company outside china. If it does not help, then reach out to Chris for help.

                                                           iii.      Meeting notes shall go to the Wiki as well. There will be a page for TSC meeting and a page for notes by date. People prefer to use Wiki for meeting notes and slack for common discussions.

                                                           iv.      Put project proposal on the Wiki. Feel free to use the Approved Projects page for release plans.

                                                             v.      There is a bottom for watching important pages. Intent to use our calls for the next few weeks for the project proposals and do the document related work through the email list.

                                                           vi.      The self-service link for the mailing list sign up is: http://lists.open-o.org/mailman/listinfo

                                                          vii.      Will add a link to the Wiki for the mailing list sign up.

 

 

1.       Action Items:

a.     Everybody is asked to make sure that their name is added to the TSC and ARC mailing lists. Link is: open-o-technical-formation@...

b.       Everybody to review Uri’s email and provide comments/answers to finalize the project planning

c.       Everybody to familiarize with the Wiki and TSC document

d.       Volunteers are needed to work on the Project lifecycle Document

 

 

 

From: Casem Majd
Sent: Wednesday, June 01, 2016 10:58 PM
To: Casem Majd; open-o-technical-formation@...; Christopher Donley (Chris); Michael McBride
Cc: Marc Cohn
Subject: RE: OPEN-O Architecture Meeting Notes

 

All,

Please find below the notes for this week’s OPEN-O Architecture Meeting.

 

Meeting Venue:  The OPEN-O Architecture Meeting Conference Call took place on Wednesday June 1th, 2016 from 6:30am to 7:55am PST. 27 people from 10 organizations participated.

 

Summary:

1.       Olga presented Four Service Modeling Roles needed for supporting OPEN-O Use Cases. This was a summary report of the Beijing meeting.

a.       Outline of the talk:

                                                               i.      Defined the role of four different “Service Designers” for various layers of OPEN-O service stack; defined the relevant terminology, defined the ownership of descriptors for each layer, and defined the proper abstraction for each layer.

                                                             ii.      Defined the service design use case

b.       Role #1) GS-O Global “Service Designer”

                                                               i.      This is the top most service designer with the end-to-end view

                                                             ii.      It is the Designer for the global Network Service. It understands the end-to-end service at the global layer (business layer?) and manages NSDs in the GS-O service catalogue.

c.       Role #2) NFV-O Network “Service Designer”

                                                               i.      It is the Designer for the Network Service in a specific NFV-O domain. It manages the NSDs for a single NFV-O domain in the NFV-O service catalogue.

d.       Role #3) SDN-O Network Connectivity “Service Designer”             

                                                               i.      It is the Designer for the network connectivity service in the specific SDN-O domain. It manages NCSDs in the SDN-O service catalogue.

e.       Role #4)  “VNFD Designer”

                                                               i.      It is the Designer for VNF Descriptors that can either create new VNFDs or import vendor VNFDs in the VNFD Catalogue.

f.        The ownership of the descriptors (NSD, VNFFGD and VNFD), as well as the level of abstraction and ownership are as follows:

                                                               i.      It is a business decision as to what is owned by GS-O, NFV-O and SDN-O and what needs to be abstracted by NFV-O and SDN-O and what is visible to GS-O.

                                                             ii.      NFV-O and SDN-O ownership of descriptors:

1.       Based on the separation of catalogue into GS-O, NFV-O and SDN-O, the ownership is split based on what is business (GS-O) and what domain/technology policy (NFV-O/SDN-O)

                                                           iii.      NSDs or VNFFGD at the NFV-O layer:

1.       Descriptors needed as they have some additional attributes that must be filled in by service designer and are not present in VNFFGD. Example: designer, version, lifecycle management scripts, deployment flavor, security, etc.

2.       The service descriptors differ by different levels of abstraction, but are based on a shared model.

                                                           iv.      VNFDs visibility at the GS-O layer:

1.       There are different layers, some VNFDs may be visible at GS-O layer (e.g. vCPE business decision), some can be visible at the individual domains (e.g. vFW always by default, or policy, only if it is not business decision). Architecture must be flexible to support different business organizations.

2.       Abstraction at different layers needed, GS-O does not need to be aware of all VNFDs, VNFs and fully expanded forwarding graphs  (VNFFGD and VNFFG)

3.       GS-O has its own abstraction and view of the network service

4.       NFV-O has visibility into the graph for its domain

5.       SDN-O has visibility into all layers of connectivity

e.        The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      There were objections to the use of “Business Layer” for the GS-O layer. OPEN-O is not a BSS. It is n OSS. GS-O deals with customer-oriented services, not the business layer.

                                                             ii.      Are roles #1 and #4 the same? More discussion is needed at the next face-to-face meeting to clarify the roles and details of GS-O. We need to define the functionalities and roles and derive from that the interface requirements for each layer. Need to close differing points of view among the team members.

                                                           iii.      Our design needs to be flexible enough to support different business decisions on ownership.

                                                           iv.      Open questions that need to be discussed at the next meeting:

1.       NFV-O Network Service Designers per NFV-O Domain?

2.       Catalogue per NFV-O Domain?

3.       VNFDs either in the GS-O Domain or NFV-O Domain?

4.       Separate SDN-O designer per technology?

5.       No agreement yet on the terminology for SDN-O descriptors (NSD is used by ETSI, TMF/ONF/MEF uses Specification/ Descriptors/ Templates)

2.       Marc Cohn presented planning for next week face-to-face meetings in Shenzhen

a.       So far, the membership data are as follows:

                                                               i.      Premier Members are CMCC, Huawei, Intel, PCCW and ZTE. Gigaspaces is also very likely.

                                                             ii.      General Members are Canonical, Cloudbase Solutions, Infoblox and Raisecom. RedHat is also very likely.

                                                           iii.      Deadline for submission of membership applications is tonight

                                                           iv.      The official list will be sent Wednesday 2 June to members only.

b.       OPEN-O Kickoff is scheduled for June 7-9 in Shenzhen

                                                               i.      The meeting Venue in The Ritz-Carlton, 116 Fuhua San Road, Futian District Shenzhen 518048, P. R. China.

c.       Refer to Jessie Liu's emails for details on hotel reservations.

                                                               i.      Contact Jessie for help with hotel bookings.

                                                             ii.      Jessie coordinated marketing activities

d.       Agenda is 3-days

                                                               i.      Day 1 (June 7th): Premier Founding Members only

1.       Board Meeting (9am – 1pm)

2.       TSC Meeting (2pm – 5pm)

3.       Board and TSC meeting are non-overlapping to accommodate those individuals who need to be in both

4.       Evening: Board / TSC Dinner (to enable the Board & TSC to get to know one another)

                                                             ii.      Day 2 (June 8th):

1.       Joint Board/TSC meeting to shape responsibilities (open only to Premier Board/TSC members) (morning)

2.       TSC Meeting #2- Assuming TSC passes a motion in advance of TSC #2, this meeting will be open to all (afternoon)

3.       Marketing Meeting #1- In parallel with the TSC Meeting #2

4.       Evening: Social Event to encourage everyone to get to know one another, and celebrate the launch of OPEN-O

                                                           iii.      Day 3 (June 9th):

1.       TSC Meeting #3- As agreed during TSC Meeting #2, assuming TSC passes a motion in advance of TSC #2, this meeting will be open to all

2.       Marketing Meeting #2- As needed, In parallel with the TSC Meeting #2

3.       Breakout session (decide on during the Kickoff; two rooms booked for this purpose)

                                                           iv.      Marc is recording/prioritizing a comprehensive list of Board actions required, to guide the Board meeting agenda

                                                             v.      OPEN-O Governance Document stipulates that Board action is required to approve the nomination/election procedures for: General Member Board Rep, OPEN-O Board Officers (Chairman, Treasurer, and Secretary), and Marketing Chair

                                                           vi.      Marc agreed to verify with the LF the best practices for holding votes and elections prior to the Board meeting

e.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Uri requested that we determine an approach to conduct the General Member Board Rep prior to the Kickoff/Board meeting (so that the new General Member Board Rep can attend the Board meeting)

                                                             ii.      Priority is to ensure that elections happen as soon as possible, but the sequence is complex.

                                                           iii.      We need to find a quick method to elect the general member representative for the Board Of Directors.

                                                           iv.      Received request from Yale University and two Chinese Universities that they are interested to support SDNC and SDNO, and would like to contribute some code to our solution. There is a request to that our kickoff meetings on the 8th and 9th be open for individual contributors to attend the discussions as the associate member. Limit 1 per each university.

                                                             v.      Marc commented that as long as the TSC passes a motion at the first meeting (June 7th) to open up the TSC meetings, which he would expect to pass, then we can invite others interested in participating in the OPEN-O TSC meetings/ technical discussions. We better not make the distribution too broad, as there is a finite limit to the space.

                                                            vi.      Marc proposed that we impose the same limit that we did at the Seed Code Workshop (no more than 6 technical individuals per organization)

 

3.       Chris made a short walk-through the TSC Charter

a.       The OPEN-O TSC Charter is mainly based on ODL Charter

b.       The ODL charter is augmented by OPEN-O specific bylaw

c.       Unique points are the

                                                               i.      TSC subcommittee for the Architecture Team

                                                             ii.      Project roles are different

d.       The charter will be approved at the board meeting

 

 

4.       Action Items:

a.       Marc is working on the agenda for the Board meeting, joint Board/TSC meeting, and Marketing meeting #1

b.       Chris agreed to coordinate with the TSC members on an agenda for the TSC #1 meeting. Chris will prepare a proposal for the TSC agenda. Premier members should help Chris to create the TSC agenda.

c.      For next week’s meeting in Shenzhen, an agenda has been sent to the formation email group. Marc will send additional details this week

d.     Everybody to read and comment on the TSC Charter document. Deadline is next Wednesday (6/8)

 

Regards,

 

Cas

 

From: Casem Majd
Sent: Thursday, May 26, 2016 11:33 AM
To: Casem Majd; open-o-technical-formation@...; Christopher Donley (Chris); Michael McBride
Cc: Marc Cohn
Subject: RE: OPEN-O Architecture Meeting Notes

 

All,

Please find below the notes for this week’s OPEN-O Architecture Meeting.

 

Meeting Venue:  The OPEN-O Architecture Meeting Conference Call took place on Wednesday May 25th, 2016 from 6:30am to 7:30am PST. 22 people from 6 organizations participated.

 

Summary:

2.       Deng Hui (CMCC) presented an assessment of current OPEN-O budget

a.       A breakdown of the current budget has been presented, by

                                                               i.      Marketing

                                                             ii.      Developer collaboration

                                                           iii.      Legal

                                                           iv.      Others

b.       Budget estimation seems to be lower than expected. Suggest going through the budget again. (Consensus)

c.       List of tasks for the next face-to-face meeting on June 6th

                                                               i.      Anti-trust (LF program manager)

                                                             ii.      Election of BoD from general members (LF PM) (to be done before June 6th)

                                                           iii.      Elections for board officers, TSC chairs. (LF PM)

                                                           iv.      Authorization Board and LF about agreement and membership (LF PM)

                                                             v.      Proposal for our project officers based on our budget (Deng Hui Volunteer)

                                                           vi.      Budget  (Volunteer needed)

                                                          vii.      Marketing committee build up (Volunteer needed)

                                                        viii.      User Advisory Group document (Uri, Deng Hui, Marc volunteered)

                                                            ix.      TSC charter (Volunteer needed)

3.       Olga presented the summary report on the OPEN-O discussions from Beijing

a.       Approach 1:

                                                               i.      Use ARIA as bases for GSO and NFVO;

                                                             ii.      China Telecom + CMCC for SDN-O;

b.       Approach 2:

                                                               i.      This approach will be based on micro-services.

                                                             ii.      Take all modules that are in Java (ZTE, Huawei, CMCC) for GSO and NFV-O;

                                                           iii.      Huawei and China Telecom for SDN-O.

                                                           iv.      (GS-O NFV-O and ARIA for the parser in Common Functions)

                                                             v.      Workflow and Catalog under Common Services

c.       Approach 3:

                                                               i.      ManageIQ for GSO and NFV-O

                                                             ii.      Huawei + China Telecom for SDN-O

d.       Approach 1.5: 

                                                               i.      Approach 2 (GSO NFVO) and ARIA for the parser in Common Functions. ZTE for common services.

                                                             ii.      Aria Parser and Execution Engine will be used in GS-O and NFV-O

                                                           iii.      Re-use of Aria Parser and Execution Engine. Aria Parser and Execution Engine in Common-O to be reused by multiple projects.

                                                           iv.      Aria Execution engine will invoke business logic by other partners

                                                             v.      SDN-O REST API will be specified in the GS-O Service Template and the REST request will be sent by Aria execution engine

                                                           vi.      ManageIO will be the VIM and fill in some missing functions. This is the optimum solution to bring as much code as possible.

e.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                          vii.      SDN-O and GS-O interaction. Do not expose TOSCA parser to all details of YANG. Only expose necessary details to TOSCA via REST.

                                                        viii.      Hierarchical layering may be supported in SDN-O.

                                                            ix.      May not use ETSI terminology, but instead using MEF, etc.

                                                             x.      We may need to continue this discussion at the next f2f meeting.

                                                            xi.      The interface between SDN-O and GS-O needs to be defined and solidified for release 1.

                                                          xii.      ManaegIQ was not mentioned in the details. Are there any opportunities to include ManageIQ. Consensus is that ManageIQ can fit into release 1.5 for doing tasks such as discovery, collecting information, monitoring, managing drivers, …

                                                        xiii.      Red Hat to work with GigaSpaces on defining the NBI and integrating to ARIA parser

4.       Jessie gave an update on pre-marketing committee and other marketing activities

a.       Members so far: CMCC, Intel, Huawei, ZTE (still open to other members)

b.       PR for official founding, covering message, high-level architecture, and call for participation.

c.       OPEN-O Mini Summit in Berlin. Agenda proposal.

d.       Submission of presentations for mini summit. Proposed selection criteria are:

                                                               i.      Strong relevance to OPEN-O

                                                             ii.      Attractive to audience

                                                           iii.      Speaker title and impact

e.       Sample suggestions for presentations:

                                                               i.      Invite potential operators to give a speech. 

                                                             ii.      Call on vendors to work with OPEN-O for on boarding

f.        The following considerations, concerns, comments, and questions were raised from the audience:

                                                           iii.      Do we have enough material to fill one-day’s worth of content (Brendan)

                                                           iv.      Code release is in November. We may not be able to disclose much. (Deng)

                                                             v.      How many developers can travel to the event given the short time (Chris)

 

 

Action Items:

1.       Red Hat to work with GigaSpaces on defining integration interface between ARIA and ManageIQ (Dave & Amir)

2.       Identify location of next face-to-face meeting (Marc C)

3.       Add the PR for the list of marketing activities for the mini summit. (Jessie)

4.       Everybody provide comments on the accuracy of OPEN-O description to Jessie (by May 27th)

5.       Call for submission of presentations for the mini summit before May 27th.

6.       Invite AT&T to give speech on ECOMP monitoring and analytics

7.       Election of BoD from general members (LF PM) (to be done before June 6th)

 

Regards,

 

Cas

 

From: Casem Majd
Sent: Friday, May 13, 2016 6:21 PM
To: Casem Majd; open-o-technical-formation@...; Christopher Donley (Chris); Michael McBride
Cc: Marc Cohn
Subject: RE: OPEN-O Architecture Meeting Notes

 

All,

Please find below the notes for this week’s OPEN-O Architecture Meeting. Thanks to Olga and Brendan for their contributions.

 

Meeting Venue:  The OPEN-O Architecture Meeting Conference Call took place on Wednesday May 11th, 2016. Meeting started at 6:30am PST and ended at 9:30am PST (~1.5 hours). 32 people from 8 organizations participated. We had two invited guests from our partner projects MEF LSO and OpenDaylight.

 

Summary:

5.       ManageIQ Presentation & Discussion

a.       Geert Jansen from Red Hat presented ManageIQ Functional Architecture Slides, especially addressing the discussions around MicroServices. The main question discussed was “why ManageIQ does not use MicroServices?”

                                                               i.      ManageIQ was developed using 30-40 years of experience in building management systems

                                                             ii.      ManageIQ does not take the MicroServices approach – It takes a platform approach – platform as a service.

                                                           iii.      To build a rich management platform, Red Hat advocates platform driven approach versus MicroServices approach.

                                                           iv.      A platform-based approach suits management applications that are tightly coupled by data.

                                                             v.      There are several services in the platform; It uses Ruby object model.

                                                           vi.      ManageIQ will be available as a container to aid integration.

                                                          vii.      One single virtual appliance can have 100 copies

                                                        viii.      Appliance can be bound to the region and to zone. They have multiple roles, one or more roles maps to the processes in the appliance

                                                            ix.      Red Hat wants to demonstrate the power of the ManageIQ platform at the OPNFV and show why one would use platform approach versus MicroServices approach – Red Hat is preparing a demo for OPNFV 2016.

b.       The reasons ManageIQ does not use MicroServices are:

                                                               i.      MicroServices is not the right approach for a management platform. MicroServices has some good things – separation (each MicroServices has independent APIs), performance/scale – but it is not the correct architecture. It is not the only way to do things.

                                                             ii.      The ManageIQ Platform got through acquisition and was built before MicroServices time

                                                           iii.      MicroServices approach is still not a well proven approach in the industry. MicroServices have not been proven to be a better architecture than a platform-based approach.

                                                           iv.      Management of resources has special requirements, where we need tighter coupling than in other domains.

                                                             v.      It is not clear that MicroServices can be efficient in Data Model driven systems

                                                           vi.      MicroServices has a large cost, Red Hat believes cost is not worth the benefit

c.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      DengHui – Advocates for MicroServices. MicroServices allow easier integration of components from multiple companies that use diverse technologies. MicroServices facilitates the integration of different components that come from different companies with different code base. ManageIQ is coming late to OPEN-O, and more analysis is needed.

                                                             ii.      Uri – Why would MicroServices be a better approach than other alternatives? How would MicroServices allow easier integration? Is REST the main advantage?

                                                           iii.      DengHui – OpenStack is an example for implementing MicroServices with success. MicroServices allows plug-and-play model, where each module is independent of the message bus, allowing each module to be integrated independently.

                                                           iv.      Geert – OpenStack is impressive, but it took 6-7 years with thousands of developers to develop. MicroServices comes at a cost, not sure if it is justified.

                                                             v.      Dave – Wants to discuss platform versus point-to-point integration more. He prefers platform versus MicroServices, because it will be more costly to define all individual p2p interfaces.

                                                           vi.      DengHui – Some existing code such as Aria needs to be integrated within this year, it cannot work with a platform that is based on another language.

                                                          vii.      Geert – ManageIQ has advantages over Aria. ManageIQ has broader functionality, except for the TOSCA parser. Using multiple languages may not be the fastest way to build a community.

                                                        viii.      Its service model may currently not be ideal but it has a good service catalogue

                                                            ix.      Deng Lingli – ManageIQ is a Cloud Manager, it has major (functional) gaps as an orchestrator. How much effort is needed to use ManageIQ as NFV-O? What effort is needed to fill the gaps?

                                                             x.      Geert – ManageIQ is a generic manager, not just a Cloud Manager. ManageIQ is not ready for use as NFV-O, but the platform provides most of the primitives.

                                                            xi.      ManageIQ has many re-usable components, activation engine, governance, federation, data model, and SDN.

                                                          xii.      The platform can be easily changed to fill any gaps for OPEN-O

                                                        xiii.      Geert – The ManageIQ core team will not be able to attend the Beijing meeting. Please do not make any decisions until you have seen our OPNFV demo.

                                                        xiv.      DengHui – RedHat should propose which module could be used. Red Hat can propose something for the platform driven approach.

                                                          xv.      The ManageIQ issues will be discussed by email. We can discuss more next week in Beijing.

                                                        xvi.      Chris – No decisions will be made at the Beijing meeting. Decisions cannot be made until June when TSC is formed. Meanwhile we can just make suggestions.

 

 

6.       MEF LSO Reference Architecture

a.       Andy Mayer, as a guest participant from a partner project, presented MEF LSO Reference Architecture. His presentation covered the following points:

                                                               i.      History of MEF Lifecycle Service Orchestration Reference Architecture

                                                             ii.      Definition of LSO and LSO RA

                                                           iii.      Drivers-on-Demand and Agile Services

                                                           iv.      Definition of Orchestration

                                                             v.      MEF Engineering Methodology

                                                           vi.      LSO-related MEF activities

                                                          vii.      LSO Reference Architecture

                                                        viii.      LSO Operational Threads

                                                            ix.      LSO Management view abstractions

                                                             x.      Examples of data transferred on each interface

                                                            xi.      LSO example with SDN and NFV

                                                          xii.      LSO RA phase 2 plans

b.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Uri – Which requirements are imposed on controllers by Presto?

                                                             ii.      Andy – We are working with ONF on Presto requirements for Service Chaining. Phase 2 will investigate more use cases and interactions.

                                                           iii.      Amir – GigaSpaces has already demonstrated at the LSO Hackathon the Legato and Presto interfaces using TOSCA. (Demonstrated Legato API using Tosca).

                                                           iv.      Uri – Is the Presto interface defined? How MEF addresses SDN-O and NFV-O – Presto + network functions and network services? There are still discussions whether Service Orchestration goes directly to VNFM or NFVO?

                                                             v.      Andy – An early draft is available.

                                                           vi.      Uri – Has LSO been adopted by any BSS groups?

                                                          vii.      Andy – We are working with open source communities.

                                                        viii.      Olga – Has MEF discussed Presto with ETSI NFV? The question is about Legato vs. ETSI API.

                                                            ix.      Andy – We have been working with ETSI NFV (still work in progress). We hope to develop use cases with ETSI.

7.       Seed Code Meeting Presentation

a.       Chris presented the Seed Code meeting charts, covering the following points:

                                                               i.      Workshop goals

                                                             ii.      Agenda

                                                           iii.      Architecture Map

                                                           iv.      Potential metrics

b.       Chris – We should add 2 new metrics. Ability to deliver this year, and effort needed to fill gaps.

c.       Marc – I have discussed the metrics with Phil Robb from OpenDaylight. Phil can share his expertise.

d.       Phil – The current list looks good. Contributors who have overlaps should discuss differences in functionality and differences in approach. Phil will join us next week in Beijing, he has experience in ODL.

e.       Phil – proposed that those who have multiple seed code contributions to have joint meetings to understand and assess each other’s proposals, overlaps and gaps

f.        Lingli – presented arrangements for the meeting in Beijing. It is important to register at the North gate on the first day.

g.       Geert – The ManageIQ core team will not be able to attend the Beijing meeting next week.

h.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Uri – We need a high-level description of the functionality and the APIs.

                                                             ii.      Chris – We will have sessions in Beijing for detailed discussions.

                                                           iii.      Uri – We need basic definitions of each component. For the proposed functionality and APIs, we need the description and requirements for the OPEN-O blocks, so that we can match OPEN-O requirements to APIs and provided functionality of the contributions

                                                           iv.      Deng Lingli – Each contributor should answer the above questions during their presentation.

                                                             v.      Chris – Each contributor should address all of these metrics.

                                                           vi.      Deng Lingli – We should add a metric for compliance to standards such as ETSI or MEF.

                                                          vii.      Uri – MEF will not be relevant outside SDN.

                                                        viii.      Chris – We can use the email list to discuss which standards may be relevant.

                                                            ix.      Corona Wei or Fengjie – Made some comments about MEF and will share her ideas by email

                                                             x.      Uri – Functionality in each block is still unclear.

                                                            xi.      Dave – It may be good to have a “bake-off” where sample use cases are used to evaluate each contribution.

 

 

Action Items:

8.       Forward the MEF LSO slides to the email list. (Chris D)

9.       Share the current Presto draft. (Andy M)

10.   Send a list of confirmed attendees for next week’s face-to-face meeting in Beijing (Lingli Deng)

11.   Red Hat will not be able to attend Beijing meeting, but they will try to communicate through presentations (Uri E)

12.   Share the slides for the section on “Seed Code Meeting” (Chris D)

13.   Add best practices for code selection (Mark C)

 

Regards,

 

Cas

 

From: Casem Majd
Sent: Thursday, May 05, 2016 2:56 PM
To: Casem Majd; open-o-technical-formation@...; Christopher Donley (Chris); Michael McBride
Cc: Marc Cohn; Casem Majd
Subject: RE: OPEN-O Architecture Meeting Notes

 

All,

Please find below the notes for this week’s OPEN-O Architecture Meeting. Thanks to Dave again for his help.

 

Meeting Venue:  The OPEN-O Architecture Meeting Conference Call took place on Wednesday May 4th, 2016. Meeting started at 6:30am and ended at 7:30am PST. 23 people from 8 organizations participated.

 

Summary:

8.       Review conference participation/feedback (ETSI NFV, OpenStack, MEF, etc.)

                                                   i.      We had an event report from the face-to-face last week at OpenStack Summit

                                                 ii.      Report on ETSI NFV meeting

                                               iii.      Report from MEF

b.      ETSI NFV Update

                                                   i.      Marc C from Linux Foundation mentioned that they had been invited to meet with the ETSI NFV MANO group this week in Atlanta to talk about possible collaboration.

                                                 ii.      ETSI NFV panel went well, which opens the door to further cooperation.

1.       Chris and Marc presented Open-O at the ~150 members ETSI panel (special session on open source orchestration, where OPEN-O and OSM were showcased in a single session)

2.       Additionally, we participated in a panel discussion

                                               iii.      Amir Levy from GigaSpaces presented ARIA hierarchical model-driven orchestrator (TOSCA/YANG). 

                                               iv.      OSM team also presented their story.

                                                 v.      Questions from the ETSI participants around how we plan to use their specs and common information/data models/VNFs.

1.       ETSI is particularly interested in OPEN-O converging on a common Information Model with OSM, and compliance with the ETSI NFV Architectural Framework.

2.       ETSI wants us to provide ETSI NFV IFA-compliant interfaces

                                               vi.      Also questions about participating in standards versus open source.

                                              vii.      Discussed the possibility of convening an OPEN-O/OPNFV/OSM session at the OPNFV Summit in June. ETSI also offered to share a tutorial on the ETSI IFA-defined interfaces.

                                            viii.      AT&T also presented ECOMP earlier in the week.  Marc said that they were hinting that they’re working on an open source strategy, but it didn’t sound like a separate community. They are asking a lot of questions about Open-O. We need to keep engaging with them.

c.       MEF Forum Update

                                                   i.      Brendan H talked about the interest for Open-O that he had encountered at the MEF forum.

                                                 ii.      SDN-O integration is important for the MEF use-cases.

                                               iii.      MEF forum asked a lot of questions about Open-O.

                                               iv.      We will invite MEF to present to the OPEN-O architecture team in May

 

9.       Work Plan

a.       Marc reviewed the plan for the next few weeks. 

b.       Marc is refining the spreadsheet, and will send an update this week.

c.       Several companies announced intention to participate in the face-to-face in Beijing: Intel, Huawei, ZTE, China Mobile, China Telecom, GigaSpaces (maybe others).

d.       Parties are asked to send the seed code map to Chris by 5/10

e.       Parties are asked to register for the event by 5/10

f.        Parties are asked to notify Marc if they are planning to join Open-O, and at what level (even prior to formally signing the membership document). We need to start planning launch activities.

10.   Architecture

a.       HA is put in the “Common Service” box and not the “O-common” box, HA is a common requirement for all the components inside OPEN-O, not only those inside the orchestration layer.

b.       Uri asked about EMS/OSS/BSS interfaces.  Deng Hui referred him to the YouTube video of our OpenStack talk.  We will discuss on a future call.

11.   Discussed preparations for the May 17-19 meeting

a.       Reported on seed code release progress and planning for face-to-face meeting in Beijing

b.       Who is bringing seed code

c.       What are the expectations for companies bringing seed code

d.       Question raised whether there were guidelines on meritocracy of operation

e.       Some organizations feel it is important to understand the meritocracy before the meeting, to inform the discussion and decision process.

12.   Red Hat ManafeIQ Presentation

a.       For the last 15 minutes, Red Hat (Geert Jansen) presented ManageIQ.

b.       Red Hat proposes that ManageIQ

c.       Red Had open sourced this code base in 2014.

d.       Code base started in 2006 and uses the Apace 2.0 license. Code is written in Ruby on Rails.

e.       It is a service catalog for on boarding of VNF

f.        Provisions the VNF via standard provisioning workflows

g.       Support of VNF lifecycle management via service models

h.       Provides event-driven automation via control

i.         Supports delegated control via service model

j.         We did not have a lot of time for questions, but there were a number of people who said that they wanted to follow up with questions.

k.       Agreed to continue the discussion via email.

 

Action Items:

14.   Parties are asked to send the seed code map to Chris by 5/10

15.   Parties are asked to register for the event by 5/10

16.   Parties are asked to notify Marc if they are planning to join Open-O, and at what level

17.   Invite MEF to present at the OPEN-O architecture team in May

 

Regards,

 

Cas

 

From: Casem Majd
Sent: Monday, May 02, 2016 5:36 PM
To: Casem Majd; open-o-technical-formation@...; Christopher Donley (Chris); Michael McBride
Cc: Marc Cohn
Subject: RE: OPEN-O Architecture Meeting Notes

 

All,

Please find below my notes for this week’s OPEN-O Architecture Meeting. Thanks to Dave Neary for his valuable contributions to this week’s meeting notes.

 

Meeting Venue:  The OPEN-O face-to-face Architecture Meeting took place in Austin, TX at the end of the OpenStack Summit on Friday April 29th, 2016. Meeting started at 9:00am and ended at 3:00pm. 18 people from 9 organizations participated.

 

Summary:

1.       Sivan and Arthur B from GigaSpaces presented a tiered or hierarchical service model proposal

a.       The proposed hierarchical model consists of two levels of abstractions

b.       TOSCA is used for the end-to-end service abstraction, with extension nodes that contain YANG models, which are used for the network and device abstraction.

                                                               i.      TOSCA extensions capabilities are used to add new node types and develop a common composite model made from TOSCA, YANG, and other plug-ins

                                                             ii.      The top-level abstraction describes what is needed for the service, and the lower-level abstraction specifies the implementation details of each network component (e.g. YANG models for ODL or ONOS network domains)

                                                           iii.      The model is used to create functions out of building blocks and chain those functions to create services.

                                                           iv.      One example presented: Modeling DNS - node type Bind9, with some connected resources (such as a GW FW, security groups) - some of which are external to the VNF

                                                             v.      The example demonstrates TOSCA as a description language, including its extensibility

                                                           vi.      Relationship between YANG and TOSCA? Sometimes some things are better expressed with YANG, and the proposed solution (ARIA) has a possibility to wrap these pieces in TOSCA to orchestrate

c.       The model covers the service lifecycle, from installation, provisioning, configuration and deployment through monitoring of the application or service in order for the system to take reactive or proactive actions, such as healing and scaling based on custom triggers, or other actions to be performed as part of a lifecycle.

d.       The models come with policy and workflow components. Pre-defined events are specified in the policy templates for certain conditions or threshold violations. The policy defines which events to track, what threshold conditions to watch for, and what corrective actions to take in case of violation of those thresholds. Examples are scale-out based on pre-set capacity utilization thresholds.

                                                               i.      Separation of policy, workflow, and execution/event handling

                                                             ii.      The policy templates specify when to react,

(Policy: If event, then mitigation (start a mitigating workflow))

                                                           iii.      The ensuing workflow specifies the sequence of actions (what to do) to perform in case the policy is violated, and

(Workflow: Actions to be executed - potentially more than one - to apply policy)

                                                           iv.      The implementation logic specifies how to react

(Execution: Event triggers policy execution, which runs through workflow)

e.       The solution would consist of a model parser and an execution engine.

                                                               i.      ARIA is a TOSCA parser and orchestrator. Every time a new node type is added, the parser needs to be aware of them, and validate them.

                                                             ii.      Q: Is it better to have a separation of parser and orchestrator? R: Opinion is that parser and orchestrator are related - similar to UI and model, hard to write a UI without awareness of underlying model

                                                           iii.      Perhaps runtime binding of an alternative orchestrator would be possible

                                                           iv.      Extensive discussion about whether it makes sense to have the parser tied to one orchestrator, and how separation would be possible

                                                             v.      ARIA is open source, and there is a desire of GigaSpaces to have multiple vendors collaborate on it - extension and collaboration could happen in ARIA

f.        The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Need to plug-in to ETSI, and try to define common models that align with ETSI

                                                             ii.      What is the relationship with ETSI NFV MANO? Will there be a common model with the industry? We should align with what is being used in OSM for the information model to converge on an industry norm (best effort attempt).

                                                           iii.      How and to what extend would the proposed models support the complete lifecycle of the service, including model-driven service assurance and inventory schema (allowing new inventory item types to be added dynamically based on models).

                                                           iv.      Is a tiered model necessary for service modeling? Doesn’t it introduce unnecessary complexity? The relevance of the model should be demonstrated with the vCPE use case implementation, and show what was extensions were made to the standard TOSCA or YANG.

2.       Olga H from Huawei reviewed the OPEN-O functional architecture

a.       The team reached consensus on the existing OPEN-O architecture. Minor modifications were made to the architecture diagram, e.g.,

                                                               i.      Adding HA function to the O-Common,

                                                             ii.      Adding EMS/NMS driver to the southbound

b.       Separation of some common services unrelated to Orchestration use-cases (logs, workflow, message bus, etc) and common services with orchestration focus (template management, lifecycle management framework, model driven framework). The main components of the architecture are:

                                                               i.      Common Services, which consist of generic applications that are independent of orchestration. These are system-wide functions.

                                                             ii.      O-Common, which consists of orchestration specific services and functions

                                                           iii.      SDN-O, which provides abstraction for masking network complexities.

                                                           iv.      NFV-O, which models VNFs and applications. It would preferably be aligned with ETSI models.

                                                             v.      What about intent? - intent parsing needs to be in global service orchestration, but also for rendering intents, southbound of SDN-O for the SDN controllers. Consensus is that both SBI and NBI will support intent.

                                                           vi.      As presented, separation of driver layer for different VIMs, SDN controllers, VNFM drivers, which are independent of the model design and resource management layers.

c.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      It is not clear if the software architecture (and its corresponding data model architecture) is aligned with the OPEN-O architecture diagram. This needs more discussion.

                                                             ii.      There is a concern of having to deal with too many modules and too many interface points between them, which would slow us down! Is there a generic VNFM interface?

                                                           iii.      Relationship with Tacker, OPNFV, etc?

                                                           iv.      Using standard open source components for common services, even if there is not a vendor at the table.

3.       The team discussed one open architectural item – HA

a.       How to provide HA? Should it be a platform function or a module-specific function?

b.       We agreed that it belonged as a common function, and updated the architecture diagram accordingly (adding HA to O-Common)

c.       Support of HA would not be within the scope of release 1.

d.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Open-O is going to implement Micro-Service architecture

                                                             ii.      HA and scalability should be common requirement for each micro-service (Perhaps on O-Common - HA service?)

                                                           iii.      HA as a common requirement has the potential consequence that the modules may have to be stateless. More work needs to be done to clarify.

 

4.       The participation at OPNFV Summit has been discussed

a.       China Mobile offers their booth space at the OPNFV Summit in Berlin for free to host the Open-O demos

                                                               i.      There will be a small/narrow space, with 2 demo spaces

                                                             ii.      So far, there are six demos prepared and proposed by different vendors (Red Hat, ZTE, etc.)

                                                           iii.      Intention is to cast the demos into a broader and more consistent story that highlight the main OPEN-O capabilities. It should not be a scattered set of demos. They all should tell a consistent end-to-end storyline.

b.       OPEN-O will be presented at OPNFV for the first time under its own name as an independent entity, and not through any specific organization.

                                                               i.      China Mobile / Huawei will be doing a joint presentation.

c.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Need to finalize the OPNFV demos during the next face-to-face meeting in May 2016.

5.       Discussion on Seed Code contributions

a.       Vibrant discussion on who plans to bring seed code to the May meeting:

                                                               i.      Organizations will be invited to contribute seed code. So that we can make most effective use of the face-to-face, every party will fill up a map that shows to what module it intends to contribute code?

                                                             ii.      Expression of intent for contributing seed code is currently not binding. Partner organizations can declare their intents for contributing code without any concerns about legal obligations. As long as TSC has not been formed, no decision will be made on what code to include and what to exclude to/from the base code.

                                                           iii.      It is preferred for organizations to come to the meeting with open source code. However, if organizations intend to submit open source seed code, but have not cleared their code yet, they may just make presentations at the next meeting in order to avoid legal complications. Organizations should not disclose their code if they don’t have the required open-sourcing approvals.

                                                           iv.      Requirement to open source code in advance of the OPNFV Summit hackfest, but not necessarily in advance of the meeting in Beijing. Marc Cohn confirms that we will not be doing any NDAs or similar - if code is not open sourced, then only publicly available information can be presented.

                                                             v.      Bringing code does not guarantee that the code will be included

                                                           vi.      The team will define the criteria and the meritocracy rules for accepting or rejecting code contributions to the code base. Linux Foundation will share its current Best Practices to all participating organizations. The team will make a group decision based on suggested best practices.

1.       The decision criteria for how seed code will be chosen will be documented before the meeting

b.       Proposed process for consolidating code:

                                                               i.      We will send the detailed architecture diagram to participating organizations and ask how their intended seed code contribution would fit into the OPEN-O module landscape.

                                                             ii.      Organizations will fill up a map that shows to what module they intent to contribute code to.

                                                           iii.      We will create a consolidated mapping table that maps each contributing code to each functional architecture block and identify a leader for each category

                                                           iv.      The goal of this planning is to gather expressions of interest to bring code to the table.

1.       The intent to participate - with an understanding that things will evolve, as we start to work on it, and refine functional block definitions.

                                                             v.      In May, we will discuss, with a level playing field, which components will be part of the initial release

                                                           vi.      The TSC, after formation, will own and validate the architecture and project operation - the architecture discussion group provides input into that discussion

                                                          vii.      Participation will be open - it is possible that people who have not been involved in the formation discussions will participate

                                                        viii.      If people express an intent to join, they can participate in the mailing list and May meeting.

c.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Question whether seed code must be open source? All seed code must be open source before the launch.

 

6.       Preparation for next face-to-face meeting in China from May 17th to May 19th 2016

a.       The review and consolidation of the contributing seed codes is the main objectives of the next face-to-face meeting in May 2016.

                                                               i.      The next face-to-face meeting to be held at China Mobile facilities in Beijing, China from May 17th to May 19th 2016.

                                                             ii.      Place: Meeting Room 908, Level 9th, China Mobile Research Institute, Beijing, China

b.       We will wait to see what code contributions we will receive and then decide how to organize the meeting (structure, number of sessions, mission for each session, etc.)

                                                               i.      The current consensus is to start with an end-to-end architecture session, followed by a set of parallel module-specific code review sessions.

1.       Day 1: Presentation of seed code

2.       Day 2: How we operate as a community, how meritocratic decision making works, and how we make seed code easier to consume

3.       Day 3: Convergence on who will participate in the project at which functional blocks, scope and goals for 1st release

                                                             ii.      There are concerns about

1.       How to coordinate the work between overlapping SDN-O and NFV-O tracks?

2.       How to take the results and consolidate them? How to take and consolidate meeting notes?

                                                           iii.      The final agenda for the May meeting is moved to the mailing list

c.       The goals of the May meeting are:

                                                               i.      Companies participating will have an opportunity to present their seed code, show how they fit into the architecture, and demo their projects

                                                             ii.      Review contributing codes, assess how contributions fit together

                                                           iii.      We will try to resolve conflicts between code which is functionally overlapping

                                                           iv.      Define a realistic scope for release 1

                                                             v.      Create a project plan for TSC

                                                           vi.      Partners should come to the meeting with their USB keys and code.

d.       Before the meeting, create a consolidated mapping table that shows how each contributing code maps to one of the following functional blocks of the architecture and identify a leader for each category:

                                                               i.      SDN-O and its drivers

                                                             ii.      NFV-O and its drivers

                                                           iii.      GS-O

                                                           iv.      Tools / Commons

                                                             v.      We will identify track leaders before the May meeting for break-out sessions on each of the main functional blocks.

e.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      There are certain visa and travel restriction concerns

                                                             ii.      It is understood that the meeting is short notice for some participants. However, the meeting should not be later - because of time pressure for OPNFV.

                                                           iii.      Concern expressed that if we start with a broad and ambitious scope, we will have trouble converging to a first release. We do not want to lock in a plan in May before we have a technical community created and working together. We may be able to start working on seeding project plans in the May meeting, even if it will take a few weeks to get a TSC.

                                                           iv.      Is there a separate track on architecture, planning, components? Someone needs to keep the overall view/big picture in mind

 

7.       Mark C presented the plan of work for the next 3 months

a.       Major milestones were presented

b.       The plan will be distributed next week

c.       Companies to introduce representatives for various committees (TSC, etc.)

d.       Launch planned for June 1st

e.       First Board Meeting in June

f.        First code release for end of year

 

Action Items:

18.   Provide a concrete example (preferable vCPE use case) that shows the need for a 2-level abstraction model (TOSCA-YANG). Show how and why the proposed hierarchical model is superior. And preferably layout the details of a use cases that would benefit from hierarchical TOSCA/YANG models. (GigaSpaces, Arthus B)

19.   Continue the discussion via mailing list on how the proposed model would support complete lifecycle for model-driven service assurance and inventory (Arthus B, Olga H)

20.   Show how to map the proposed models to the OPEN-O architecture diagram (GigaSpaces, Arthur B)

21.   Show more specifically a SBI for legacy EMS/NMS by adding an EMS/NMS driver to the architecture diagram. (Olga H)

22.   Update OPEN-O architecture diagram to include HA function in O-Common box (Chris D)

23.   Identify who in the industry has tools or applications that would fall within the scope of OPEN-O Common Services. The search should also include those companies that are currently not involved in OPEN-O. (Dave N)

24.   Send the detailed architecture diagram to participating organizations to see how their intended seed code contributions would fit into the OPEN-O module landscape. Organizations will fill up a map that shows to what module they intent to contribute code to? (Chris D)

25.   Coordinate the activity for creating a consolidated mapping table that maps each contributing code to each functional architecture blocks and identify a leader for each category; Emails to be sent out by May 3rd for collecting information. Mapping table to be created by May 10th.  (Mark C; Chris D)

26.   In order to define the criteria and the meritocracy rules for accepting or rejecting code contributions to the code base, Linux Foundation will share its current Best Practices by May 5th. Post it on Etherpad. (Mark C)

27.   Organize OPEN-O activities (demos, presentations, etc.) related to OPNFV summit in Berlin. Consolidate the six OPNFV demos into common groups such that they fit into a broader storyline and better highlight core OPEN-O capabilities. Every demo will be mapped to a supporting organization. Create a game plan for the OPNFV demos. (Deng Hui)

28.   Organize the logistics of the next face-to-face meeting in China. List of attendees. Who does what? Define when and where we will meet? (Deng Hui)

29.   Send out instructions on logistics of the May meeting, what to bring to the meeting, rules, etc. (Mark C, Chris D)

1.       Participant to send their information (name, email, phone, and food preferences) to China Mobile

2.       Participants to bring their passport to the meeting. Passport registration is required at China Mobile

3.       Participant to bring their USB keys with code

4.       Organizations to bring their developer experts to the meeting that can present code.

30.   Incorporate latest feedback/corrections to the whitepaper, add a paragraph about how to interact with OSS/BSS, and release the 5th version of the Whitepaper to Linux Foundation for final editing and publication. Each company has to provide an author name for the whitepaper. (Cas M; Harshad T; Deng Hui)

31.   Invite MEF to make an LSO presentation at one of our OPEN-O architecture meetings. Focus on describing what is LSO and how does it relate to OPEN-O? (Chris D)

 

Regards,

 

Cas

 

From: Casem Majd
Sent: Thursday, April 21, 2016 10:48 AM
To: open-o-technical-formation@...; Christopher Donley (Chris)
Cc: Casem Majd; Marc Cohn
Subject: OPEN-O Architecture Meeting Notes

 

All,

Please find below the notes for this week’s OPEN-O Architecture Meeting.

 

Meeting Venue: OPEN-O Architecture Conference Call on Wednesday April 20th, 2016

 

Summary:

1.       Marc Cohn went through the current launch details.  The charter and membership agreement have been sent out for review. Prospective members must return signed documents by June 1 to be considered founders.  The launch date will be June 1.

2.       Plan of work:

a.       Chris, Marc, and Chengli will create a (2-3 month) plan document for pre-launch activities, which will encompass the timeline and ownership of the following milestones, formation documents, tasks, and launch items;

                                                               i.      Official launch

                                                             ii.      Founding Member review and

                                                           iii.      User Advisory Group

                                                           iv.      Targeted recruitment

                                                             v.      Design and sign-off of a Logo

                                                           vi.      Design and launch of the Web site

                                                          vii.      Brief and white paper publication

                                                        viii.      Target architecture

                                                            ix.      Coordinated release of seed code

b.       The 2-page Brief is a pre-formation document, not an official document. LF to be the official author to make its publication easier.

c.       LF compiled draft of Formation Committee and Membership Agreement; Date of joining is early May, which is moved to June 1st so that additional members can sign up.

                                                               i.      Membership Agreements have been sent out to some

                                                             ii.      Founding Members to be formed

d.       LF to issue PR with Founding Members later in May. Being reviewed and collecting executive quotes form member organizations.

e.       User Advisory Group has to be formed before official formation (End User Group?)

3.       Release of seed code

a.       Huawei seed code going through final internal approval and should be released to git in mid May (quietly). It will be publicly announced in June, coordinated with other partners. The seed code is currently available for review under NDA

b.       China Mobile also will release seed code; Date not confirmed!

c.       China Mobile suggests having an informal 2-3 days of seed code review in mid May in China. The topic will be taken to mailing list to gain critical mass and finalize time and location.

4.       Plan to finalize the target architecture and use cases (cloud VPN and model stacks) at the face-to-face meeting in Austin, TX

5.       OPEN-O Whitepaper:

a.       The current 4th version of the whitepaper to be sent out for review on 4/20.

b.       Whitepaper will be handed off to Marc for final editorial review.  Publication will be timed to support the Open-O launch (target- Mid-May).

c.       Publication of the whitepaper will be put up after signing of Joining Agreement and formation of Founding Members.

d.       The final version will include Founding Members’ names as contributors.

6.       The following module names were agreed for OPEN-O: GS-O (Global Service Orchestrator); SDN-O; and NFV-O. The name NFV-O is maintained to show alignment with ETSI.

7.       Olga had a short discussion on the model stack.

a.       China Telecom to add a SDN controller for the enterprise in the Cloud VPN use case

b.       Open questions:

                                                               i.      Which module decides on VNFs: the NFV-O or the GS-O?

                                                             ii.      Which module owns SFC: the SDN-O or the NFV-O?

c.       China Telecom will send more details on underlay versus overlay connectivity and their orchestration

d.       Use cases to be finalized at next week’s architecture meeting. The discussion to be continued via mailing list.

8.       Members were asked to provide feedback on the agenda of next week’s face-to-face meeting. The agenda is on Etherpath. https://openo-arch.titanpad.com/4

 

 

Action Items:

32.  Chris, Marc, and Chengli will create a plan document for the next three months.

33.  Incorporate community feedback and release the 5th version of the White Paper by mid May.

34.  Define the when and where of 2-3 days long seed code review meeting (mailing list)

35.  Gigaspaces will present on data modeling at the face-to-face meeting

36.  China Telecom use case to be finalized by 4/29.

37.  Each company to provide an author name for the whitepaper

38.  Qiong Sun to send specific details on the Cloud VPN use case for the whitepaper

39.  Next week’s face-to-face meeting will be in Austin, TX (at OpenStack Summit) on Friday 4/29

 

 

Regards,

 

Cas

 

--
You received this message because you are subscribed to the Google Groups "open-o-technical-formation" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-o-technical-formation+unsubscribe@....
To post to this group, send email to open-o-technical-formation@....
To view this discussion on the web visit https://groups.google.com/a/linuxfoundation.org/d/msgid/open-o-technical-formation/B32AAC004DC2B941B1641BF9F8FA7398013E75FE%40dfweml501-mbx.


Christopher Donley (Chris) <Christopher.Donley@...>
 

Thanks Lingli.  Let me put you in touch with Gildas Lanilis, our new Release Manager, who is taking the lead on the Project Lifecycle document.

 

Chris

 

From: Lingli Deng [mailto:denglingli@...]
Sent: Tuesday, June 14, 2016 9:25 PM
To: Casem Majd; Christopher Donley (Chris)
Cc: 'Marc Cohn'; Michael McBride; openo-discuss@...; openo-tsc@...; open-o-technical-formation@...
Subject: RE: OPEN-O Architecture Meeting Notes

 

Hi Cas,

 

Thanks for taking the notes.

 

Chris, I volunteer working on the project life cycle document draft for further TSC discussion.

 

Thanks and Regards,

Lingli

 

From: open-o-technical-formation@... [mailto:open-o-technical-formation@...] On Behalf Of Casem Majd
Sent: 2016615 10:37
To: Casem Majd <cas.majd@...>; open-o-technical-formation@...; Christopher Donley (Chris) <Christopher.Donley@...>; Michael McBride <Michael.McBride@...>; openo-tsc@...; openo-discuss@...
Cc: Marc Cohn <mcohn@...>
Subject: RE: OPEN-O Architecture Meeting Notes

 

All,

Please find below the notes for this week’s OPEN-O TSC Meeting. Note that starting this week, the Technical Steering Committee (TSC) and the Architecture Committee (ARC) conduct separate meetings, on Tuesdays and Wednesdays respectively. This is the report for the TSC meeting.

 

TSC Meeting Venue:  The OPEN-O TSC Meeting Conference Call took place on Tuesday June 14th, 2016 from 7:00am to 8:00am PST. 30 people from 7 organizations participated.

 

Summary:

1.       Chris D. gave a summary report on last week’s achievements, reviewed open items (Uri’s email), gave a walk-through the Wiki tools, and discussed the process for developing governance and policy documents.

a.       Charter has been approved and is posted on Wiki. The Charter governs our behavior as the TSC, defines officers and describes the organizational structure.

b.       Elections held with following results:

                                                               i.      Chris Donley was elected at Chair of the TSC.

                                                             ii.      Uri Elzur as the Chair of Architecture Committee group and Vice Chair of the TSC.

                                                           iii.      Voted to open the TSC meetings to everyone in community with the exception of executive sessions, which will be made know in advance.

                                                           iv.      The TSC members may delegate alternatives in case the voting TSC member cannot attend

c.       Release Plan discussed and posted on Wiki

                                                               i.      Targeting release end of 2016

                                                             ii.      Internal release date set for Nov 3rd; this date will not be publicized externally. We are looking for additional feedback from board on both the release plan and the use case. So the release date may change in near future.

d.       Four projects proposal have been approved. There were open items on each project proposal. Uri has been documenting those open items in an email.

                                                               i.      NFV-O

                                                             ii.      SDN-O

                                                           iii.      GS-O

                                                           iv.      Common Service

                                                             v.      Two additional project proposals are in the pipeline that will be reviewed in coming weeks when we do the planning process through the remainder of this month.

e.       SLACK tool is a conferencing note taking for the community. People feel free to take notes and conduct discussions on the SLACK.

                                                               i.      Link for SLACK: open-o-tsc.slack.com

f.        Gildas Lanilis was introduced as the OPEN-O Release Manager. 15+ years of experience in telco software development.

g.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Some participants could not join the GoToMeeting meeting due to cap on number of people that can participate. Volunteers were asked to drop off.

                                                             ii.      The team has been borrowing OPNFV tools so far. Linux Foundation will be asked this week to come up with resolution. The group will need a larger conference bridge.

                                                           iii.      All content of the presentations is put on the Wilki.

                                                           iv.      What template to use for the project planning? Please continue using the existing project proposal PowerPoint templates that we have used last week and at our Seed Code meeting. It is posted on the Wiki this week. The Project Lifecycle Document still needs to be written. A rough outline of the release plan is on the Wiki.

                                                             v.      Can we use the ODL template for project planning? OPEN-O projects have slight differences in the information that we need compared to ODL. There are a couple of additional questions related to the architecture that we would like to cover in our project plans. So, please use our existing project plans.

                                                           vi.      To make best use of our time during the planning phase, in tomorrow’s architecture call we will continue to review project proposals and talk about OPNFV MANO project (draft slides available)

2.       Uri E. gave a walk-through some of the open items from last week.

a.       The review is structured in two sections with three types of comments:

                                                               i.      Brief commentary, which project owners/participants need to take a look at and comment

                                                             ii.      Decisions (very few)

                                                           iii.      Open issues where actions are needed (this is the largest category)

b.       Decisions that we agreed are:

                                                               i.      Readjust each proposal’s scope depending on how the whole project comes together.  Coordinate adjustments between different proposals.

                                                             ii.      Creating a long term architecture proposed in parallel (not gating) that will include reference to areas that are out of scope so that we have at least a discussion on how they relate to or impact our projects (examples are OSS/BSS, migration issues, etc.)

                                                           iii.      Each project and the main project will have a document about the “problem being solved”. So that we have the same for the whole OPEN-O project and each sub-project. The individual projects may have to adjust according to the overall problem being solved.

                                                           iv.      For release 1, the drivers are separate will be integrated into respective project of NFVO and SDN-O.

c.       Questions:

                                                               i.      NFV-O was the first sub-project reviewed. But at the same time, this helps address many questions related to the Open-O wide project as well.

                                                             ii.      Started commenting slide-by-slide on Lingli’s project proposal on NFV-O, so that we make sure we are all on the same page and can finalize the project proposal.

                                                           iii.      First Question: Slide# 3 makes a general reference to NS. The O-Commons project also refers to VNF on-boarding. There is also a reference to on-boarding during the design phase.

1.       Question: Are we talking about NS of NFV or are we talking about NS of pNFV, vNFV and the corresponding VNFFG, etc.?

a.       Answer: NFV-O is responsible only for VNF Network Service. The E2E NS that includes VNF and legacy devices, it is to GS-O to do E2E orchestration. 

2.       Question: What do you expect to get? Do you expect to get NSD?

a.       Answer: NFV-O supports 5 different lifecycle management operations (CRUD Operations). Each operation we expect to receive different things. The first operation step is about NS template design. For input to the design you may need software image and a package of NSD, VNFD, VNFFG and other artifacts.

d.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Not all TSC members had received Uri’s email and were not ready to really participate in the discussion.

                                                             ii.      Uri’s email and review was too lengthy to be covered in the TSC meeting. People will review and respond via email. Discussions will follow in smaller teams and continued in the larger TSC meeting only if it concerns the larger end-to-end solution.

                                                           iii.      From the Common TOSCA perspective, there are many integration points between the components. We need to do joint engineering work and shared design to ensure that all touch points and overlaps are covered. Joint design would facilitate proper project planning.

                                                           iv.      We should work on this offline through Wiki, email, SLACK, and other tools. We should work off-line asynchronously. Wiki would be a better choice for this discussion to capture all the documentation. SLACK is more for online discussions. The content on SLACK needs to be copied over to the Wiki.

                                                             v.      Will have follow up design session between various groups. Should each group have these discussions separately? If the integration point is just between two teams, feel free to do it in a smaller group. If it relates the overall project, then bring it to the TSC. Try to make progress over email and if email is not enough, we will have smaller group meetings.

3.       Chris D. gave a walk-through the Wiki pages.

a.       Link is: https://wiki.open-o.org. It is still under development. Use it for new project proposals, for discussions, for alignment between projects, and to share information between different people.

b.       Starting to populate things. The conf bridge info is in the “Meeting Times”.

c.       Release Plan currently just has the milestones. It should become similar to ODL sites, containing much more details.

d.       Kick-off Meeting Outcome contains the resolutions from last week.

e.       Approved Project Page is not populated yet. As we move forward and have more artifacts, we can have individual pages for each project. Those would be pages similar to what Uri created.

f.        The TSC Governance Document page contains the TSC Charter v6 that is approved. This has pdf and full Wiki version.

g.       TSC Policies. We have not reached consensus on yet. Will send out emails this week to the board members to reach consensus.

h.       Project Lifecycle Documents has not been started yet. It will be similar to OPNFV and ODL. ODL defines 4 steps and OPNFV defines 5 steps. We will start with 4 and expand as needed. Volunteers are needed to work on the document.

i.         The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Currently the Wiki registration uses Google services. It will cause problems for people in China

                                                             ii.      Somebody outside of China can do the registration work for people in China. If people in China have problem, first reach out to people from your company outside china. If it does not help, then reach out to Chris for help.

                                                           iii.      Meeting notes shall go to the Wiki as well. There will be a page for TSC meeting and a page for notes by date. People prefer to use Wiki for meeting notes and slack for common discussions.

                                                           iv.      Put project proposal on the Wiki. Feel free to use the Approved Projects page for release plans.

                                                             v.      There is a bottom for watching important pages. Intent to use our calls for the next few weeks for the project proposals and do the document related work through the email list.

                                                           vi.      The self-service link for the mailing list sign up is: http://lists.open-o.org/mailman/listinfo

                                                          vii.      Will add a link to the Wiki for the mailing list sign up.

 

 

1.       Action Items:

a.     Everybody is asked to make sure that their name is added to the TSC and ARC mailing lists. Link is: open-o-technical-formation@...

b.       Everybody to review Uri’s email and provide comments/answers to finalize the project planning

c.       Everybody to familiarize with the Wiki and TSC document

d.       Volunteers are needed to work on the Project lifecycle Document

 

 

 

From: Casem Majd
Sent: Wednesday, June 01, 2016 10:58 PM
To: Casem Majd; open-o-technical-formation@...; Christopher Donley (Chris); Michael McBride
Cc: Marc Cohn
Subject: RE: OPEN-O Architecture Meeting Notes

 

All,

Please find below the notes for this week’s OPEN-O Architecture Meeting.

 

Meeting Venue:  The OPEN-O Architecture Meeting Conference Call took place on Wednesday June 1th, 2016 from 6:30am to 7:55am PST. 27 people from 10 organizations participated.

 

Summary:

1.       Olga presented Four Service Modeling Roles needed for supporting OPEN-O Use Cases. This was a summary report of the Beijing meeting.

a.       Outline of the talk:

                                                               i.      Defined the role of four different “Service Designers” for various layers of OPEN-O service stack; defined the relevant terminology, defined the ownership of descriptors for each layer, and defined the proper abstraction for each layer.

                                                             ii.      Defined the service design use case

b.       Role #1) GS-O Global “Service Designer”

                                                               i.      This is the top most service designer with the end-to-end view

                                                             ii.      It is the Designer for the global Network Service. It understands the end-to-end service at the global layer (business layer?) and manages NSDs in the GS-O service catalogue.

c.       Role #2) NFV-O Network “Service Designer”

                                                               i.      It is the Designer for the Network Service in a specific NFV-O domain. It manages the NSDs for a single NFV-O domain in the NFV-O service catalogue.

d.       Role #3) SDN-O Network Connectivity “Service Designer”             

                                                               i.      It is the Designer for the network connectivity service in the specific SDN-O domain. It manages NCSDs in the SDN-O service catalogue.

e.       Role #4)  “VNFD Designer”

                                                               i.      It is the Designer for VNF Descriptors that can either create new VNFDs or import vendor VNFDs in the VNFD Catalogue.

f.        The ownership of the descriptors (NSD, VNFFGD and VNFD), as well as the level of abstraction and ownership are as follows:

                                                               i.      It is a business decision as to what is owned by GS-O, NFV-O and SDN-O and what needs to be abstracted by NFV-O and SDN-O and what is visible to GS-O.

                                                             ii.      NFV-O and SDN-O ownership of descriptors:

1.       Based on the separation of catalogue into GS-O, NFV-O and SDN-O, the ownership is split based on what is business (GS-O) and what domain/technology policy (NFV-O/SDN-O)

                                                           iii.      NSDs or VNFFGD at the NFV-O layer:

1.       Descriptors needed as they have some additional attributes that must be filled in by service designer and are not present in VNFFGD. Example: designer, version, lifecycle management scripts, deployment flavor, security, etc.

2.       The service descriptors differ by different levels of abstraction, but are based on a shared model.

                                                           iv.      VNFDs visibility at the GS-O layer:

1.       There are different layers, some VNFDs may be visible at GS-O layer (e.g. vCPE business decision), some can be visible at the individual domains (e.g. vFW always by default, or policy, only if it is not business decision). Architecture must be flexible to support different business organizations.

2.       Abstraction at different layers needed, GS-O does not need to be aware of all VNFDs, VNFs and fully expanded forwarding graphs  (VNFFGD and VNFFG)

3.       GS-O has its own abstraction and view of the network service

4.       NFV-O has visibility into the graph for its domain

5.       SDN-O has visibility into all layers of connectivity

e.        The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      There were objections to the use of “Business Layer” for the GS-O layer. OPEN-O is not a BSS. It is n OSS. GS-O deals with customer-oriented services, not the business layer.

                                                             ii.      Are roles #1 and #4 the same? More discussion is needed at the next face-to-face meeting to clarify the roles and details of GS-O. We need to define the functionalities and roles and derive from that the interface requirements for each layer. Need to close differing points of view among the team members.

                                                           iii.      Our design needs to be flexible enough to support different business decisions on ownership.

                                                           iv.      Open questions that need to be discussed at the next meeting:

1.       NFV-O Network Service Designers per NFV-O Domain?

2.       Catalogue per NFV-O Domain?

3.       VNFDs either in the GS-O Domain or NFV-O Domain?

4.       Separate SDN-O designer per technology?

5.       No agreement yet on the terminology for SDN-O descriptors (NSD is used by ETSI, TMF/ONF/MEF uses Specification/ Descriptors/ Templates)

2.       Marc Cohn presented planning for next week face-to-face meetings in Shenzhen

a.       So far, the membership data are as follows:

                                                               i.      Premier Members are CMCC, Huawei, Intel, PCCW and ZTE. Gigaspaces is also very likely.

                                                             ii.      General Members are Canonical, Cloudbase Solutions, Infoblox and Raisecom. RedHat is also very likely.

                                                           iii.      Deadline for submission of membership applications is tonight

                                                           iv.      The official list will be sent Wednesday 2 June to members only.

b.       OPEN-O Kickoff is scheduled for June 7-9 in Shenzhen

                                                               i.      The meeting Venue in The Ritz-Carlton, 116 Fuhua San Road, Futian District Shenzhen 518048, P. R. China.

c.       Refer to Jessie Liu's emails for details on hotel reservations.

                                                               i.      Contact Jessie for help with hotel bookings.

                                                             ii.      Jessie coordinated marketing activities

d.       Agenda is 3-days

                                                               i.      Day 1 (June 7th): Premier Founding Members only

1.       Board Meeting (9am – 1pm)

2.       TSC Meeting (2pm – 5pm)

3.       Board and TSC meeting are non-overlapping to accommodate those individuals who need to be in both

4.       Evening: Board / TSC Dinner (to enable the Board & TSC to get to know one another)

                                                             ii.      Day 2 (June 8th):

1.       Joint Board/TSC meeting to shape responsibilities (open only to Premier Board/TSC members) (morning)

2.       TSC Meeting #2- Assuming TSC passes a motion in advance of TSC #2, this meeting will be open to all (afternoon)

3.       Marketing Meeting #1- In parallel with the TSC Meeting #2

4.       Evening: Social Event to encourage everyone to get to know one another, and celebrate the launch of OPEN-O

                                                           iii.      Day 3 (June 9th):

1.       TSC Meeting #3- As agreed during TSC Meeting #2, assuming TSC passes a motion in advance of TSC #2, this meeting will be open to all

2.       Marketing Meeting #2- As needed, In parallel with the TSC Meeting #2

3.       Breakout session (decide on during the Kickoff; two rooms booked for this purpose)

                                                           iv.      Marc is recording/prioritizing a comprehensive list of Board actions required, to guide the Board meeting agenda

                                                             v.      OPEN-O Governance Document stipulates that Board action is required to approve the nomination/election procedures for: General Member Board Rep, OPEN-O Board Officers (Chairman, Treasurer, and Secretary), and Marketing Chair

                                                           vi.      Marc agreed to verify with the LF the best practices for holding votes and elections prior to the Board meeting

e.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Uri requested that we determine an approach to conduct the General Member Board Rep prior to the Kickoff/Board meeting (so that the new General Member Board Rep can attend the Board meeting)

                                                             ii.      Priority is to ensure that elections happen as soon as possible, but the sequence is complex.

                                                           iii.      We need to find a quick method to elect the general member representative for the Board Of Directors.

                                                           iv.      Received request from Yale University and two Chinese Universities that they are interested to support SDNC and SDNO, and would like to contribute some code to our solution. There is a request to that our kickoff meetings on the 8th and 9th be open for individual contributors to attend the discussions as the associate member. Limit 1 per each university.

                                                             v.      Marc commented that as long as the TSC passes a motion at the first meeting (June 7th) to open up the TSC meetings, which he would expect to pass, then we can invite others interested in participating in the OPEN-O TSC meetings/ technical discussions. We better not make the distribution too broad, as there is a finite limit to the space.

                                                            vi.      Marc proposed that we impose the same limit that we did at the Seed Code Workshop (no more than 6 technical individuals per organization)

 

3.       Chris made a short walk-through the TSC Charter

a.       The OPEN-O TSC Charter is mainly based on ODL Charter

b.       The ODL charter is augmented by OPEN-O specific bylaw

c.       Unique points are the

                                                               i.      TSC subcommittee for the Architecture Team

                                                             ii.      Project roles are different

d.       The charter will be approved at the board meeting

 

 

4.       Action Items:

a.       Marc is working on the agenda for the Board meeting, joint Board/TSC meeting, and Marketing meeting #1

b.       Chris agreed to coordinate with the TSC members on an agenda for the TSC #1 meeting. Chris will prepare a proposal for the TSC agenda. Premier members should help Chris to create the TSC agenda.

c.      For next week’s meeting in Shenzhen, an agenda has been sent to the formation email group. Marc will send additional details this week

d.     Everybody to read and comment on the TSC Charter document. Deadline is next Wednesday (6/8)

 

Regards,

 

Cas

 

From: Casem Majd
Sent: Thursday, May 26, 2016 11:33 AM
To: Casem Majd; open-o-technical-formation@...; Christopher Donley (Chris); Michael McBride
Cc: Marc Cohn
Subject: RE: OPEN-O Architecture Meeting Notes

 

All,

Please find below the notes for this week’s OPEN-O Architecture Meeting.

 

Meeting Venue:  The OPEN-O Architecture Meeting Conference Call took place on Wednesday May 25th, 2016 from 6:30am to 7:30am PST. 22 people from 6 organizations participated.

 

Summary:

2.       Deng Hui (CMCC) presented an assessment of current OPEN-O budget

a.       A breakdown of the current budget has been presented, by

                                                               i.      Marketing

                                                             ii.      Developer collaboration

                                                           iii.      Legal

                                                           iv.      Others

b.       Budget estimation seems to be lower than expected. Suggest going through the budget again. (Consensus)

c.       List of tasks for the next face-to-face meeting on June 6th

                                                               i.      Anti-trust (LF program manager)

                                                             ii.      Election of BoD from general members (LF PM) (to be done before June 6th)

                                                           iii.      Elections for board officers, TSC chairs. (LF PM)

                                                           iv.      Authorization Board and LF about agreement and membership (LF PM)

                                                             v.      Proposal for our project officers based on our budget (Deng Hui Volunteer)

                                                           vi.      Budget  (Volunteer needed)

                                                          vii.      Marketing committee build up (Volunteer needed)

                                                        viii.      User Advisory Group document (Uri, Deng Hui, Marc volunteered)

                                                            ix.      TSC charter (Volunteer needed)

3.       Olga presented the summary report on the OPEN-O discussions from Beijing

a.       Approach 1:

                                                               i.      Use ARIA as bases for GSO and NFVO;

                                                             ii.      China Telecom + CMCC for SDN-O;

b.       Approach 2:

                                                               i.      This approach will be based on micro-services.

                                                             ii.      Take all modules that are in Java (ZTE, Huawei, CMCC) for GSO and NFV-O;

                                                           iii.      Huawei and China Telecom for SDN-O.

                                                           iv.      (GS-O NFV-O and ARIA for the parser in Common Functions)

                                                             v.      Workflow and Catalog under Common Services

c.       Approach 3:

                                                               i.      ManageIQ for GSO and NFV-O

                                                             ii.      Huawei + China Telecom for SDN-O

d.       Approach 1.5: 

                                                               i.      Approach 2 (GSO NFVO) and ARIA for the parser in Common Functions. ZTE for common services.

                                                             ii.      Aria Parser and Execution Engine will be used in GS-O and NFV-O

                                                           iii.      Re-use of Aria Parser and Execution Engine. Aria Parser and Execution Engine in Common-O to be reused by multiple projects.

                                                           iv.      Aria Execution engine will invoke business logic by other partners

                                                             v.      SDN-O REST API will be specified in the GS-O Service Template and the REST request will be sent by Aria execution engine

                                                           vi.      ManageIO will be the VIM and fill in some missing functions. This is the optimum solution to bring as much code as possible.

e.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                          vii.      SDN-O and GS-O interaction. Do not expose TOSCA parser to all details of YANG. Only expose necessary details to TOSCA via REST.

                                                        viii.      Hierarchical layering may be supported in SDN-O.

                                                            ix.      May not use ETSI terminology, but instead using MEF, etc.

                                                             x.      We may need to continue this discussion at the next f2f meeting.

                                                            xi.      The interface between SDN-O and GS-O needs to be defined and solidified for release 1.

                                                          xii.      ManaegIQ was not mentioned in the details. Are there any opportunities to include ManageIQ. Consensus is that ManageIQ can fit into release 1.5 for doing tasks such as discovery, collecting information, monitoring, managing drivers, …

                                                        xiii.      Red Hat to work with GigaSpaces on defining the NBI and integrating to ARIA parser

4.       Jessie gave an update on pre-marketing committee and other marketing activities

a.       Members so far: CMCC, Intel, Huawei, ZTE (still open to other members)

b.       PR for official founding, covering message, high-level architecture, and call for participation.

c.       OPEN-O Mini Summit in Berlin. Agenda proposal.

d.       Submission of presentations for mini summit. Proposed selection criteria are:

                                                               i.      Strong relevance to OPEN-O

                                                             ii.      Attractive to audience

                                                           iii.      Speaker title and impact

e.       Sample suggestions for presentations:

                                                               i.      Invite potential operators to give a speech. 

                                                             ii.      Call on vendors to work with OPEN-O for on boarding

f.        The following considerations, concerns, comments, and questions were raised from the audience:

                                                           iii.      Do we have enough material to fill one-day’s worth of content (Brendan)

                                                           iv.      Code release is in November. We may not be able to disclose much. (Deng)

                                                             v.      How many developers can travel to the event given the short time (Chris)

 

 

Action Items:

1.       Red Hat to work with GigaSpaces on defining integration interface between ARIA and ManageIQ (Dave & Amir)

2.       Identify location of next face-to-face meeting (Marc C)

3.       Add the PR for the list of marketing activities for the mini summit. (Jessie)

4.       Everybody provide comments on the accuracy of OPEN-O description to Jessie (by May 27th)

5.       Call for submission of presentations for the mini summit before May 27th.

6.       Invite AT&T to give speech on ECOMP monitoring and analytics

7.       Election of BoD from general members (LF PM) (to be done before June 6th)

 

Regards,

 

Cas

 

From: Casem Majd
Sent: Friday, May 13, 2016 6:21 PM
To: Casem Majd; open-o-technical-formation@...; Christopher Donley (Chris); Michael McBride
Cc: Marc Cohn
Subject: RE: OPEN-O Architecture Meeting Notes

 

All,

Please find below the notes for this week’s OPEN-O Architecture Meeting. Thanks to Olga and Brendan for their contributions.

 

Meeting Venue:  The OPEN-O Architecture Meeting Conference Call took place on Wednesday May 11th, 2016. Meeting started at 6:30am PST and ended at 9:30am PST (~1.5 hours). 32 people from 8 organizations participated. We had two invited guests from our partner projects MEF LSO and OpenDaylight.

 

Summary:

5.       ManageIQ Presentation & Discussion

a.       Geert Jansen from Red Hat presented ManageIQ Functional Architecture Slides, especially addressing the discussions around MicroServices. The main question discussed was “why ManageIQ does not use MicroServices?”

                                                               i.      ManageIQ was developed using 30-40 years of experience in building management systems

                                                             ii.      ManageIQ does not take the MicroServices approach – It takes a platform approach – platform as a service.

                                                           iii.      To build a rich management platform, Red Hat advocates platform driven approach versus MicroServices approach.

                                                           iv.      A platform-based approach suits management applications that are tightly coupled by data.

                                                             v.      There are several services in the platform; It uses Ruby object model.

                                                           vi.      ManageIQ will be available as a container to aid integration.

                                                          vii.      One single virtual appliance can have 100 copies

                                                        viii.      Appliance can be bound to the region and to zone. They have multiple roles, one or more roles maps to the processes in the appliance

                                                            ix.      Red Hat wants to demonstrate the power of the ManageIQ platform at the OPNFV and show why one would use platform approach versus MicroServices approach – Red Hat is preparing a demo for OPNFV 2016.

b.       The reasons ManageIQ does not use MicroServices are:

                                                               i.      MicroServices is not the right approach for a management platform. MicroServices has some good things – separation (each MicroServices has independent APIs), performance/scale – but it is not the correct architecture. It is not the only way to do things.

                                                             ii.      The ManageIQ Platform got through acquisition and was built before MicroServices time

                                                           iii.      MicroServices approach is still not a well proven approach in the industry. MicroServices have not been proven to be a better architecture than a platform-based approach.

                                                           iv.      Management of resources has special requirements, where we need tighter coupling than in other domains.

                                                             v.      It is not clear that MicroServices can be efficient in Data Model driven systems

                                                           vi.      MicroServices has a large cost, Red Hat believes cost is not worth the benefit

c.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      DengHui – Advocates for MicroServices. MicroServices allow easier integration of components from multiple companies that use diverse technologies. MicroServices facilitates the integration of different components that come from different companies with different code base. ManageIQ is coming late to OPEN-O, and more analysis is needed.

                                                             ii.      Uri – Why would MicroServices be a better approach than other alternatives? How would MicroServices allow easier integration? Is REST the main advantage?

                                                           iii.      DengHui – OpenStack is an example for implementing MicroServices with success. MicroServices allows plug-and-play model, where each module is independent of the message bus, allowing each module to be integrated independently.

                                                           iv.      Geert – OpenStack is impressive, but it took 6-7 years with thousands of developers to develop. MicroServices comes at a cost, not sure if it is justified.

                                                             v.      Dave – Wants to discuss platform versus point-to-point integration more. He prefers platform versus MicroServices, because it will be more costly to define all individual p2p interfaces.

                                                           vi.      DengHui – Some existing code such as Aria needs to be integrated within this year, it cannot work with a platform that is based on another language.

                                                          vii.      Geert – ManageIQ has advantages over Aria. ManageIQ has broader functionality, except for the TOSCA parser. Using multiple languages may not be the fastest way to build a community.

                                                        viii.      Its service model may currently not be ideal but it has a good service catalogue

                                                            ix.      Deng Lingli – ManageIQ is a Cloud Manager, it has major (functional) gaps as an orchestrator. How much effort is needed to use ManageIQ as NFV-O? What effort is needed to fill the gaps?

                                                             x.      Geert – ManageIQ is a generic manager, not just a Cloud Manager. ManageIQ is not ready for use as NFV-O, but the platform provides most of the primitives.

                                                            xi.      ManageIQ has many re-usable components, activation engine, governance, federation, data model, and SDN.

                                                          xii.      The platform can be easily changed to fill any gaps for OPEN-O

                                                        xiii.      Geert – The ManageIQ core team will not be able to attend the Beijing meeting. Please do not make any decisions until you have seen our OPNFV demo.

                                                        xiv.      DengHui – RedHat should propose which module could be used. Red Hat can propose something for the platform driven approach.

                                                          xv.      The ManageIQ issues will be discussed by email. We can discuss more next week in Beijing.

                                                        xvi.      Chris – No decisions will be made at the Beijing meeting. Decisions cannot be made until June when TSC is formed. Meanwhile we can just make suggestions.

 

 

6.       MEF LSO Reference Architecture

a.       Andy Mayer, as a guest participant from a partner project, presented MEF LSO Reference Architecture. His presentation covered the following points:

                                                               i.      History of MEF Lifecycle Service Orchestration Reference Architecture

                                                             ii.      Definition of LSO and LSO RA

                                                           iii.      Drivers-on-Demand and Agile Services

                                                           iv.      Definition of Orchestration

                                                             v.      MEF Engineering Methodology

                                                           vi.      LSO-related MEF activities

                                                          vii.      LSO Reference Architecture

                                                        viii.      LSO Operational Threads

                                                            ix.      LSO Management view abstractions

                                                             x.      Examples of data transferred on each interface

                                                            xi.      LSO example with SDN and NFV

                                                          xii.      LSO RA phase 2 plans

b.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Uri – Which requirements are imposed on controllers by Presto?

                                                             ii.      Andy – We are working with ONF on Presto requirements for Service Chaining. Phase 2 will investigate more use cases and interactions.

                                                           iii.      Amir – GigaSpaces has already demonstrated at the LSO Hackathon the Legato and Presto interfaces using TOSCA. (Demonstrated Legato API using Tosca).

                                                           iv.      Uri – Is the Presto interface defined? How MEF addresses SDN-O and NFV-O – Presto + network functions and network services? There are still discussions whether Service Orchestration goes directly to VNFM or NFVO?

                                                             v.      Andy – An early draft is available.

                                                           vi.      Uri – Has LSO been adopted by any BSS groups?

                                                          vii.      Andy – We are working with open source communities.

                                                        viii.      Olga – Has MEF discussed Presto with ETSI NFV? The question is about Legato vs. ETSI API.

                                                            ix.      Andy – We have been working with ETSI NFV (still work in progress). We hope to develop use cases with ETSI.

7.       Seed Code Meeting Presentation

a.       Chris presented the Seed Code meeting charts, covering the following points:

                                                               i.      Workshop goals

                                                             ii.      Agenda

                                                           iii.      Architecture Map

                                                           iv.      Potential metrics

b.       Chris – We should add 2 new metrics. Ability to deliver this year, and effort needed to fill gaps.

c.       Marc – I have discussed the metrics with Phil Robb from OpenDaylight. Phil can share his expertise.

d.       Phil – The current list looks good. Contributors who have overlaps should discuss differences in functionality and differences in approach. Phil will join us next week in Beijing, he has experience in ODL.

e.       Phil – proposed that those who have multiple seed code contributions to have joint meetings to understand and assess each other’s proposals, overlaps and gaps

f.        Lingli – presented arrangements for the meeting in Beijing. It is important to register at the North gate on the first day.

g.       Geert – The ManageIQ core team will not be able to attend the Beijing meeting next week.

h.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Uri – We need a high-level description of the functionality and the APIs.

                                                             ii.      Chris – We will have sessions in Beijing for detailed discussions.

                                                           iii.      Uri – We need basic definitions of each component. For the proposed functionality and APIs, we need the description and requirements for the OPEN-O blocks, so that we can match OPEN-O requirements to APIs and provided functionality of the contributions

                                                           iv.      Deng Lingli – Each contributor should answer the above questions during their presentation.

                                                             v.      Chris – Each contributor should address all of these metrics.

                                                           vi.      Deng Lingli – We should add a metric for compliance to standards such as ETSI or MEF.

                                                          vii.      Uri – MEF will not be relevant outside SDN.

                                                        viii.      Chris – We can use the email list to discuss which standards may be relevant.

                                                            ix.      Corona Wei or Fengjie – Made some comments about MEF and will share her ideas by email

                                                             x.      Uri – Functionality in each block is still unclear.

                                                            xi.      Dave – It may be good to have a “bake-off” where sample use cases are used to evaluate each contribution.

 

 

Action Items:

8.       Forward the MEF LSO slides to the email list. (Chris D)

9.       Share the current Presto draft. (Andy M)

10.   Send a list of confirmed attendees for next week’s face-to-face meeting in Beijing (Lingli Deng)

11.   Red Hat will not be able to attend Beijing meeting, but they will try to communicate through presentations (Uri E)

12.   Share the slides for the section on “Seed Code Meeting” (Chris D)

13.   Add best practices for code selection (Mark C)

 

Regards,

 

Cas

 

From: Casem Majd
Sent: Thursday, May 05, 2016 2:56 PM
To: Casem Majd; open-o-technical-formation@...; Christopher Donley (Chris); Michael McBride
Cc: Marc Cohn; Casem Majd
Subject: RE: OPEN-O Architecture Meeting Notes

 

All,

Please find below the notes for this week’s OPEN-O Architecture Meeting. Thanks to Dave again for his help.

 

Meeting Venue:  The OPEN-O Architecture Meeting Conference Call took place on Wednesday May 4th, 2016. Meeting started at 6:30am and ended at 7:30am PST. 23 people from 8 organizations participated.

 

Summary:

8.       Review conference participation/feedback (ETSI NFV, OpenStack, MEF, etc.)

                                                   i.      We had an event report from the face-to-face last week at OpenStack Summit

                                                 ii.      Report on ETSI NFV meeting

                                               iii.      Report from MEF

b.      ETSI NFV Update

                                                   i.      Marc C from Linux Foundation mentioned that they had been invited to meet with the ETSI NFV MANO group this week in Atlanta to talk about possible collaboration.

                                                 ii.      ETSI NFV panel went well, which opens the door to further cooperation.

1.       Chris and Marc presented Open-O at the ~150 members ETSI panel (special session on open source orchestration, where OPEN-O and OSM were showcased in a single session)

2.       Additionally, we participated in a panel discussion

                                               iii.      Amir Levy from GigaSpaces presented ARIA hierarchical model-driven orchestrator (TOSCA/YANG). 

                                               iv.      OSM team also presented their story.

                                                 v.      Questions from the ETSI participants around how we plan to use their specs and common information/data models/VNFs.

1.       ETSI is particularly interested in OPEN-O converging on a common Information Model with OSM, and compliance with the ETSI NFV Architectural Framework.

2.       ETSI wants us to provide ETSI NFV IFA-compliant interfaces

                                               vi.      Also questions about participating in standards versus open source.

                                              vii.      Discussed the possibility of convening an OPEN-O/OPNFV/OSM session at the OPNFV Summit in June. ETSI also offered to share a tutorial on the ETSI IFA-defined interfaces.

                                            viii.      AT&T also presented ECOMP earlier in the week.  Marc said that they were hinting that they’re working on an open source strategy, but it didn’t sound like a separate community. They are asking a lot of questions about Open-O. We need to keep engaging with them.

c.       MEF Forum Update

                                                   i.      Brendan H talked about the interest for Open-O that he had encountered at the MEF forum.

                                                 ii.      SDN-O integration is important for the MEF use-cases.

                                               iii.      MEF forum asked a lot of questions about Open-O.

                                               iv.      We will invite MEF to present to the OPEN-O architecture team in May

 

9.       Work Plan

a.       Marc reviewed the plan for the next few weeks. 

b.       Marc is refining the spreadsheet, and will send an update this week.

c.       Several companies announced intention to participate in the face-to-face in Beijing: Intel, Huawei, ZTE, China Mobile, China Telecom, GigaSpaces (maybe others).

d.       Parties are asked to send the seed code map to Chris by 5/10

e.       Parties are asked to register for the event by 5/10

f.        Parties are asked to notify Marc if they are planning to join Open-O, and at what level (even prior to formally signing the membership document). We need to start planning launch activities.

10.   Architecture

a.       HA is put in the “Common Service” box and not the “O-common” box, HA is a common requirement for all the components inside OPEN-O, not only those inside the orchestration layer.

b.       Uri asked about EMS/OSS/BSS interfaces.  Deng Hui referred him to the YouTube video of our OpenStack talk.  We will discuss on a future call.

11.   Discussed preparations for the May 17-19 meeting

a.       Reported on seed code release progress and planning for face-to-face meeting in Beijing

b.       Who is bringing seed code

c.       What are the expectations for companies bringing seed code

d.       Question raised whether there were guidelines on meritocracy of operation

e.       Some organizations feel it is important to understand the meritocracy before the meeting, to inform the discussion and decision process.

12.   Red Hat ManafeIQ Presentation

a.       For the last 15 minutes, Red Hat (Geert Jansen) presented ManageIQ.

b.       Red Hat proposes that ManageIQ

c.       Red Had open sourced this code base in 2014.

d.       Code base started in 2006 and uses the Apace 2.0 license. Code is written in Ruby on Rails.

e.       It is a service catalog for on boarding of VNF

f.        Provisions the VNF via standard provisioning workflows

g.       Support of VNF lifecycle management via service models

h.       Provides event-driven automation via control

i.         Supports delegated control via service model

j.         We did not have a lot of time for questions, but there were a number of people who said that they wanted to follow up with questions.

k.       Agreed to continue the discussion via email.

 

Action Items:

14.   Parties are asked to send the seed code map to Chris by 5/10

15.   Parties are asked to register for the event by 5/10

16.   Parties are asked to notify Marc if they are planning to join Open-O, and at what level

17.   Invite MEF to present at the OPEN-O architecture team in May

 

Regards,

 

Cas

 

From: Casem Majd
Sent: Monday, May 02, 2016 5:36 PM
To: Casem Majd; open-o-technical-formation@...; Christopher Donley (Chris); Michael McBride
Cc: Marc Cohn
Subject: RE: OPEN-O Architecture Meeting Notes

 

All,

Please find below my notes for this week’s OPEN-O Architecture Meeting. Thanks to Dave Neary for his valuable contributions to this week’s meeting notes.

 

Meeting Venue:  The OPEN-O face-to-face Architecture Meeting took place in Austin, TX at the end of the OpenStack Summit on Friday April 29th, 2016. Meeting started at 9:00am and ended at 3:00pm. 18 people from 9 organizations participated.

 

Summary:

1.       Sivan and Arthur B from GigaSpaces presented a tiered or hierarchical service model proposal

a.       The proposed hierarchical model consists of two levels of abstractions

b.       TOSCA is used for the end-to-end service abstraction, with extension nodes that contain YANG models, which are used for the network and device abstraction.

                                                               i.      TOSCA extensions capabilities are used to add new node types and develop a common composite model made from TOSCA, YANG, and other plug-ins

                                                             ii.      The top-level abstraction describes what is needed for the service, and the lower-level abstraction specifies the implementation details of each network component (e.g. YANG models for ODL or ONOS network domains)

                                                           iii.      The model is used to create functions out of building blocks and chain those functions to create services.

                                                           iv.      One example presented: Modeling DNS - node type Bind9, with some connected resources (such as a GW FW, security groups) - some of which are external to the VNF

                                                             v.      The example demonstrates TOSCA as a description language, including its extensibility

                                                           vi.      Relationship between YANG and TOSCA? Sometimes some things are better expressed with YANG, and the proposed solution (ARIA) has a possibility to wrap these pieces in TOSCA to orchestrate

c.       The model covers the service lifecycle, from installation, provisioning, configuration and deployment through monitoring of the application or service in order for the system to take reactive or proactive actions, such as healing and scaling based on custom triggers, or other actions to be performed as part of a lifecycle.

d.       The models come with policy and workflow components. Pre-defined events are specified in the policy templates for certain conditions or threshold violations. The policy defines which events to track, what threshold conditions to watch for, and what corrective actions to take in case of violation of those thresholds. Examples are scale-out based on pre-set capacity utilization thresholds.

                                                               i.      Separation of policy, workflow, and execution/event handling

                                                             ii.      The policy templates specify when to react,

(Policy: If event, then mitigation (start a mitigating workflow))

                                                           iii.      The ensuing workflow specifies the sequence of actions (what to do) to perform in case the policy is violated, and

(Workflow: Actions to be executed - potentially more than one - to apply policy)

                                                           iv.      The implementation logic specifies how to react

(Execution: Event triggers policy execution, which runs through workflow)

e.       The solution would consist of a model parser and an execution engine.

                                                               i.      ARIA is a TOSCA parser and orchestrator. Every time a new node type is added, the parser needs to be aware of them, and validate them.

                                                             ii.      Q: Is it better to have a separation of parser and orchestrator? R: Opinion is that parser and orchestrator are related - similar to UI and model, hard to write a UI without awareness of underlying model

                                                           iii.      Perhaps runtime binding of an alternative orchestrator would be possible

                                                           iv.      Extensive discussion about whether it makes sense to have the parser tied to one orchestrator, and how separation would be possible

                                                             v.      ARIA is open source, and there is a desire of GigaSpaces to have multiple vendors collaborate on it - extension and collaboration could happen in ARIA

f.        The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Need to plug-in to ETSI, and try to define common models that align with ETSI

                                                             ii.      What is the relationship with ETSI NFV MANO? Will there be a common model with the industry? We should align with what is being used in OSM for the information model to converge on an industry norm (best effort attempt).

                                                           iii.      How and to what extend would the proposed models support the complete lifecycle of the service, including model-driven service assurance and inventory schema (allowing new inventory item types to be added dynamically based on models).

                                                           iv.      Is a tiered model necessary for service modeling? Doesn’t it introduce unnecessary complexity? The relevance of the model should be demonstrated with the vCPE use case implementation, and show what was extensions were made to the standard TOSCA or YANG.

2.       Olga H from Huawei reviewed the OPEN-O functional architecture

a.       The team reached consensus on the existing OPEN-O architecture. Minor modifications were made to the architecture diagram, e.g.,

                                                               i.      Adding HA function to the O-Common,

                                                             ii.      Adding EMS/NMS driver to the southbound

b.       Separation of some common services unrelated to Orchestration use-cases (logs, workflow, message bus, etc) and common services with orchestration focus (template management, lifecycle management framework, model driven framework). The main components of the architecture are:

                                                               i.      Common Services, which consist of generic applications that are independent of orchestration. These are system-wide functions.

                                                             ii.      O-Common, which consists of orchestration specific services and functions

                                                           iii.      SDN-O, which provides abstraction for masking network complexities.

                                                           iv.      NFV-O, which models VNFs and applications. It would preferably be aligned with ETSI models.

                                                             v.      What about intent? - intent parsing needs to be in global service orchestration, but also for rendering intents, southbound of SDN-O for the SDN controllers. Consensus is that both SBI and NBI will support intent.

                                                           vi.      As presented, separation of driver layer for different VIMs, SDN controllers, VNFM drivers, which are independent of the model design and resource management layers.

c.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      It is not clear if the software architecture (and its corresponding data model architecture) is aligned with the OPEN-O architecture diagram. This needs more discussion.

                                                             ii.      There is a concern of having to deal with too many modules and too many interface points between them, which would slow us down! Is there a generic VNFM interface?

                                                           iii.      Relationship with Tacker, OPNFV, etc?

                                                           iv.      Using standard open source components for common services, even if there is not a vendor at the table.

3.       The team discussed one open architectural item – HA

a.       How to provide HA? Should it be a platform function or a module-specific function?

b.       We agreed that it belonged as a common function, and updated the architecture diagram accordingly (adding HA to O-Common)

c.       Support of HA would not be within the scope of release 1.

d.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Open-O is going to implement Micro-Service architecture

                                                             ii.      HA and scalability should be common requirement for each micro-service (Perhaps on O-Common - HA service?)

                                                           iii.      HA as a common requirement has the potential consequence that the modules may have to be stateless. More work needs to be done to clarify.

 

4.       The participation at OPNFV Summit has been discussed

a.       China Mobile offers their booth space at the OPNFV Summit in Berlin for free to host the Open-O demos

                                                               i.      There will be a small/narrow space, with 2 demo spaces

                                                             ii.      So far, there are six demos prepared and proposed by different vendors (Red Hat, ZTE, etc.)

                                                           iii.      Intention is to cast the demos into a broader and more consistent story that highlight the main OPEN-O capabilities. It should not be a scattered set of demos. They all should tell a consistent end-to-end storyline.

b.       OPEN-O will be presented at OPNFV for the first time under its own name as an independent entity, and not through any specific organization.

                                                               i.      China Mobile / Huawei will be doing a joint presentation.

c.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Need to finalize the OPNFV demos during the next face-to-face meeting in May 2016.

5.       Discussion on Seed Code contributions

a.       Vibrant discussion on who plans to bring seed code to the May meeting:

                                                               i.      Organizations will be invited to contribute seed code. So that we can make most effective use of the face-to-face, every party will fill up a map that shows to what module it intends to contribute code?

                                                             ii.      Expression of intent for contributing seed code is currently not binding. Partner organizations can declare their intents for contributing code without any concerns about legal obligations. As long as TSC has not been formed, no decision will be made on what code to include and what to exclude to/from the base code.

                                                           iii.      It is preferred for organizations to come to the meeting with open source code. However, if organizations intend to submit open source seed code, but have not cleared their code yet, they may just make presentations at the next meeting in order to avoid legal complications. Organizations should not disclose their code if they don’t have the required open-sourcing approvals.

                                                           iv.      Requirement to open source code in advance of the OPNFV Summit hackfest, but not necessarily in advance of the meeting in Beijing. Marc Cohn confirms that we will not be doing any NDAs or similar - if code is not open sourced, then only publicly available information can be presented.

                                                             v.      Bringing code does not guarantee that the code will be included

                                                           vi.      The team will define the criteria and the meritocracy rules for accepting or rejecting code contributions to the code base. Linux Foundation will share its current Best Practices to all participating organizations. The team will make a group decision based on suggested best practices.

1.       The decision criteria for how seed code will be chosen will be documented before the meeting

b.       Proposed process for consolidating code:

                                                               i.      We will send the detailed architecture diagram to participating organizations and ask how their intended seed code contribution would fit into the OPEN-O module landscape.

                                                             ii.      Organizations will fill up a map that shows to what module they intent to contribute code to.

                                                           iii.      We will create a consolidated mapping table that maps each contributing code to each functional architecture block and identify a leader for each category

                                                           iv.      The goal of this planning is to gather expressions of interest to bring code to the table.

1.       The intent to participate - with an understanding that things will evolve, as we start to work on it, and refine functional block definitions.

                                                             v.      In May, we will discuss, with a level playing field, which components will be part of the initial release

                                                           vi.      The TSC, after formation, will own and validate the architecture and project operation - the architecture discussion group provides input into that discussion

                                                          vii.      Participation will be open - it is possible that people who have not been involved in the formation discussions will participate

                                                        viii.      If people express an intent to join, they can participate in the mailing list and May meeting.

c.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Question whether seed code must be open source? All seed code must be open source before the launch.

 

6.       Preparation for next face-to-face meeting in China from May 17th to May 19th 2016

a.       The review and consolidation of the contributing seed codes is the main objectives of the next face-to-face meeting in May 2016.

                                                               i.      The next face-to-face meeting to be held at China Mobile facilities in Beijing, China from May 17th to May 19th 2016.

                                                             ii.      Place: Meeting Room 908, Level 9th, China Mobile Research Institute, Beijing, China

b.       We will wait to see what code contributions we will receive and then decide how to organize the meeting (structure, number of sessions, mission for each session, etc.)

                                                               i.      The current consensus is to start with an end-to-end architecture session, followed by a set of parallel module-specific code review sessions.

1.       Day 1: Presentation of seed code

2.       Day 2: How we operate as a community, how meritocratic decision making works, and how we make seed code easier to consume

3.       Day 3: Convergence on who will participate in the project at which functional blocks, scope and goals for 1st release

                                                             ii.      There are concerns about

1.       How to coordinate the work between overlapping SDN-O and NFV-O tracks?

2.       How to take the results and consolidate them? How to take and consolidate meeting notes?

                                                           iii.      The final agenda for the May meeting is moved to the mailing list

c.       The goals of the May meeting are:

                                                               i.      Companies participating will have an opportunity to present their seed code, show how they fit into the architecture, and demo their projects

                                                             ii.      Review contributing codes, assess how contributions fit together

                                                           iii.      We will try to resolve conflicts between code which is functionally overlapping

                                                           iv.      Define a realistic scope for release 1

                                                             v.      Create a project plan for TSC

                                                           vi.      Partners should come to the meeting with their USB keys and code.

d.       Before the meeting, create a consolidated mapping table that shows how each contributing code maps to one of the following functional blocks of the architecture and identify a leader for each category:

                                                               i.      SDN-O and its drivers

                                                             ii.      NFV-O and its drivers

                                                           iii.      GS-O

                                                           iv.      Tools / Commons

                                                             v.      We will identify track leaders before the May meeting for break-out sessions on each of the main functional blocks.

e.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      There are certain visa and travel restriction concerns

                                                             ii.      It is understood that the meeting is short notice for some participants. However, the meeting should not be later - because of time pressure for OPNFV.

                                                           iii.      Concern expressed that if we start with a broad and ambitious scope, we will have trouble converging to a first release. We do not want to lock in a plan in May before we have a technical community created and working together. We may be able to start working on seeding project plans in the May meeting, even if it will take a few weeks to get a TSC.

                                                           iv.      Is there a separate track on architecture, planning, components? Someone needs to keep the overall view/big picture in mind

 

7.       Mark C presented the plan of work for the next 3 months

a.       Major milestones were presented

b.       The plan will be distributed next week

c.       Companies to introduce representatives for various committees (TSC, etc.)

d.       Launch planned for June 1st

e.       First Board Meeting in June

f.        First code release for end of year

 

Action Items:

18.   Provide a concrete example (preferable vCPE use case) that shows the need for a 2-level abstraction model (TOSCA-YANG). Show how and why the proposed hierarchical model is superior. And preferably layout the details of a use cases that would benefit from hierarchical TOSCA/YANG models. (GigaSpaces, Arthus B)

19.   Continue the discussion via mailing list on how the proposed model would support complete lifecycle for model-driven service assurance and inventory (Arthus B, Olga H)

20.   Show how to map the proposed models to the OPEN-O architecture diagram (GigaSpaces, Arthur B)

21.   Show more specifically a SBI for legacy EMS/NMS by adding an EMS/NMS driver to the architecture diagram. (Olga H)

22.   Update OPEN-O architecture diagram to include HA function in O-Common box (Chris D)

23.   Identify who in the industry has tools or applications that would fall within the scope of OPEN-O Common Services. The search should also include those companies that are currently not involved in OPEN-O. (Dave N)

24.   Send the detailed architecture diagram to participating organizations to see how their intended seed code contributions would fit into the OPEN-O module landscape. Organizations will fill up a map that shows to what module they intent to contribute code to? (Chris D)

25.   Coordinate the activity for creating a consolidated mapping table that maps each contributing code to each functional architecture blocks and identify a leader for each category; Emails to be sent out by May 3rd for collecting information. Mapping table to be created by May 10th.  (Mark C; Chris D)

26.   In order to define the criteria and the meritocracy rules for accepting or rejecting code contributions to the code base, Linux Foundation will share its current Best Practices by May 5th. Post it on Etherpad. (Mark C)

27.   Organize OPEN-O activities (demos, presentations, etc.) related to OPNFV summit in Berlin. Consolidate the six OPNFV demos into common groups such that they fit into a broader storyline and better highlight core OPEN-O capabilities. Every demo will be mapped to a supporting organization. Create a game plan for the OPNFV demos. (Deng Hui)

28.   Organize the logistics of the next face-to-face meeting in China. List of attendees. Who does what? Define when and where we will meet? (Deng Hui)

29.   Send out instructions on logistics of the May meeting, what to bring to the meeting, rules, etc. (Mark C, Chris D)

1.       Participant to send their information (name, email, phone, and food preferences) to China Mobile

2.       Participants to bring their passport to the meeting. Passport registration is required at China Mobile

3.       Participant to bring their USB keys with code

4.       Organizations to bring their developer experts to the meeting that can present code.

30.   Incorporate latest feedback/corrections to the whitepaper, add a paragraph about how to interact with OSS/BSS, and release the 5th version of the Whitepaper to Linux Foundation for final editing and publication. Each company has to provide an author name for the whitepaper. (Cas M; Harshad T; Deng Hui)

31.   Invite MEF to make an LSO presentation at one of our OPEN-O architecture meetings. Focus on describing what is LSO and how does it relate to OPEN-O? (Chris D)

 

Regards,

 

Cas

 

From: Casem Majd
Sent: Thursday, April 21, 2016 10:48 AM
To: open-o-technical-formation@...; Christopher Donley (Chris)
Cc: Casem Majd; Marc Cohn
Subject: OPEN-O Architecture Meeting Notes

 

All,

Please find below the notes for this week’s OPEN-O Architecture Meeting.

 

Meeting Venue: OPEN-O Architecture Conference Call on Wednesday April 20th, 2016

 

Summary:

1.       Marc Cohn went through the current launch details.  The charter and membership agreement have been sent out for review. Prospective members must return signed documents by June 1 to be considered founders.  The launch date will be June 1.

2.       Plan of work:

a.       Chris, Marc, and Chengli will create a (2-3 month) plan document for pre-launch activities, which will encompass the timeline and ownership of the following milestones, formation documents, tasks, and launch items;

                                                               i.      Official launch

                                                             ii.      Founding Member review and

                                                           iii.      User Advisory Group

                                                           iv.      Targeted recruitment

                                                             v.      Design and sign-off of a Logo

                                                           vi.      Design and launch of the Web site

                                                          vii.      Brief and white paper publication

                                                        viii.      Target architecture

                                                            ix.      Coordinated release of seed code

b.       The 2-page Brief is a pre-formation document, not an official document. LF to be the official author to make its publication easier.

c.       LF compiled draft of Formation Committee and Membership Agreement; Date of joining is early May, which is moved to June 1st so that additional members can sign up.

                                                               i.      Membership Agreements have been sent out to some

                                                             ii.      Founding Members to be formed

d.       LF to issue PR with Founding Members later in May. Being reviewed and collecting executive quotes form member organizations.

e.       User Advisory Group has to be formed before official formation (End User Group?)

3.       Release of seed code

a.       Huawei seed code going through final internal approval and should be released to git in mid May (quietly). It will be publicly announced in June, coordinated with other partners. The seed code is currently available for review under NDA

b.       China Mobile also will release seed code; Date not confirmed!

c.       China Mobile suggests having an informal 2-3 days of seed code review in mid May in China. The topic will be taken to mailing list to gain critical mass and finalize time and location.

4.       Plan to finalize the target architecture and use cases (cloud VPN and model stacks) at the face-to-face meeting in Austin, TX

5.       OPEN-O Whitepaper:

a.       The current 4th version of the whitepaper to be sent out for review on 4/20.

b.       Whitepaper will be handed off to Marc for final editorial review.  Publication will be timed to support the Open-O launch (target- Mid-May).

c.       Publication of the whitepaper will be put up after signing of Joining Agreement and formation of Founding Members.

d.       The final version will include Founding Members’ names as contributors.

6.       The following module names were agreed for OPEN-O: GS-O (Global Service Orchestrator); SDN-O; and NFV-O. The name NFV-O is maintained to show alignment with ETSI.

7.       Olga had a short discussion on the model stack.

a.       China Telecom to add a SDN controller for the enterprise in the Cloud VPN use case

b.       Open questions:

                                                               i.      Which module decides on VNFs: the NFV-O or the GS-O?

                                                             ii.      Which module owns SFC: the SDN-O or the NFV-O?

c.       China Telecom will send more details on underlay versus overlay connectivity and their orchestration

d.       Use cases to be finalized at next week’s architecture meeting. The discussion to be continued via mailing list.

8.       Members were asked to provide feedback on the agenda of next week’s face-to-face meeting. The agenda is on Etherpath. https://openo-arch.titanpad.com/4

 

 

Action Items:

32.  Chris, Marc, and Chengli will create a plan document for the next three months.

33.  Incorporate community feedback and release the 5th version of the White Paper by mid May.

34.  Define the when and where of 2-3 days long seed code review meeting (mailing list)

35.  Gigaspaces will present on data modeling at the face-to-face meeting

36.  China Telecom use case to be finalized by 4/29.

37.  Each company to provide an author name for the whitepaper

38.  Qiong Sun to send specific details on the Cloud VPN use case for the whitepaper

39.  Next week’s face-to-face meeting will be in Austin, TX (at OpenStack Summit) on Friday 4/29

 

 

Regards,

 

Cas

 

--
You received this message because you are subscribed to the Google Groups "open-o-technical-formation" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-o-technical-formation+unsubscribe@....
To post to this group, send email to open-o-technical-formation@....
To view this discussion on the web visit https://groups.google.com/a/linuxfoundation.org/d/msgid/open-o-technical-formation/B32AAC004DC2B941B1641BF9F8FA7398013E75FE%40dfweml501-mbx.


邓灵莉 <denglingli@...>
 

Thank you Chris.

Hi Gildas, welcome on board. Looking forward to working with you.


Lingli/邓灵莉


中国移动通信研究院

denglingli@...


----邮件原文----
发件人:"Christopher Donley (Chris)" <Christopher.Donley@...>
收件人:Lingli Deng  <denglingli@...>,Casem Majd <cas.majd@...>,Gildas Lanilis  <gildas.lanilis@...>
抄 送: 'Marc Cohn' <mcohn@...>,Michael McBride <Michael.McBride@...>,"openo-discuss@..." <openo-discuss@...>,"openo-tsc@..." <openo-tsc@...>,"open-o-technical-formation@..." <open-o-technical-formation@...>
发送时间:2016-06-15 21:08:28
主题:RE: OPEN-O Architecture Meeting Notes

   

Thanks Lingli.  Let me put you in touch with Gildas Lanilis, our new Release Manager, who is taking the lead on the Project Lifecycle document.

 

Chris

 

From: Lingli Deng [mailto:denglingli@...]
Sent: Tuesday, June 14, 2016 9:25 PM
To: Casem Majd; Christopher Donley (Chris)
Cc: 'Marc Cohn'; Michael McBride; openo-discuss@...; openo-tsc@...; open-o-technical-formation@...
Subject: RE: OPEN-O Architecture Meeting Notes

 

Hi Cas,

 

Thanks for taking the notes.

 

Chris, I volunteer working on the project life cycle document draft for further TSC discussion.

 

Thanks and Regards,

Lingli

 

From: open-o-technical-formation@... [mailto:open-o-technical-formation@...] On Behalf Of Casem Majd
Sent: 2016615 10:37
To: Casem Majd <cas.majd@...>; open-o-technical-formation@...; Christopher Donley (Chris) <Christopher.Donley@...>; Michael McBride <Michael.McBride@...>; openo-tsc@...; openo-discuss@...
Cc: Marc Cohn <mcohn@...>
Subject: RE: OPEN-O Architecture Meeting Notes

 

All,

Please find below the notes for this week’s OPEN-O TSC Meeting. Note that starting this week, the Technical Steering Committee (TSC) and the Architecture Committee (ARC) conduct separate meetings, on Tuesdays and  Wednesdays respectively. This is the report for the TSC meeting.

 

TSC Meeting Venue:  The OPEN-O TSC Meeting Conference Call took place on Tuesday June 14th, 2016 from 7:00am to 8:00am PST. 30 people from 7 organizations participated.

 

Summary:

1.       Chris D. gave a summary report on last week’s achievements, reviewed open items (Uri’s email), gave a walk-through the Wiki tools, and discussed the process for developing governance and  policy documents.

a.       Charter has been approved and is posted on Wiki. The Charter governs our behavior as the TSC, defines officers and describes the organizational structure.

b.       Elections held with following results:

                                                               i.      Chris Donley was elected at Chair of the TSC.  

                                                             ii.      Uri Elzur as the Chair of Architecture Committee group and Vice Chair of the TSC.

                                                           iii.      Voted to open the TSC meetings to everyone in community with the exception of executive sessions, which will be made know in advance.

                                                           iv.      The TSC members may delegate alternatives in case the voting TSC member cannot attend

c.       Release Plan discussed and posted on Wiki

                                                               i.      Targeting release end of 2016

                                                             ii.      Internal release date set for Nov 3rd; this date will not be publicized externally. We are looking for additional feedback from board on both the release plan and the use case. So the release date may change in near  future.

d.       Four projects proposal have been approved. There were open items on each project proposal. Uri has been documenting those open items in an email.

                                                               i.      NFV-O

                                                             ii.      SDN-O

                                                           iii.      GS-O

                                                           iv.      Common Service

                                                             v.      Two additional project proposals are in the pipeline that will be reviewed in coming weeks when we do the planning process through the remainder of this month.

e.       SLACK tool is a conferencing note taking for the community. People feel free to take notes and conduct discussions on the SLACK.

                                                               i.      Link for SLACK: open-o-tsc.slack.com

f.        Gildas Lanilis was introduced as the OPEN-O Release Manager. 15+ years of experience in telco software development.

g.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Some participants could not join the GoToMeeting meeting due to cap on number of people that can participate. Volunteers were asked to drop off.

                                                             ii.      The team has been borrowing OPNFV tools so far. Linux Foundation will be asked this week to come up with resolution. The group will need a larger conference bridge.

                                                           iii.      All content of the presentations is put on the Wilki.

                                                           iv.      What template to use for the project planning? Please continue using the existing project proposal PowerPoint templates that we have used last week and at our Seed Code meeting. It is posted on the Wiki this week. The Project  Lifecycle Document still needs to be written. A rough outline of the release plan is on the Wiki.

                                                             v.      Can we use the ODL template for project planning? OPEN-O projects have slight differences in the information that we need compared to ODL. There are a couple of additional questions related to the architecture that we would  like to cover in our project plans. So, please use our existing project plans.

                                                           vi.      To make best use of our time during the planning phase, in tomorrow’s architecture call we will continue to review project proposals and talk about OPNFV MANO project (draft slides available)

2.       Uri E. gave a walk-through some of the open items from last week.

a.       The review is structured in two sections with three types of comments:

                                                               i.      Brief commentary, which project owners/participants need to take a look at and comment

                                                             ii.      Decisions (very few)

                                                           iii.      Open issues where actions are needed (this is the largest category)

b.       Decisions that we agreed are:

                                                               i.      Readjust each proposal’s scope depending on how the whole project comes together.  Coordinate adjustments between different proposals.

                                                             ii.      Creating a long term architecture proposed in parallel (not gating) that will include reference to areas that are out of scope so that we have at least a discussion on how they relate to or impact our projects (examples are  OSS/BSS, migration issues, etc.)

                                                           iii.      Each project and the main project will have a document about the “problem being solved”. So that we have the same for the whole OPEN-O project and each sub-project. The individual projects may have to adjust according to the  overall problem being solved.

                                                           iv.      For release 1, the drivers are separate will be integrated into respective project of NFVO and SDN-O.

c.       Questions:

                                                               i.      NFV-O was the first sub-project reviewed. But at the same time, this helps address many questions related to the Open-O wide project as well.

                                                             ii.      Started commenting slide-by-slide on Lingli’s project proposal on NFV-O, so that we make sure we are all on the same page and can finalize the project proposal.

                                                           iii.      First Question: Slide# 3 makes a general reference to NS. The O-Commons project also refers to VNF on-boarding. There is also a reference to on-boarding during the design phase.

1.       Question: Are we talking about NS of NFV or are we talking about NS of pNFV, vNFV and the corresponding VNFFG, etc.?

a.       Answer: NFV-O is responsible only for VNF Network Service. The E2E NS that includes VNF and legacy devices, it is to GS-O to do E2E orchestration. 

2.       Question: What do you expect to get? Do you expect to get NSD?

a.       Answer: NFV-O supports 5 different lifecycle management operations (CRUD Operations). Each operation we expect to receive different things. The first operation step is about NS template design. For input to the design you may  need software image and a package of NSD, VNFD, VNFFG and other artifacts.  

d.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Not all TSC members had received Uri’s email and were not ready to really participate in the discussion.

                                                             ii.      Uri’s email and review was too lengthy to be covered in the TSC meeting. People will review and respond via email. Discussions will follow in smaller teams and continued in the larger TSC meeting only if it concerns the larger  end-to-end solution.

                                                           iii.      From the Common TOSCA perspective, there are many integration points between the components. We need to do joint engineering work and shared design to ensure that all touch points and overlaps are covered. Joint design would  facilitate proper project planning.

                                                           iv.      We should work on this offline through Wiki, email, SLACK, and other tools. We should work off-line asynchronously. Wiki would be a better choice for this discussion to capture all the documentation. SLACK is more for online  discussions. The content on SLACK needs to be copied over to the Wiki.

                                                             v.      Will have follow up design session between various groups. Should each group have these discussions separately? If the integration point is just between two teams, feel free to do it in a smaller group. If it relates the overall  project, then bring it to the TSC. Try to make progress over email and if email is not enough, we will have smaller group meetings.

3.       Chris D. gave a walk-through the Wiki pages.

a.       Link is: https://wiki.open-o.org. It is still under development. Use it for new project proposals, for discussions, for alignment between projects, and to share information between different  people.

b.       Starting to populate things. The conf bridge info is in the “Meeting Times”.

c.       Release Plan currently just has the milestones. It should become similar to ODL sites, containing much more details.

d.       Kick-off Meeting Outcome contains the resolutions from last week.

e.       Approved Project Page is not populated yet. As we move forward and have more artifacts, we can have individual pages for each project. Those would be pages similar to what Uri created.

f.        The TSC Governance Document page contains the TSC Charter v6 that is approved. This has pdf and full Wiki version.

g.       TSC Policies. We have not reached consensus on yet. Will send out emails this week to the board members to reach consensus.

h.       Project Lifecycle Documents has not been started yet. It will be similar to OPNFV and ODL. ODL defines 4 steps and OPNFV defines 5 steps. We will start with 4 and expand as needed. Volunteers are needed to work on the document.

i.         The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Currently the Wiki registration uses Google services. It will cause problems for people in China

                                                             ii.      Somebody outside of China can do the registration work for people in China. If people in China have problem, first reach out to people from your company outside china. If it does not help, then reach out to Chris for help.

                                                           iii.      Meeting notes shall go to the Wiki as well. There will be a page for TSC meeting and a page for notes by date. People prefer to use Wiki for meeting notes and slack for common discussions.

                                                           iv.      Put project proposal on the Wiki. Feel free to use the Approved Projects page for release plans.

                                                             v.      There is a bottom for watching important pages. Intent to use our calls for the next few weeks for the project proposals and do the document related work through the email list.

                                                           vi.      The self-service link for the mailing list sign up is: http://lists.open-o.org/mailman/listinfo

                                                          vii.      Will add a link to the Wiki for the mailing list sign up.

 

 

1.       Action Items:

a.     Everybody is asked to make sure that their name is added to the TSC and ARC mailing lists. Link is: open-o-technical-formation@...

b.       Everybody to review Uri’s email and provide comments/answers to finalize the project planning

c.       Everybody to familiarize with the Wiki and TSC document

d.       Volunteers are needed to work on the Project lifecycle Document

 

 

 

From: Casem Majd
Sent: Wednesday, June 01, 2016 10:58 PM
To: Casem Majd; open-o-technical-formation@...; Christopher Donley (Chris); Michael McBride
Cc: Marc Cohn
Subject: RE: OPEN-O Architecture Meeting Notes

 

All,

Please find below the notes for this week’s OPEN-O Architecture Meeting.

 

Meeting Venue:  The OPEN-O Architecture Meeting Conference Call took place on Wednesday June 1th, 2016 from 6:30am to 7:55am PST. 27 people from 10 organizations  participated.

 

Summary:

1.       Olga presented Four Service Modeling Roles needed for supporting OPEN-O Use Cases. This was a summary report of the Beijing meeting.

a.       Outline of the talk:

                                                               i.      Defined the role of four different “Service Designers” for various layers of OPEN-O service stack; defined the relevant terminology, defined the ownership of descriptors  for each layer, and defined the proper abstraction for each layer.

                                                             ii.      Defined the service design use case

b.       Role #1) GS-O Global “Service Designer”

                                                               i.      This is the top most service designer with the end-to-end view

                                                             ii.      It is the Designer for the global Network Service. It understands the end-to-end service at the global layer (business layer?) and manages NSDs  in the GS-O service catalogue.

c.       Role #2) NFV-O Network “Service Designer”

                                                               i.      It is the Designer for the Network Service in a specific NFV-O domain. It manages the NSDs for a single NFV-O domain in the NFV-O service catalogue.

d.       Role #3) SDN-O Network Connectivity “Service Designer”             

                                                               i.      It is the Designer for the network connectivity service in the specific SDN-O domain. It manages NCSDs in the SDN-O service catalogue.

e.       Role #4)  “VNFD Designer”

                                                               i.      It is the Designer for VNF Descriptors that can either create new VNFDs or import vendor VNFDs in the VNFD Catalogue.

f.        The ownership of the descriptors (NSD, VNFFGD and VNFD), as well as the level of abstraction and ownership are as follows:

                                                               i.      It is a business decision as to what is owned by GS-O, NFV-O and SDN-O and what needs to be abstracted by NFV-O and SDN-O and what is visible to GS-O.

                                                             ii.      NFV-O and SDN-O ownership of descriptors:

1.       Based on the separation of catalogue into GS-O, NFV-O and SDN-O, the ownership is split based on what is business (GS-O) and what domain/technology policy (NFV-O/SDN-O)

                                                           iii.      NSDs or VNFFGD at the NFV-O layer:

1.       Descriptors needed as they have some additional attributes that must be filled in by service designer and are not present in VNFFGD. Example: designer, version, lifecycle management scripts, deployment flavor, security, etc.

2.       The service descriptors differ by different levels of abstraction, but are based on a shared model.

                                                           iv.      VNFDs visibility at the GS-O layer:

1.       There are different layers, some VNFDs may be visible at GS-O layer (e.g. vCPE business decision), some can be visible at the individual domains (e.g. vFW always by default, or policy, only if it is not business decision). Architecture  must be flexible to support different business organizations.

2.       Abstraction at different layers needed, GS-O does not need to be aware of all VNFDs, VNFs and fully expanded forwarding graphs  (VNFFGD and VNFFG)

3.       GS-O has its own abstraction and view of the network service

4.       NFV-O has visibility into the graph for its domain

5.       SDN-O has visibility into all layers of connectivity

e.        The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      There were objections to the use of “Business Layer” for the GS-O layer. OPEN-O is not a BSS. It is n OSS. GS-O deals with customer-oriented services, not the business layer.

                                                             ii.      Are roles #1 and #4 the same? More discussion is needed at the next face-to-face meeting to clarify the roles and details of GS-O. We need to define the functionalities and roles and derive from that the interface requirements  for each layer. Need to close differing points of view among the team members.

                                                           iii.      Our design needs to be flexible enough to support different business decisions on ownership.

                                                           iv.      Open questions that need to be discussed at the next meeting:

1.       NFV-O Network Service Designers per NFV-O Domain?

2.       Catalogue per NFV-O Domain?

3.       VNFDs either in the GS-O Domain or NFV-O Domain?

4.       Separate SDN-O designer per technology?

5.       No agreement yet on the terminology for SDN-O descriptors (NSD is used by ETSI, TMF/ONF/MEF uses Specification/ Descriptors/ Templates)

2.       Marc Cohn presented planning for next week face-to-face meetings in Shenzhen

a.       So far, the membership data are as follows:

                                                               i.      Premier Members are CMCC, Huawei, Intel, PCCW and ZTE. Gigaspaces is also very likely.

                                                             ii.      General Members are Canonical, Cloudbase Solutions, Infoblox and Raisecom. RedHat is also very likely.

                                                           iii.      Deadline for submission of membership applications is tonight

                                                           iv.      The official list will be sent Wednesday 2 June to members only.

b.       OPEN-O Kickoff is scheduled for June 7-9 in Shenzhen

                                                               i.      The meeting Venue in The Ritz-Carlton, 116 Fuhua San Road, Futian District Shenzhen 518048, P. R. China.

c.       Refer to Jessie Liu's emails for details on hotel reservations.

                                                               i.      Contact Jessie for help with hotel bookings.

                                                             ii.      Jessie coordinated marketing activities

d.       Agenda is 3-days

                                                               i.      Day 1 (June 7th): Premier Founding Members only

1.       Board Meeting (9am – 1pm)

2.       TSC Meeting (2pm – 5pm)

3.       Board and TSC meeting are non-overlapping to accommodate those individuals who need to be in both

4.       Evening: Board / TSC Dinner (to enable the Board & TSC to get to know one another)

                                                             ii.      Day 2 (June 8th):

1.       Joint Board/TSC meeting to shape responsibilities (open only to Premier Board/TSC members) (morning)

2.       TSC Meeting #2- Assuming TSC passes a motion in advance of TSC #2, this meeting will be open to all (afternoon)

3.       Marketing Meeting #1- In parallel with the TSC Meeting #2

4.       Evening: Social Event to encourage everyone to get to know one another, and celebrate the launch of OPEN-O

                                                           iii.      Day 3 (June 9th):

1.       TSC Meeting #3- As agreed during TSC Meeting #2, assuming TSC passes a motion in advance of TSC #2, this meeting will be open to all

2.       Marketing Meeting #2- As needed, In parallel with the TSC Meeting #2

3.       Breakout session (decide on during the Kickoff; two rooms booked for this purpose)

                                                           iv.      Marc is recording/prioritizing a comprehensive list of Board actions required, to guide the Board meeting agenda

                                                             v.      OPEN-O Governance Document stipulates that Board action is required to approve the nomination/election procedures for: General Member Board Rep, OPEN-O Board Officers (Chairman, Treasurer, and Secretary), and Marketing Chair

                                                           vi.      Marc agreed to verify with the LF the best practices for holding votes and elections prior to the Board meeting

e.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Uri requested that we determine an approach to conduct the General Member Board Rep prior to the Kickoff/Board meeting (so that the new General Member Board Rep can attend the Board meeting)

                                                             ii.      Priority is to ensure that elections happen as soon as possible, but the sequence is complex.

                                                           iii.      We need to find a quick method to elect the general member representative for the Board Of Directors.

                                                           iv.      Received request from Yale University and two Chinese Universities that they are interested to support SDNC and SDNO, and would like to contribute some code to our solution. There is a request to that our kickoff meetings on  the 8th and 9th be open for individual contributors to attend the discussions as the associate member. Limit 1 per each university.

                                                             v.      Marc commented that as long as the TSC passes a motion at the first meeting (June 7th) to open up the TSC meetings, which he would expect to pass, then we can invite others interested in participating in the OPEN-O  TSC meetings/ technical discussions. We better not make the distribution too broad, as there is a finite limit to the space.

                                                            vi.      Marc proposed that we impose the same limit that we did at the Seed Code Workshop (no more than 6 technical individuals per organization)

 

3.       Chris made a short walk-through the TSC Charter

a.       The OPEN-O TSC Charter is mainly based on ODL Charter

b.       The ODL charter is augmented by OPEN-O specific bylaw

c.       Unique points are the

                                                               i.      TSC subcommittee for the Architecture Team

                                                             ii.      Project roles are different

d.       The charter will be approved at the board meeting

 

 

4.       Action Items:

a.       Marc is working on the agenda for the Board meeting, joint Board/TSC meeting, and Marketing meeting #1

b.       Chris agreed to coordinate with the TSC members on an agenda for the TSC #1 meeting. Chris will prepare a proposal for the TSC agenda. Premier members should help Chris to create the TSC agenda.

c.      For next week’s meeting in Shenzhen, an agenda has been sent to the formation email group. Marc will send additional details this week

d.     Everybody to read and comment on the TSC Charter document. Deadline is next Wednesday (6/8)

 

Regards,

 

Cas

 

From: Casem Majd
Sent: Thursday, May 26, 2016 11:33 AM
To: Casem Majd; open-o-technical-formation@...; Christopher Donley (Chris); Michael McBride
Cc: Marc Cohn
Subject: RE: OPEN-O Architecture Meeting Notes

 

All,

Please find below the notes for this week’s OPEN-O Architecture Meeting.

 

Meeting Venue:  The OPEN-O Architecture Meeting Conference Call took place on Wednesday May 25th, 2016 from 6:30am to 7:30am PST. 22 people from 6 organizations  participated.

 

Summary:

2.       Deng Hui (CMCC) presented an assessment of current OPEN-O budget

a.       A breakdown of the current budget has been presented, by

                                                               i.      Marketing

                                                             ii.      Developer collaboration

                                                           iii.      Legal

                                                           iv.      Others

b.       Budget estimation seems to be lower than expected. Suggest going through the budget again. (Consensus)

c.       List of tasks for the next face-to-face meeting on June 6th

                                                               i.      Anti-trust (LF program manager)

                                                             ii.      Election of BoD from general members (LF PM) (to be done before June 6th)

                                                           iii.      Elections for board officers, TSC chairs. (LF PM)

                                                           iv.      Authorization Board and LF about agreement and membership (LF PM)

                                                             v.      Proposal for our project officers based on our budget (Deng Hui Volunteer)

                                                           vi.      Budget  (Volunteer needed)

                                                          vii.      Marketing committee build up (Volunteer needed)

                                                        viii.      User Advisory Group document (Uri, Deng Hui, Marc volunteered)

                                                            ix.      TSC charter (Volunteer needed)

3.       Olga presented the summary report on the OPEN-O discussions from Beijing

a.       Approach 1:

                                                               i.      Use ARIA as bases for GSO and NFVO;

                                                             ii.      China Telecom + CMCC for SDN-O;

b.       Approach 2:

                                                               i.      This approach will be based on micro-services.  

                                                             ii.      Take all modules that are in Java (ZTE, Huawei, CMCC) for GSO and NFV-O;

                                                           iii.      Huawei and China Telecom for SDN-O.

                                                           iv.      (GS-O NFV-O and ARIA for the parser in Common Functions)

                                                             v.      Workflow and Catalog under Common Services

c.       Approach 3:

                                                               i.      ManageIQ for GSO and NFV-O

                                                             ii.      Huawei + China Telecom for SDN-O

d.       Approach 1.5: 

                                                               i.      Approach 2 (GSO NFVO) and ARIA for the parser in Common Functions. ZTE for common services.

                                                             ii.      Aria Parser and Execution Engine will be used in GS-O and NFV-O

                                                           iii.      Re-use of Aria Parser and Execution Engine. Aria Parser and Execution Engine in Common-O to be reused by multiple projects.

                                                           iv.      Aria Execution engine will invoke business logic by other partners

                                                             v.      SDN-O REST API will be specified in the GS-O Service Template and the REST request will be sent by Aria execution engine

                                                           vi.      ManageIO will be the VIM and fill in some missing functions. This is the optimum solution to bring as much code as possible.

e.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                          vii.      SDN-O and GS-O interaction. Do not expose TOSCA parser to all details of YANG. Only expose necessary details to TOSCA via REST.

                                                        viii.      Hierarchical layering may be supported in SDN-O.

                                                            ix.      May not use ETSI terminology, but instead using MEF, etc.

                                                             x.      We may need to continue this discussion at the next f2f meeting.

                                                            xi.      The interface between SDN-O and GS-O needs to be defined and solidified for release 1.

                                                          xii.      ManaegIQ was not mentioned in the details. Are there any opportunities to include ManageIQ. Consensus is that ManageIQ can fit into release 1.5 for doing tasks such as discovery, collecting information, monitoring, managing  drivers, …

                                                        xiii.      Red Hat to work with GigaSpaces on defining the NBI and integrating to ARIA parser

4.       Jessie gave an update on pre-marketing committee and other marketing activities

a.       Members so far: CMCC, Intel, Huawei, ZTE (still open to other members)

b.       PR for official founding, covering message, high-level architecture, and call for participation.

c.       OPEN-O Mini Summit in Berlin. Agenda proposal.

d.       Submission of presentations for mini summit. Proposed selection criteria are:

                                                               i.      Strong relevance to OPEN-O

                                                             ii.      Attractive to audience

                                                           iii.      Speaker title and impact

e.       Sample suggestions for presentations:

                                                               i.      Invite potential operators to give a speech.   

                                                             ii.      Call on vendors to work with OPEN-O for on boarding

f.        The following considerations, concerns, comments, and questions were raised from the audience:

                                                           iii.      Do we have enough material to fill one-day’s worth of content (Brendan)

                                                           iv.      Code release is in November. We may not be able to disclose much. (Deng)

                                                             v.      How many developers can travel to the event given the short time (Chris)

 

 

Action Items:

1.       Red Hat to work with GigaSpaces on defining integration interface between ARIA and ManageIQ (Dave & Amir)

2.       Identify location of next face-to-face meeting (Marc C)

3.       Add the PR for the list of marketing activities for the mini summit. (Jessie)

4.       Everybody provide comments on the accuracy of OPEN-O description to Jessie (by May 27th)

5.       Call for submission of presentations for the mini summit before May 27th.

6.       Invite AT&T to give speech on ECOMP monitoring and analytics

7.       Election of BoD from general members (LF PM) (to be done before June 6th)

 

Regards,

 

Cas

 

From: Casem Majd
Sent: Friday, May 13, 2016 6:21 PM
To: Casem Majd; open-o-technical-formation@...; Christopher Donley (Chris); Michael McBride
Cc: Marc Cohn
Subject: RE: OPEN-O Architecture Meeting Notes

 

All,

Please find below the notes for this week’s OPEN-O Architecture Meeting. Thanks to Olga and Brendan for their contributions.

 

Meeting Venue:  The OPEN-O Architecture Meeting Conference Call took place on Wednesday May 11th, 2016. Meeting started at 6:30am PST and ended at 9:30am PST (~1.5  hours). 32 people from 8 organizations participated. We had two invited guests from our partner projects MEF LSO and OpenDaylight.

 

Summary:

5.       ManageIQ Presentation & Discussion

a.       Geert Jansen from Red Hat presented ManageIQ Functional Architecture Slides, especially addressing the discussions around MicroServices. The main question discussed was “why ManageIQ does not use MicroServices?”

                                                               i.      ManageIQ was developed using 30-40 years of experience in building management systems

                                                             ii.      ManageIQ does not take the MicroServices approach – It takes a platform approach – platform as a service.

                                                           iii.      To build a rich management platform, Red Hat advocates platform driven approach versus MicroServices approach.

                                                           iv.      A platform-based approach suits management applications that are tightly coupled by data.

                                                             v.      There are several services in the platform; It uses Ruby object model.

                                                           vi.      ManageIQ will be available as a container to aid integration.

                                                          vii.      One single virtual appliance can have 100 copies

                                                        viii.      Appliance can be bound to the region and to zone. They have multiple roles, one or more roles maps to the processes in the appliance

                                                            ix.      Red Hat wants to demonstrate the power of the ManageIQ platform at the OPNFV and show why one would use platform approach versus MicroServices approach – Red Hat is preparing a demo for OPNFV 2016.

b.       The reasons ManageIQ does not use MicroServices are:

                                                               i.      MicroServices is not the right approach for a management platform. MicroServices has some good things – separation (each MicroServices has independent APIs), performance/scale – but it is not the correct architecture. It is  not the only way to do things.

                                                             ii.      The ManageIQ Platform got through acquisition and was built before MicroServices time

                                                           iii.      MicroServices approach is still not a well proven approach in the industry. MicroServices have not been proven to be a better architecture than a platform-based approach.

                                                           iv.      Management of resources has special requirements, where we need tighter coupling than in other domains.

                                                             v.      It is not clear that MicroServices can be efficient in Data Model driven systems

                                                           vi.      MicroServices has a large cost, Red Hat believes cost is not worth the benefit

c.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      DengHui – Advocates for MicroServices. MicroServices allow easier integration of components from multiple companies that use diverse technologies. MicroServices facilitates the integration of different components that come from  different companies with different code base. ManageIQ is coming late to OPEN-O, and more analysis is needed.

                                                             ii.      Uri – Why would MicroServices be a better approach than other alternatives? How would MicroServices allow easier integration? Is REST the main advantage?

                                                           iii.      DengHui – OpenStack is an example for implementing MicroServices with success. MicroServices allows plug-and-play model, where each module is independent of the message bus, allowing each module to be integrated independently.

                                                           iv.      Geert – OpenStack is impressive, but it took 6-7 years with thousands of developers to develop. MicroServices comes at a cost, not sure if it is justified.

                                                             v.      Dave – Wants to discuss platform versus point-to-point integration more. He prefers platform versus MicroServices, because it will be more costly to define all individual p2p interfaces.

                                                           vi.      DengHui – Some existing code such as Aria needs to be integrated within this year, it cannot work with a platform that is based on another language.

                                                          vii.      Geert – ManageIQ has advantages over Aria. ManageIQ has broader functionality, except for the TOSCA parser. Using multiple languages may not be the fastest way to build a community.

                                                        viii.      Its service model may currently not be ideal but it has a good service catalogue

                                                            ix.      Deng Lingli – ManageIQ is a Cloud Manager, it has major (functional) gaps as an orchestrator. How much effort is needed to use ManageIQ as NFV-O? What effort is needed to fill the gaps?

                                                             x.      Geert – ManageIQ is a generic manager, not just a Cloud Manager. ManageIQ is not ready for use as NFV-O, but the platform provides most of the primitives.

                                                            xi.      ManageIQ has many re-usable components, activation engine, governance, federation, data model, and SDN.

                                                          xii.      The platform can be easily changed to fill any gaps for OPEN-O

                                                        xiii.      Geert – The ManageIQ core team will not be able to attend the Beijing meeting. Please do not make any decisions until you have seen our OPNFV demo.

                                                        xiv.      DengHui – RedHat should propose which module could be used. Red Hat can propose something for the platform driven approach.

                                                          xv.      The ManageIQ issues will be discussed by email. We can discuss more next week in Beijing.

                                                        xvi.      Chris – No decisions will be made at the Beijing meeting. Decisions cannot be made until June when TSC is formed. Meanwhile we can just make suggestions.

 

 

6.       MEF LSO Reference Architecture

a.       Andy Mayer, as a guest participant from a partner project, presented MEF LSO Reference Architecture. His presentation covered the following points:

                                                               i.      History of MEF Lifecycle Service Orchestration Reference Architecture

                                                             ii.      Definition of LSO and LSO RA

                                                           iii.      Drivers-on-Demand and Agile Services

                                                           iv.      Definition of Orchestration

                                                             v.      MEF Engineering Methodology

                                                           vi.      LSO-related MEF activities

                                                          vii.      LSO Reference Architecture

                                                        viii.      LSO Operational Threads

                                                            ix.      LSO Management view abstractions

                                                             x.      Examples of data transferred on each interface

                                                            xi.      LSO example with SDN and NFV

                                                          xii.      LSO RA phase 2 plans

b.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Uri – Which requirements are imposed on controllers by Presto?

                                                             ii.      Andy – We are working with ONF on Presto requirements for Service Chaining. Phase 2 will investigate more use cases and interactions.

                                                           iii.      Amir – GigaSpaces has already demonstrated at the LSO Hackathon the Legato and Presto interfaces using TOSCA. (Demonstrated Legato API using Tosca).

                                                           iv.      Uri – Is the Presto interface defined? How MEF addresses SDN-O and NFV-O – Presto + network functions and network services? There are still discussions whether Service Orchestration goes directly to VNFM or NFVO?

                                                             v.      Andy – An early draft is available.

                                                           vi.      Uri – Has LSO been adopted by any BSS groups?

                                                          vii.      Andy – We are working with open source communities.

                                                        viii.      Olga – Has MEF discussed Presto with ETSI NFV? The question is about Legato vs. ETSI API.

                                                            ix.      Andy – We have been working with ETSI NFV (still work in progress). We hope to develop use cases with ETSI.

7.       Seed Code Meeting Presentation

a.       Chris presented the Seed Code meeting charts, covering the following points:

                                                               i.      Workshop goals

                                                             ii.      Agenda

                                                           iii.      Architecture Map

                                                           iv.      Potential metrics

b.       Chris – We should add 2 new metrics. Ability to deliver this year, and effort needed to fill gaps.

c.       Marc – I have discussed the metrics with Phil Robb from OpenDaylight. Phil can share his expertise.

d.       Phil – The current list looks good. Contributors who have overlaps should discuss differences in functionality and differences in approach. Phil will join us next week in Beijing, he has experience in ODL.

e.       Phil – proposed that those who have multiple seed code contributions to have joint meetings to understand and assess each other’s proposals, overlaps and gaps

f.        Lingli – presented arrangements for the meeting in Beijing. It is important to register at the North gate on the first day.

g.       Geert – The ManageIQ core team will not be able to attend the Beijing meeting next week.

h.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Uri – We need a high-level description of the functionality and the APIs.

                                                             ii.      Chris – We will have sessions in Beijing for detailed discussions.

                                                           iii.      Uri – We need basic definitions of each component. For the proposed functionality and APIs, we need the description and requirements for the OPEN-O blocks, so that we can match OPEN-O requirements to APIs and provided functionality  of the contributions

                                                           iv.      Deng Lingli – Each contributor should answer the above questions during their presentation.

                                                             v.      Chris – Each contributor should address all of these metrics.

                                                           vi.      Deng Lingli – We should add a metric for compliance to standards such as ETSI or MEF.

                                                          vii.      Uri – MEF will not be relevant outside SDN.

                                                        viii.      Chris – We can use the email list to discuss which standards may be relevant.

                                                            ix.      Corona Wei or Fengjie – Made some comments about MEF and will share her ideas by email

                                                             x.      Uri – Functionality in each block is still unclear.

                                                            xi.      Dave – It may be good to have a “bake-off” where sample use cases are used to evaluate each contribution.

 

 

Action Items:

8.       Forward the MEF LSO slides to the email list. (Chris D)

9.       Share the current Presto draft. (Andy M)

10.   Send a list of confirmed attendees for next week’s face-to-face meeting in Beijing (Lingli Deng)

11.   Red Hat will not be able to attend Beijing meeting, but they will try to communicate through presentations (Uri E)

12.   Share the slides for the section on “Seed Code Meeting” (Chris D)

13.   Add best practices for code selection (Mark C)

 

Regards,

 

Cas

 

From: Casem Majd
Sent: Thursday, May 05, 2016 2:56 PM
To: Casem Majd; open-o-technical-formation@...; Christopher Donley (Chris); Michael McBride
Cc: Marc Cohn; Casem Majd
Subject: RE: OPEN-O Architecture Meeting Notes

 

All,

Please find below the notes for this week’s OPEN-O Architecture Meeting. Thanks to Dave again for his help.

 

Meeting Venue:  The OPEN-O Architecture Meeting Conference Call took place on Wednesday May 4th, 2016. Meeting started at 6:30am and ended at 7:30am PST. 23 people  from 8 organizations participated.

 

Summary:

8.       Review conference participation/feedback (ETSI NFV, OpenStack, MEF, etc.)

                                                   i.      We had an event report from the face-to-face last week at OpenStack Summit

                                                 ii.      Report on ETSI NFV meeting

                                               iii.      Report from MEF

b.      ETSI NFV Update

                                                   i.      Marc C from Linux Foundation mentioned that they had been invited to meet with the ETSI NFV MANO group this week in Atlanta to talk about possible collaboration.

                                                 ii.      ETSI NFV panel went well, which opens the door to further cooperation.

1.       Chris and Marc presented Open-O at the ~150 members ETSI panel (special session on open source orchestration, where OPEN-O and OSM were showcased in a single session)

2.       Additionally, we participated in a panel discussion

                                               iii.      Amir Levy from GigaSpaces presented ARIA hierarchical model-driven orchestrator (TOSCA/YANG). 

                                               iv.      OSM team also presented their story.

                                                 v.      Questions from the ETSI participants around how we plan to use their specs and common information/data models/VNFs.

1.       ETSI is particularly interested in OPEN-O converging on a common Information Model with OSM, and compliance with the ETSI NFV Architectural Framework.

2.       ETSI wants us to provide ETSI NFV IFA-compliant interfaces

                                               vi.      Also questions about participating in standards versus open source.

                                              vii.      Discussed the possibility of convening an OPEN-O/OPNFV/OSM session at the OPNFV Summit in June. ETSI also offered to share a tutorial on the ETSI IFA-defined interfaces.

                                            viii.      AT&T also presented ECOMP earlier in the week.  Marc said that they were hinting that they’re working on an open source strategy, but it didn’t sound like a separate community. They are asking a lot of questions about Open-O.  We need to keep engaging with them.

c.       MEF Forum Update

                                                   i.      Brendan H talked about the interest for Open-O that he had encountered at the MEF forum.

                                                 ii.      SDN-O integration is important for the MEF use-cases.

                                               iii.      MEF forum asked a lot of questions about Open-O.

                                               iv.      We will invite MEF to present to the OPEN-O architecture team in May

 

9.       Work Plan

a.       Marc reviewed the plan for the next few weeks.   

b.       Marc is refining the spreadsheet, and will send an update this week.

c.       Several companies announced intention to participate in the face-to-face in Beijing: Intel, Huawei, ZTE, China Mobile, China Telecom, GigaSpaces (maybe others).

d.       Parties are asked to send the seed code map to Chris by 5/10

e.       Parties are asked to register for the event by 5/10

f.        Parties are asked to notify Marc if they are planning to join Open-O, and at what level (even prior to formally signing the membership document). We need to start planning launch activities.

10.   Architecture

a.       HA is put in the “Common Service” box and not the “O-common” box, HA is a common requirement for all the components inside OPEN-O, not only those inside the orchestration layer.

b.       Uri asked about EMS/OSS/BSS interfaces.  Deng Hui referred him to the YouTube video of our OpenStack talk.  We will discuss on a future call.

11.   Discussed preparations for the May 17-19 meeting

a.       Reported on seed code release progress and planning for face-to-face meeting in Beijing

b.       Who is bringing seed code

c.       What are the expectations for companies bringing seed code

d.       Question raised whether there were guidelines on meritocracy of operation

e.       Some organizations feel it is important to understand the meritocracy before the meeting, to inform the discussion and decision process.

12.   Red Hat ManafeIQ Presentation

a.       For the last 15 minutes, Red Hat (Geert Jansen) presented ManageIQ.

b.       Red Hat proposes that ManageIQ

c.       Red Had open sourced this code base in 2014.  

d.       Code base started in 2006 and uses the Apace 2.0 license. Code is written in Ruby on Rails.

e.       It is a service catalog for on boarding of VNF

f.        Provisions the VNF via standard provisioning workflows

g.       Support of VNF lifecycle management via service models

h.       Provides event-driven automation via control

i.         Supports delegated control via service model

j.         We did not have a lot of time for questions, but there were a number of people who said that they wanted to follow up with questions.

k.       Agreed to continue the discussion via email.

 

Action Items:

14.   Parties are asked to send the seed code map to Chris by 5/10

15.   Parties are asked to register for the event by 5/10

16.   Parties are asked to notify Marc if they are planning to join Open-O, and at what level

17.   Invite MEF to present at the OPEN-O architecture team in May

 

Regards,

 

Cas

 

From: Casem Majd
Sent: Monday, May 02, 2016 5:36 PM
To: Casem Majd; open-o-technical-formation@...; Christopher Donley (Chris); Michael McBride
Cc: Marc Cohn
Subject: RE: OPEN-O Architecture Meeting Notes

 

All,

Please find below my notes for this week’s OPEN-O Architecture Meeting. Thanks to Dave Neary for his valuable contributions to this week’s meeting notes.

 

Meeting Venue:  The OPEN-O face-to-face Architecture Meeting took place in Austin, TX at the end of the OpenStack Summit on Friday April 29th, 2016. Meeting started  at 9:00am and ended at 3:00pm. 18 people from 9 organizations participated.

 

Summary:

1.       Sivan and Arthur B from GigaSpaces presented a tiered or hierarchical service model proposal

a.       The proposed hierarchical model consists of two levels of abstractions

b.       TOSCA is used for the end-to-end service abstraction, with extension nodes that contain YANG models, which are used for the network and device abstraction.

                                                               i.      TOSCA extensions capabilities are used to add new node types and develop a common composite model made from TOSCA, YANG, and other plug-ins

                                                             ii.      The top-level abstraction describes what is needed for the service, and the lower-level abstraction specifies the implementation details of each network component (e.g. YANG models for ODL or ONOS network domains)

                                                           iii.      The model is used to create functions out of building blocks and chain those functions to create services.

                                                           iv.      One example presented: Modeling DNS - node type Bind9, with some connected resources (such as a GW FW, security groups) - some of which are external to the VNF

                                                             v.      The example demonstrates TOSCA as a description language, including its extensibility

                                                           vi.      Relationship between YANG and TOSCA? Sometimes some things are better expressed with YANG, and the proposed solution (ARIA) has a possibility to wrap these pieces in TOSCA to orchestrate

c.       The model covers the service lifecycle, from installation, provisioning, configuration and deployment through monitoring of the application or service in order for the system to take reactive or proactive actions, such as healing  and scaling based on custom triggers, or other actions to be performed as part of a lifecycle.

d.       The models come with policy and workflow components. Pre-defined events are specified in the policy templates for certain conditions or threshold violations. The policy defines which events to track, what threshold conditions  to watch for, and what corrective actions to take in case of violation of those thresholds. Examples are scale-out based on pre-set capacity utilization thresholds.

                                                               i.      Separation of policy, workflow, and execution/event handling

                                                             ii.      The policy templates specify when to react,

(Policy: If event, then mitigation (start a mitigating workflow))

                                                           iii.      The ensuing workflow specifies the sequence of actions (what to do) to perform in case the policy is violated, and

(Workflow: Actions to be executed - potentially more than one - to apply policy)

                                                           iv.      The implementation logic specifies how to react

(Execution: Event triggers policy execution, which runs through workflow)

e.       The solution would consist of a model parser and an execution engine.

                                                               i.      ARIA is a TOSCA parser and orchestrator. Every time a new node type is added, the parser needs to be aware of them, and validate them.

                                                             ii.      Q: Is it better to have a separation of parser and orchestrator? R: Opinion is that parser and orchestrator are related - similar to UI and model, hard to write a UI without awareness of underlying model

                                                           iii.      Perhaps runtime binding of an alternative orchestrator would be possible

                                                           iv.      Extensive discussion about whether it makes sense to have the parser tied to one orchestrator, and how separation would be possible

                                                             v.      ARIA is open source, and there is a desire of GigaSpaces to have multiple vendors collaborate on it - extension and collaboration could happen in ARIA

f.        The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Need to plug-in to ETSI, and try to define common models that align with ETSI

                                                             ii.      What is the relationship with ETSI NFV MANO? Will there be a common model with the industry? We should align with what is being used in OSM for the information model to converge on an industry norm (best effort attempt).

                                                           iii.      How and to what extend would the proposed models support the complete lifecycle of the service, including model-driven service assurance and inventory schema (allowing new inventory item types to be added dynamically based on  models).

                                                           iv.      Is a tiered model necessary for service modeling? Doesn’t it introduce unnecessary complexity? The relevance of the model should be demonstrated with the vCPE use case implementation, and show what was extensions were made to  the standard TOSCA or YANG.

2.       Olga H from Huawei reviewed the OPEN-O functional architecture

a.       The team reached consensus on the existing OPEN-O architecture. Minor modifications were made to the architecture diagram, e.g.,

                                                               i.      Adding HA function to the O-Common,

                                                             ii.      Adding EMS/NMS driver to the southbound

b.       Separation of some common services unrelated to Orchestration use-cases (logs, workflow, message bus, etc) and common services with orchestration focus (template management, lifecycle management framework, model driven framework).  The main components of the architecture are:

                                                               i.      Common Services, which consist of generic applications that are independent of orchestration. These are system-wide functions.

                                                             ii.      O-Common, which consists of orchestration specific services and functions

                                                           iii.      SDN-O, which provides abstraction for masking network complexities.

                                                           iv.      NFV-O, which models VNFs and applications. It would preferably be aligned with ETSI models.

                                                             v.      What about intent? - intent parsing needs to be in global service orchestration, but also for rendering intents, southbound of SDN-O for the SDN controllers. Consensus is that both SBI and NBI will support intent.

                                                           vi.      As presented, separation of driver layer for different VIMs, SDN controllers, VNFM drivers, which are independent of the model design and resource management layers.

c.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      It is not clear if the software architecture (and its corresponding data model architecture) is aligned with the OPEN-O architecture diagram. This needs more discussion.

                                                             ii.      There is a concern of having to deal with too many modules and too many interface points between them, which would slow us down! Is there a generic VNFM interface?

                                                           iii.      Relationship with Tacker, OPNFV, etc?

                                                           iv.      Using standard open source components for common services, even if there is not a vendor at the table.

3.       The team discussed one open architectural item – HA

a.       How to provide HA? Should it be a platform function or a module-specific function?

b.       We agreed that it belonged as a common function, and updated the architecture diagram accordingly (adding HA to O-Common)

c.       Support of HA would not be within the scope of release 1.

d.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Open-O is going to implement Micro-Service architecture

                                                             ii.      HA and scalability should be common requirement for each micro-service (Perhaps on O-Common - HA service?)

                                                           iii.      HA as a common requirement has the potential consequence that the modules may have to be stateless. More work needs to be done to clarify.

 

4.       The participation at OPNFV Summit has been discussed

a.       China Mobile offers their booth space at the OPNFV Summit in Berlin for free to host the Open-O demos

                                                               i.      There will be a small/narrow space, with 2 demo spaces

                                                             ii.      So far, there are six demos prepared and proposed by different vendors (Red Hat, ZTE, etc.)

                                                           iii.      Intention is to cast the demos into a broader and more consistent story that highlight the main OPEN-O capabilities. It should not be a scattered set of demos. They all should tell a consistent end-to-end storyline.

b.       OPEN-O will be presented at OPNFV for the first time under its own name as an independent entity, and not through any specific organization.

                                                               i.      China Mobile / Huawei will be doing a joint presentation.

c.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Need to finalize the OPNFV demos during the next face-to-face meeting in May 2016.

5.       Discussion on Seed Code contributions

a.       Vibrant discussion on who plans to bring seed code to the May meeting:

                                                               i.      Organizations will be invited to contribute seed code. So that we can make most effective use of the face-to-face, every party will fill up a map that shows to what module it intends to contribute code?

                                                             ii.      Expression of intent for contributing seed code is currently not binding. Partner organizations can declare their intents for contributing code without any concerns about legal obligations. As long as TSC has not been formed,  no decision will be made on what code to include and what to exclude to/from the base code.

                                                           iii.      It is preferred for organizations to come to the meeting with open source code. However, if organizations intend to submit open source seed code, but have not cleared their code yet, they may just make presentations at the next  meeting in order to avoid legal complications. Organizations should not disclose their code if they don’t have the required open-sourcing approvals.

                                                           iv.      Requirement to open source code in advance of the OPNFV Summit hackfest, but not necessarily in advance of the meeting in Beijing. Marc Cohn confirms that we will not be doing any NDAs or similar - if code is not open sourced,  then only publicly available information can be presented.

                                                             v.      Bringing code does not guarantee that the code will be included

                                                           vi.      The team will define the criteria and the meritocracy rules for accepting or rejecting code contributions to the code base. Linux Foundation will share its current Best Practices to all participating organizations. The team  will make a group decision based on suggested best practices.

1.       The decision criteria for how seed code will be chosen will be documented before the meeting

b.       Proposed process for consolidating code:

                                                               i.      We will send the detailed architecture diagram to participating organizations and ask how their intended seed code contribution would fit into the OPEN-O module landscape.

                                                             ii.      Organizations will fill up a map that shows to what module they intent to contribute code to.

                                                           iii.      We will create a consolidated mapping table that maps each contributing code to each functional architecture block and identify a leader for each category

                                                           iv.      The goal of this planning is to gather expressions of interest to bring code to the table.

1.       The intent to participate - with an understanding that things will evolve, as we start to work on it, and refine functional block definitions.

                                                             v.      In May, we will discuss, with a level playing field, which components will be part of the initial release

                                                           vi.      The TSC, after formation, will own and validate the architecture and project operation - the architecture discussion group provides input into that discussion

                                                          vii.      Participation will be open - it is possible that people who have not been involved in the formation discussions will participate

                                                        viii.      If people express an intent to join, they can participate in the mailing list and May meeting.

c.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      Question whether seed code must be open source? All seed code must be open source before the launch.

 

6.       Preparation for next face-to-face meeting in China from May 17th to May 19th 2016

a.       The review and consolidation of the contributing seed codes is the main objectives of the next face-to-face meeting in May 2016.

                                                               i.      The next face-to-face meeting to be held at China Mobile facilities in Beijing, China from May 17th to May 19th 2016.

                                                             ii.      Place: Meeting Room 908, Level 9th, China Mobile Research Institute, Beijing, China

b.       We will wait to see what code contributions we will receive and then decide how to organize the meeting (structure, number of sessions, mission for each session, etc.)

                                                               i.      The current consensus is to start with an end-to-end architecture session, followed by a set of parallel module-specific code review sessions.

1.       Day 1: Presentation of seed code

2.       Day 2: How we operate as a community, how meritocratic decision making works, and how we make seed code easier to consume

3.       Day 3: Convergence on who will participate in the project at which functional blocks, scope and goals for 1st release

                                                             ii.      There are concerns about

1.       How to coordinate the work between overlapping SDN-O and NFV-O tracks?

2.       How to take the results and consolidate them? How to take and consolidate meeting notes?

                                                           iii.      The final agenda for the May meeting is moved to the mailing list

c.       The goals of the May meeting are:

                                                               i.      Companies participating will have an opportunity to present their seed code, show how they fit into the architecture, and demo their projects

                                                             ii.      Review contributing codes, assess how contributions fit together

                                                           iii.      We will try to resolve conflicts between code which is functionally overlapping

                                                           iv.      Define a realistic scope for release 1

                                                             v.      Create a project plan for TSC

                                                           vi.      Partners should come to the meeting with their USB keys and code.

d.       Before the meeting, create a consolidated mapping table that shows how each contributing code maps to one of the following functional blocks of the architecture and identify a leader for each category:

                                                               i.      SDN-O and its drivers

                                                             ii.      NFV-O and its drivers

                                                           iii.      GS-O

                                                           iv.      Tools / Commons

                                                             v.      We will identify track leaders before the May meeting for break-out sessions on each of the main functional blocks.

e.       The following considerations, concerns, comments, and questions were raised from the audience:

                                                               i.      There are certain visa and travel restriction concerns

                                                             ii.      It is understood that the meeting is short notice for some participants. However, the meeting should not be later - because of time pressure for OPNFV.

                                                           iii.      Concern expressed that if we start with a broad and ambitious scope, we will have trouble converging to a first release. We do not want to lock in a plan in May before we have a technical community created and working together.  We may be able to start working on seeding project plans in the May meeting, even if it will take a few weeks to get a TSC.

                                                           iv.      Is there a separate track on architecture, planning, components? Someone needs to keep the overall view/big picture in mind

 

7.       Mark C presented the plan of work for the next 3 months

a.       Major milestones were presented

b.       The plan will be distributed next week

c.       Companies to introduce representatives for various committees (TSC, etc.)

d.       Launch planned for June 1st

e.