Loading...

XML

Word

Printable

2019-07-02 ArchCom

Focus for this presentation is the 'self-service' LCM API

support for GRPC in CCSDK - this was due to p2p communication not many clients, and grpc is lightweight and well used in industry. WIll support DMaaP / messaging in the future
Concern that implementing this as part of the PNF upgrade UC was misleading. Does the UC description need to be changed?
Need to support plugin mechanism to support multiple PNF / VNF types through the common interface - this is already accounted for in CDS
what is the best approach for onboarding - appc or CDS?
- CDS used for e2e CL and instantiation
- In Frankfurt it will also support all needed use cases
- Long term APPC will become deprecated
- Steps are moving towards generic network controller architecture
Can we present this from an SO perspective at the SO session - next week
How do we customise the SO behaviours? Certain steps are not needed for VNFs that are needed for PNFs for e.g.
- Take with SO meeting
Good consensus on the direction, discussion is getting into the details

2019-04-09 ArchCom

There were questions about the compatability. It was clarified that this seems to be maintaining compatability
There were questions about the PNF, the response was that there is some work required but it seems to be a solvalbe problem.
On the slide with the branch to SLI engine (for directed grafph) and gRPC for (CDS blueprint processor). The response was that is not yet decided.
There were questions about when the designer uses the directed graph vs CDS and based on what.
There was a comment that a single YANG finle in CCSDK for the API definition was questioned as it was considered to be hard coding.
At high level there was support for the direction, though further discussion is required to bring it forward to a recomendation.

Oskar/Yuri/Chaker to progress it.

2019-03-19 Archcom

- It was talking about the LCM APIs that the controllers provide
- It describes the different approaches that SDNC and APPC take today
- The current approach provides confusion as to what we should use
- The presentation asks can we move towards a common API definition that comes from the CCSDK
There was a comment about the the relation to the TOSCA work in OASIS group.
There were comments on the different approaches for CDS-based LCM (branching at SO; branching at the controller LCM API handling; and branching at the DG level). There were comments that option 3 is not preferred.
It was commented that this seems to be in line with what people was thinking.
It seems there is appreciation for having CDS API to be the target and defacto approach, retaining alternative 2 for compatibility.
Cap and grow type of approach. Evolve with the CDS capabilities. Common LCM for all controller - the maintain option option A (2) for compatibility. Recommended for the Release E and projecting to ONAP we should get at the Arch F2F.