This wiki page This wiki page is explicitly set up as a scratch-pad of feedback that the ONAP TSC Members will use to identify, and collate initial feedback to ONAP project proposals as we all prepare for the first set of Project Creation Reviews starting on June 8th and 9th 2107.
...
Service Orchestrator (5/14/17)
(Alla, Andrei)
- Closed Loop management and orchestration: applying Event/Model/Policy approach causing service re-plan
(Stephen)
- Scope is rather clear. It would be good to state which APIs the project feels it is responsible for defining (it states later which it feels it uses).
- JIRA prefix: I suggest we drop MSO now as I understood its decided as SO.
...
- Potential Overlap with VNF SDK for VNF validation tooling or testing framework.
- Need clarificatin with the overlap between modeling and this project regarding the VNF template (HEAT and TOSCA).
ICE
(Alla, Andrei)
- VNF package validation, VNF testing based on agreed KPI's;
- Supporting ETSI NFV standards and TOSCA specifications;
- VNF store/market place;
- VNF certification;
- Leveraging SDC platform and SDC/ONAP Portal
(Jason Hunt)
- I believe I understand the difference between ICE and VNF SDK, as it appears that VNF SDK will provide all the tooling to implement the validation program, but the ICE/VNF Validation Program will establish the community and processes for validation. Is this correct? Because of the tight synergies of these projects, would you consider merging them? Perhaps VNF SDK and VNF Requirements could be subprojects under the VNF Validation Program?
(Roberto Kung)
- VNF SDK and ICE should be merged. VNF-SDK starts almost from scratch, so it would be easy. Some links to be made do OPNFV (Dovetail, Program CVP).
- Will depends very much on technical decisions from other projects that may impact VNF guidelines.
...
(Chris) We discussed this at length. ICE/Verification will focus on the verification program. VNF SDK will focus on the tools (including the ICE tools) and will align with SDC.
VNF-SDK
(Alla, Andrei)
- VNF package onboarding;
- Supporting ETSI NFV standards and TOSCA specifications;
- Leveraging SDC platform and SDC/ONAP Portal
(Jason Hunt)
- I believe I understand the difference between ICE and VNF SDK, as it appears that VNF SDK will provide all the tooling to implement the validation program, but the ICE/VNF Validation Program will establish the community and processes for validation. Is this correct? Because of the tight synergies of these projects, would you consider merging them? Perhaps VNF SDK and VNF Requirements could be subprojects under the VNF Validation Program? Or are there other uses of VNF SDK outside of the validation program?
- Can you clarify how this tooling will be provided? Will it be another running component of ONAP, accessible from the ONAP portal?
- Can you clarify the role of the network function repository? Is the thought for this to be run separately by a third party? If not, and it is part of an ONAP installation, how is it different from the existing catalog of onboarded functions?
...
This project targets to provide data filtering/processing/transportation support by leverage other open sources. With the big scope, the team need to clarify what is the focus in R1. Also need seed code list and company diversity.
Modeling & Design
Note on this section:
The part under the names is comments received from the individuals.
Where it says "review comments" is the consolidated comments after discussion, following the criteria/skeleton proposed.
Modeling (5/11/17)
(Xiaojun)
Review:
Clarity of Scope:
Reasonable and Well defined Scope:
- Could the proposal clarify the unified model-driven approach? How are the data models used by AAI, APIs, or blueprints updated?
...
- Include in scope: Modeling and Design (concept for multiple projects: CLAMP, SDC, AAI, Network Functions Change Management, External API Framework, External System Registry );
- Include in Scope: Application Modeling (VNF modeling) (e.g. YAML based) for managed VNF's as supported by APP-C that leverages Closed Loop management including application management
(Stephen)
- management
- Small: the text uses OPEN-O and OpenECOMP. As the project description should survive the first release, perhaps look at wording to avoid referring to those terms as they should be deprecated in ONAP. e.g. "The project will produce unified and consolidated data models".
- During the release planning, it would be good to have the plan of when to deliver what models for the needs of other projects to use. I understand that the deliverables are both models, as well as code in the form of tools. Should they be in the
- Under "scope" The reference to R1 may better be removed. It may imply that the data model will be designed to address these use cases only and ignore the rest, which I am sure was not the intention. This information should go into the release planning, not project definition.
- Question: What about backwards compatibility for ECOMP and Open-O data models? Will there be a new model to replace both? If so, is ONAP expected to support only the unified model? Or support the new as well as the two old ones?
Identification of SW modules and APIs being developed and delivered to other components
- I understand that the deliverables are both models, as well as code in the form of tools. Should they be in the same repo, or different repos (question, not a statement)
- . consider separating tooling from models in repos The number of committers is very high, perhaps 1-2 per company
- as the code will be pulled down separately from the tools.
- Be clear on the tools to be as a deliverable, and the APIs. e.g. a model passer .
(Ranny Haiby)
- Under "scope" The reference to R1 may better be removed. It may imply that the data model will be designed to address these use cases only and ignore the rest, which I am sure was not the intention. This information should go into the release planning, not project definition.
- What about backwards compatibility for ECOMP and Open-O data models? Will there be a new model to replace both? If so, is ONAP expected to support only the unified model? Or support the new as well as the two old ones? In general, what does the existence of data model and information model mean? That they must be
- passer
Follow project and LF guidelines for contributors/committers:
- The number of committers is very high, perhaps 1-2 per company
Identification of dependences and assumptions on other components and open source
Overlap
Intentional and unintentional overlap
- In general, what does the existence of data model and information model mean? That they must be used by all other projects? Could be used?
- (i.e. is this producing models that the other projects must use, or this a coordination activity providing guidance) .
(Review meeting)
- On the R1, please state which projects will use which models. We want to know how the projects are going to interact with the projects and whether they expect to receive the model or receive coordination and guidance.
CLAMP (5/11/17)
Review Comments:
(Xiaojun)
Could the proposal clarify the functionality implemented by the control loops? And what’s the relationship with Holmes?
(Stephen)
- Scope: Regarding E2E call flows, alignment with the architecture team on the scope would be good.
- Editorial: Commetters and contributors are listed twice.
- Can it be clarified what the deliverable is in terms of deliverables: Code modules, templates, .... I understand the concept, but I am trying to figure out what is delivered by this project compared to SDC, and modeling.
- Can parts of Policy driven VNF orchestration be incorporated?
- It would be good to clarify the relationship with SNIRO.
- Look at Holmes scope to see if some is relevant here.
- A high level flow (technical) showing the CLAMP parts and the interaction with the other projects would be great.
(Roberto)
needs analytics microservice description to be included in its design capabilities
(mazin)
Overlap with Holmes. Have that project intgerate with CLAMP.
(Zhaoxing)
From my understanding, the main goal of CLAMP should be:
Design time:
Design close loops to connect the models and actions distributed in different components together, such as metrics definition in VNF model, data collection ? analytics in DCAE, policy and vnf/ns lifecycle management in SO/VF-C/APP-C.
Run time:
Present the status of the running close loops.
However, from the description of the proposal, it seems that DCAE is responsible for the execution of close loop, I might be wrong at this, but it would be great if a high-level workflow diagram could be used to clarify how close loop is designed and enforced, as well as the interactions between the involved components such as SDC, DCAE, Policy, SO/VF-C/APP-C, etc.
Below is extracted from project proposal
Interfaces:
The following interfaces will be implemented by other components but used for CLAMP. Therefore, CLAMP has these as dependencies:
Query and update services in SDC
Query and update control loop templates in SDC (future not in R1)
Policy interfaces for creating/updating configuration and operational policies
DCAE interfaces for deploying/undeploying control loops
Runtime messaging interface between DCAE and Policy
Service Design & Creation (5/17/17)
Review summary:
----
(Xiaojun)
Could the proposal describe the scope of the catalog module?
(Alla, Andrei)
- SDC should be an umbrella for all Design time parts from other Projects (CLAM, Policy, Converged ICE & VNF SD-K);
- SDC is a platform for all the modeling and design in ONAP and provides the interactive tool for design and automation for on-boarding.
(Stephen)
- It would be great to be clear on the modules delivered by this project.
- The connections to other projects should be clarified clearly.
- Are there APIs that the project feels it is responsible for, or does it use the APIs defined by others?
- Perhaps 1-2 committers per company
- More detail on what test is.
- Scope seems rather large. Not clear on what is for the first release, and interactions/dependencies with DCAE, policy, SO, Controllers. ......
- Not clear what deliverables are required to support the usecases
(Zhaoxing)
- Could this project proposal clarify how to support the Telcom use case(VoLTE), for example, how to onboarding TOSCA based VNF and use it as building block for service design?
- Could this project proposal clarify its relationship/dependency with ICE? It seems that the ICE project will provide guideline/process definition for certification and this project will provide tools to support ICE?
Active and Available Inventory (AAI) (5/11/17)
(Stephen)
- In this scope it would be great to be clear on the modules that are to be delivered in general.
- In the scope it would be great to clarify whether this project responsible for any APIs to be defined, I assume so.
- Perpahs 1-2 committers per company?
- Editorial. Referens to MSO, should be SO now.
Network Function Change Management Project Proposal (5/11/17)
(Stephen)
- It would be great to be clear on the code module deliverables from this project so we can understand whether there are overlaps in the deliverables with the other projects (e.g. SDC). i.e. what is planned to go into the repo NFCM. i.e. from the scope of this, it feels like it should be part of SDC or produces requirements, however I would like to understand the deliverables to get a clearer understanding of that.
External API Framework (5/15/17)
(Stephen)
- Scope: Question: Does this provide a SB API definition into ONAP (or use one) and a "plug-in" environment for bringing the external interfaces?
- Scope: Clarify the code modules that are a deliverable.
- Scope: On the models, discussion with the modeling project about what are the models covered in this project vs the modeling project would be great. I can see what the line would be though. the TMF SID maybe one point to align on (not clear how that would be part of integration)
...
The suggestion here is where it states: Deliverables for R1, state which projects depend on this and handshake with them also the timing.
overlap with external opensource efforts
- Covered, OK.
Risk Management
Sufficient resources allocated to deliver on time:
- Yes there are sufficient resources, the risk is the discussion on this interesting topic could delay other dependent projects, so important to handshake the needed timing.
At least 3-4 companies involved to provide diversity:
- Yes, OK
Available seed code and maturity
- Yes, ok
Relevance and prioritization
Alignment with merger release
- Yes, required.
Alignment with use cases
- Yes, required
Sound technical solution solving a real need.
- Yes, fulfills a need
(Xiaojun)
- Could the proposal clarify the unified model-driven approach? How are the data models used by AAI, APIs, or blueprints updated?
(Alla, Andrei)
- Include in scope: Modeling and Design (concept for multiple projects: CLAMP, SDC, AAI, Network Functions Change Management, External API Framework, External System Registry);
- Include in Scope: Application Modeling (VNF modeling) (e.g. YAML based) for managed VNF's as supported by APP-C that leverages Closed Loop management including application management
(Stephen)
- Small: the text uses OPEN-O and OpenECOMP. As the project description should survive the first release, perhaps look at wording to avoid referring to those terms as they should be deprecated in ONAP. e.g. "The project will produce unified and consolidated data models".
- During the release planning, it would be good to have the plan of when to deliver what models for the needs of other projects to use.
- I understand that the deliverables are both models, as well as code in the form of tools. Should they be in the same repo, or different repos (question, not a statement). consider separating tooling from models in repos
- The number of committers is very high, perhaps 1-2 per company
- Be clear on the tools to be as a deliverable, and the APIs. e.g. a model passer .
(Ranny Haiby)
- Under "scope" The reference to R1 may better be removed. It may imply that the data model will be designed to address these use cases only and ignore the rest, which I am sure was not the intention. This information should go into the release planning, not project definition.
- What about backwards compatibility for ECOMP and Open-O data models? Will there be a new model to replace both? If so, is ONAP expected to support only the unified model? Or support the new as well as the two old ones?
- In general, what does the existence of data model and information model mean? That they must be used by all other projects? Could be used?
(i.e. is this producing models that the other projects must use, or this a coordination activity providing guidance).
(Review meeting)
- On the R1, please state which projects will use which models. We want to know how the projects are going to interact with the projects and whether they expect to receive the model or receive coordination and guidance.
CLAMP (5/11/17)
Review Comments:
Clarity of Scope:
Reasonable and Well defined Scope:
- Could the proposal clarify the functionality implemented by the control loops? And what’s the relationship with Holmes?
- Editorial: Commetters and contributors are listed twice
- A high level workflow showing the CLAMP part and the relationship with the other components would help to clarify.
- needs analytics microservice description to be included in its design capabilities
Identification of SW modules and APIs being developed and delivered to other components
- Can it be clarified what the deliverable is in terms of deliverables: Code modules, templates, .... I understand the concept, but I am trying to figure out what is delivered by this project compared to SDC, and modeling
- Dependant interfaces are identified. The assumption is that this project does not define interfaces.
Follow project and LF guidelines for contributors/committers
- In general yes, though increased diverstity of the committers would be appreciated.
Identification of dependences and assumptions on other components and open source
Overlap
Intentional and unintentional overlap
- Scope: Regarding E2E call flows, alignment with the architecture team on the scope would be good.
- Can parts of Policy driven VNF orchestration be incorporated? (and coordinate with project)
- It would be good to clarify the relationship with SNIRO (and coordinate with project)
- Look at Holmes scope to see if some is relevant here (and coordinate with project)
overlap with external opensource efforts
Risk Management
Sufficient resources allocated to deliver on time:
- Could be a little thin
At least 3-4 companies involved to provide diversity:
- No, increased diversity is encouraged
Available seed code and maturity
- Yes
Relevance and prioritization
Alignment with merger release
Alignment with use cases
Sound technical solution solving a real need.
(Xiaojun)
Could the proposal clarify the functionality implemented by the control loops? And what’s the relationship with Holmes?
(Stephen)
- Scope: Regarding E2E call flows, alignment with the architecture team on the scope would be good.
- Editorial: Commetters and contributors are listed twice.
- Can it be clarified what the deliverable is in terms of deliverables: Code modules, templates, .... I understand the concept, but I am trying to figure out what is delivered by this project compared to SDC, and modeling.
- Can parts of Policy driven VNF orchestration be incorporated?
- It would be good to clarify the relationship with SNIRO.
- Look at Holmes scope to see if some is relevant here.
- A high level flow (technical) showing the CLAMP parts and the interaction with the other projects would be great.
(Roberto)
needs analytics microservice description to be included in its design capabilities
(mazin)
Overlap with Holmes. Have that project intgerate with CLAMP.
(Zhaoxing)
From my understanding, the main goal of CLAMP should be:
Design time:
Design close loops to connect the models and actions distributed in different components together, such as metrics definition in VNF model, data collection ? analytics in DCAE, policy and vnf/ns lifecycle management in SO/VF-C/APP-C.
Run time:
Present the status of the running close loops.
However, from the description of the proposal, it seems that DCAE is responsible for the execution of close loop, I might be wrong at this, but it would be great if a high-level workflow diagram could be used to clarify how close loop is designed and enforced, as well as the interactions between the involved components such as SDC, DCAE, Policy, SO/VF-C/APP-C, etc.
Below is extracted from project proposal
Interfaces:
The following interfaces will be implemented by other components but used for CLAMP. Therefore, CLAMP has these as dependencies:
Query and update services in SDC
Query and update control loop templates in SDC (future not in R1)
Policy interfaces for creating/updating configuration and operational policies
DCAE interfaces for deploying/undeploying control loops
Runtime messaging interface between DCAE and Policy
Service Design & Creation (5/17/17)
Review summary:
Clarity of Scope:
Reasonable and Well defined Scope:
Identification of SW modules and APIs being developed and delivered to other components
Follow project and LF guidelines for contributors/committers
Identification of dependences and assumptions on other components and open source
Overlap
Intentional and unintentional overlap
overlap with external opensource efforts
Risk Management
Sufficient resources allocated to deliver on time:
At least 3-4 companies involved to provide diversity:
Available seed code and maturity
Relevance and prioritization
Alignment with merger release
Alignment with use cases
Sound technical solution solving a real need.
(Xiaojun)
Could the proposal describe the scope of the catalog module?
(Alla, Andrei)
- SDC should be an umbrella for all Design time parts from other Projects (CLAM, Policy, Converged ICE & VNF SD-K);
- SDC is a platform for all the modeling and design in ONAP and provides the interactive tool for design and automation for on-boarding.
(Stephen)
- It would be great to be clear on the modules delivered by this project.
- The connections to other projects should be clarified clearly.
- Are there APIs that the project feels it is responsible for, or does it use the APIs defined by others?
- Perhaps 1-2 committers per company
- More detail on what test is.
- Scope seems rather large. Not clear on what is for the first release, and interactions/dependencies with DCAE, policy, SO, Controllers. ......
- Not clear what deliverables are required to support the usecases
(Zhaoxing)
- Could this project proposal clarify how to support the Telcom use case(VoLTE), for example, how to onboarding TOSCA based VNF and use it as building block for service design?
- Could this project proposal clarify its relationship/dependency with ICE? It seems that the ICE project will provide guideline/process definition for certification and this project will provide tools to support ICE?
Active and Available Inventory (AAI) (5/11/17)
Review Comments:
Clarity of Scope:
Reasonable and Well defined Scope:
- quite ok, except for the deliverables.
- Editorial: refers to MSO, should be SO.
Identification of SW modules and APIs being developed and delivered to other components
- No, this could be clearer
Follow project and LF guidelines for contributors/committers
- perhaps 1-2 committers per company
Identification of dependences and assumptions on other components and open source
Overlap
Intentional and unintentional overlap
- ok, no
overlap with external opensource efforts
-ok, no
Risk Management
Sufficient resources allocated to deliver on time:
- ok
At least 3-4 companies involved to provide diversity:
- ok
Available seed code and maturity
-ok, yes
Relevance and prioritization
Alignment with merger release
- yes required
Alignment with use cases
- appears so, but use cases not mentioned.
Sound technical solution solving a real need.
- yes, ok
(Stephen)
- In this scope it would be great to be clear on the modules that are to be delivered in general.
- In the scope it would be great to clarify whether this project responsible for any APIs to be defined, I assume so.
- Perpahs 1-2 committers per company?
- Editorial. Referens to MSO, should be SO now.
Network Function Change Management Project Proposal (5/11/17)
Review Comments:
Clarity of Scope:
Reasonable and Well defined Scope:
- it was unclear what this was to deliver, requirements or code.... Then, if there was code whether that was overlapping with other projects...
Identification of SW modules and APIs being developed and delivered to other components:
- It would be great to be clear on the code module deliverables from this project so we can understand whether there are overlaps in the deliverables with the other projects (e.g. SDC). i.e. what is planned to go into the repo NFCM. i.e. from the scope of this, it feels like it should be part of SDC or produces requirements, however I would like to understand the deliverables to get a clearer understanding of that
Follow project and LF guidelines for contributors/committers
- no, further diversity would be appreciated.
Identification of dependences and assumptions on other components and open source
Overlap
Intentional and unintentional overlap
- This can be clarified when the modules are clarified. Keep in mind that the code can only go into one repo
overlap with external opensource efforts
Risk Management
Sufficient resources allocated to deliver on time:
- depends on scope
At least 3-4 companies involved to provide diversity:
-no, one company
Available seed code and maturity
- indicates, that there is.
Relevance and prioritization
Alignment with merger release
- Its general
Alignment with use cases
- Independent, i.e. could release with or without deliverable
Sound technical solution solving a real need.
- yes
(Stephen)
- It would be great to be clear on the code module deliverables from this project so we can understand whether there are overlaps in the deliverables with the other projects (e.g. SDC). i.e. what is planned to go into the repo NFCM. i.e. from the scope of this, it feels like it should be part of SDC or produces requirements, however I would like to understand the deliverables to get a clearer understanding of that.
External API Framework (5/15/17)
Review Comments:
Clarity of Scope:
Reasonable and Well defined Scope:
- mainly ok
- modules to be delivered could be clearer.
- On the models, discussion with the modeling project about what are the models covered in this project vs the modeling project would be great. I can see what the line would be though. the TMF SID maybe one point to align on (not clear how that would be part of integration)
- Not sure what TMF SID is doing here, relation to model project ......
Identification of SW modules and APIs being developed and delivered to other components
- no should be included.
Follow project and LF guidelines for contributors/committers
Identification of dependences and assumptions on other components and open source
Overlap
Intentional and unintentional overlap
- potentially with models on model driven interface, just needs to be clarified.
- TMF SID? with modelling
overlap with external opensource efforts
- ok
Risk Management
Sufficient resources allocated to deliver on time:
- yes
At least 3-4 companies involved to provide diversity:
- yes
Available seed code and maturity
- No information, could be stated if there is.
Relevance and prioritization
Alignment with merger release
- independent, necessary area but release could happen with/without
Alignment with use cases
- independent, not related
Sound technical solution solving a real need.
- Yes.
(Stephen)
- Scope: Question: Does this provide a SB API definition into ONAP (or use one) and a "plug-in" environment for bringing the external interfaces?
- Scope: Clarify the code modules that are a deliverable.
- Scope: On the models, discussion with the modeling project about what are the models covered in this project vs the modeling project would be great. I can see what the line would be though. the TMF SID maybe one point to align on (not clear how that would be part of integration)
External System Register (5/14/17)
Review Comments:
Clarity of Scope:
Reasonable and Well defined Scope:
- Could be clearer, exemplify with a use case.
Identification of SW modules and APIs being developed and delivered to other components
- could be clearer
Follow project and LF guidelines for contributors/committers
- Yes, but one company
Identification of dependences and assumptions on other components and open source
Overlap
Intentional and unintentional overlap
overlap with external opensource efforts
Risk Management
Sufficient resources allocated to deliver on time:
- ok, but one company
At least 3-4 companies involved to provide diversity:
- no
Available seed code and maturity
- Yes
Relevance and prioritization
Alignment with merger release
Alignment with use cases
Sound technical solution solving a real need.
(Stephen)
- Scope: could be a little clearer by way of example..
...