[RI MVP] NFVI required State

[michaelfix]

RI MVP work item for Snezka: NFVI Required State

Placeholder to track status, and ask Q&A, for the creation (finishing) of NFVI Required State documentation, including Manifest Validations. Write the content in the respective RI chapter(s).

Lead: @msidana (Manik), @opensource-tnbt (Sridhar)

[michaelfix]

@msidana , @opensource-tnbt - can you update on status?

[msidana]

@mf4716 I haven't been following RI activitirs and threads and also don't have the lab access. Can you please check with @opensource-tnbt , he would have a better idea on this.(I don't have the lab access as well)

[michaelfix]

@msidana (Manik), that is okay. The ask from the last RI/RC status call, was that we needed someone to partner with Sridhar to complete the necessary content. You had mentioned you can reach out to Sridhar to see how to help him. Can you do that?

As discussed last week, the ask is to complete the RI content, at least the initial pass, which would include things like providing the meta data which is needed to drive the actual state of the NFVI (e.g. huge page) that would be used as inputs into installer. In essence, requirements correlation and traceability from the RA/RM requirements documents which can be found here:

o RM 5: https://github.com/cntt-n/CNTT/blob/master/doc/ref_model/chapters/chapter05.md -> RM requirements o RA 2: https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter02.md --> RA Infra Requirements o RA 5: https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/chapters/chapter05.md --> RA API Requirements

More specifically, NFVI Target State is RI-1 Chapter 3, and @fuqiao123 (Fu Qiao) is the Lead. The initial content for RI-1 Chapter 3 can be found here on GitHub, which was created with the following merged PR #582 .

My recommendation would be to reach out to @fuqiao123 @opensource-tnbt , and @jiaqiang-cmcc , and confirm Ch3 is complete, and matches the above for the MVP. If so, we can review as a team and close the issue, but the expectation is that the Requirements to Create the Target State NFVI are clear, and the meta-data elements clearly document. Then, we can close.

[msidana]

@mf4716 Created an initial PR #813 as initial content based on discussion with @opensource-tnbt. @fuqiao123 Can you please assist if the tests/frameworks are identified for NFVI required state.

[jiaqiang-cmcc]

@msidana I was planning to create a PR to add more items for NFVI profile based on the contents of RA2 and RA5. Currently I am working on it, when it ready, I will invite you to review.

In PR #813 it said a set of tests, but I think they should belong to "certification". RI ch03 should not include this.

[michaelfix]

@jiaqiang-cmcc , @msidana - hopefully, this clarifyies:

For RI chapters:

• Ch02: RI Requirements - Issue #401 - right now there is no PR, but here is the link to the RI-1 Chapter 2 for reference. This issue, 401, is to provide initial content which is the requirement of Reference Implementation (examples: write requirements for RI based on a) open source, b) comply to reference architectures, etc)

• Ch03: NFVI + VNF Target State & Spec - this current issue #796 with open PR #813 - is to define the actual state of the NFVI and list out meta-data elements (e.g. huge page) that would be used as inputs into installers; this is the RA/RM requirements traceability.

If you're writing content for the same chapter, please use just one PR and add commits. Will be easier and faster.

If there is any confusion though, please contact each ASAP.

[fuqiao123]

@jiaqiang-cmcc , @msidana - hopefully, this clarifyies:

For RI chapters:

• Ch02: RI Requirements - Issue #401 - right now there is no PR, but here is the link to the RI-1 Chapter 2 for reference. This issue, 401, is to provide initial content which is the requirement of Reference Implementation (examples: write requirements for RI based on a) open source, b) comply to reference architectures, etc)
• Ch03: NFVI + VNF Target State & Spec - this current issue #796 with open PR #813 - is to define the actual state of the NFVI and list out meta-data elements (e.g. huge page) that would be used as inputs into installers; this is the RA/RM requirements traceability.

If you're writing content for the same chapter, please use just one PR and add commits. Will be easier and faster.

If there is any confusion though, please contact each ASAP.

For Issue #401, I think I have created a PR and it is now merged. So if no other comments on that ,I suggest we close #401

[jiaqiang-cmcc]

OK, let's use the PR #813 only for all needed contents for Ch03.

[msidana]

@msidana I was planning to create a PR to add more items for NFVI profile based on the contents of RA2 and RA5. Currently I am working on it, when it ready, I will invite you to review.

In PR #813 it said a set of tests, but I think they should belong to "certification". RI ch03 should not include this.

Ok sure. Thanks for your reply and clarification. Since you have already documented the content, can you mark yourself as an assignee for #813 and perhaps continue on the same PR (or a new one, whichever way you prefer) ?

[michaelfix]

status?

[jiaqiang-cmcc]

Hi @msidana and @mf4716

Currently, I have no new input for chapter 3.

Yesterday I had checked all the content of RA2 and RA5 to find if there are any meta-data items missing. But I am not sure if any of them are relevant to NFVI required state. Anyway, I put all items from RA chapter into one table as following. If you think there is one should be included, we can discuss further on this.

RA1: Chapter 2.3 Openstack Requirements describes the requirements related to the following 8 domains: general(gen), infrastrucutre(inf), VIM(vim), Interface & API(int), Tenants(tnt), LCM(lcm), Assurance(asr), Security(sec).

Ref #	Description
req.gen.ost.01	must use OpenStack APIs.
req.gen.ost.02	must support dynamic request and configuration of virtual resources through APIs.
req.gen.cnt.01	should consist of stateless service components. However, where state is required it must be kept external to the components.
req.gen.cnt.02	should consist of service components implemented as microservices that are individually dynamically scalable.
req.gen.scl.01	should support policy driven auto-scaling.
req.gen.rsl.01	must support resilient OpenStack components that are required for the continued availability of running workloads.
req.gen.rsl.02	should support resilient OpenStack service components that are not subject to req.gen.rsl.01.
req.gen.avl.01	must provide High Availability for OpenStack components.
req.inf.com.01	must provide compute resources for VM instances.
req.inf.com.02	should include industry standard hardware management systems at both HW device and platform level
req.inf.com.03	should support symmetrical CPU multi-processing with shared memory access as well as multi-threading.
req.inf.com.04	must be able to support multiple CPU SKU options to support Base, Network Intensive, and Compute Intensive infrastructure profiles.
req.inf.com.05	must support Hardware Platforms with NUMA capabilities.
req.inf.com.06	must support CPU Pinning.
req.inf.com.07	must support different hardware configurations to support Base, Network Intensive, and Compute Intensive infrastructure profiles.
req.inf.stg.01	must provide shared Block storage for VM Instances.
req.inf.stg.02	must provide shared Object storage for VM Instances.
req.inf.stg.03	may provide local file system storage solution for VM Instances.
req.inf.stg.04	may support Software Defined Storage (SDS) that seamlessly supports shared block storage, object storage and flat files.
req.inf.stg.05	should be able to accommodate VNFs that store back into its image through use of hypervisor attached volumes.
req.inf.stg.06	should make the immutable images available via location independent means.
req.inf.stg.07	should provide high-performance and horizontally scalable VM storage.
req.inf.stg.08	should allow use of externally provided large archival storage for its Backup / Restore / Archival needs.
req.inf.stg.09	should make available all non-host OS / Hypervisor / Host systems storage as network-based Block, File or Object Storage for tenant/management consumption.
req.inf.ntw.01	must provide virtual network interfaces to VM instances.
req.inf.ntw.02	must include capabilities for integrating SDN controllers to support provisioning of network services, from the OpenStack Neutron service, such as networking of VTEPs to the Border Edge based VRFs.
req.inf.ntw.03	must support low latency and high throughput traffic needs.
req.inf.ntw.04	should support service function chaining.
req.inf.ntw.05	must allow for East/West tenant traffic within the cloud (via tunnelled encapsulation overlay such as VXLAN or Geneve).
req.inf.ntw.06	should support Distributed Virtual Routing (DVR) to allow compute nodes to route traffic efficiently.
req.inf.ntw.07	must support network resiliency.
req.inf.ntw.08	The NFVI Network Fabric should embrace the concepts of open networking and disaggregation using commodity networking hardware and disaggregated Network Operating Systems.
req.inf.ntw.09	The NFVI Network Fabric should embrace open-based standards and technologies.
req.inf.ntw.10	The NFVI Network Fabric must be capable of supporting highly available (Five 9’s or better) VNF workloads.
req.inf.ntw.11	The NFVI Network Fabric should be architected to provide a standardised, scalable, and repeatable deployment model across all applicable NFVI sites.
req.inf.ntw.12	The SDN solution should be configurable via orchestration or VIM systems in an automated manner using openly published API definitions.
req.inf.ntw.13	The SDN solution should be able to support federated networks.
req.inf.ntw.14	The SDN solution should be able to be centrally administrated and configured.
req.inf.ntw.15	must support multiple networking options for NFVI to support Base, Network Intensive, and Compute Intensive infrastructure profiles.
req.inf.ntw.16	must support dual stack IPv4 and IPv6 for tenant networks and workloads.
req.inf.ntw.17	should use dual stack IPv4 and IPv6 for NFVI internal networks.
req.inf.acc.01	should support Application Specific Acceleration (exposed to VNFs).
req.inf.acc.02	should support NFVI Acceleration (such as SmartNICs).
req.inf.acc.03	should not rely on SR-IOV PCI-Pass through to provide acceleration to VNFs.
req.vim.01	must allow infrastructure resource sharing.
req.vim.02	should support deployment of OpenStack components in containers.
req.vim.03	must allow VIM to discover and manage NFVI resources.
req.vim.04	must support Enhanced Platform Awareness (EPA).
req.vim.05	must include image repository management.
req.vim.06	must allow orchestration solutions to be integrated with VIM.
req.vim.07	must support a multi-tenanted environment.
req.vim.08	must support resource tagging.
req.vim.09	must support horizontal scaling.
req.int.api.01	must provide Control API endpoints to cloud platform core services.
req.int.api.02	must provide GUI access to tenant facing cloud platform core services.
req.int.api.03	must provide APIs needed to discover and manage NFVI resources.
req.int.acc.01	should provide an open and standard acceleration interface to VNFs.
req.int.acc.02	should not rely on SR-IOV PCI-Pass through for acceleration interface exposed to VNFs.
req.tnt.gen.01	must support multi-tenancy.
req.tnt.gen.02	must support self-service dashboard (GUI) and APIs for users to deploy, configure and manage their workloads.
req.lcm.gen.01	must support zero downtime expansion/change of physical capacity (compute hosts, storage increase/replacement).
req.lcm.adp.01	should allow for “cookie cutter” automated deployment, configuration, provisioning and management of multiple NFVI sites.
req.lcm.adp.02	must support hitless upgrades of software provided by the cloud provider so that the availability of running workloads is not impacted.
req.lcm.adp.03	should support hitless upgrade of all software provided by the cloud provider that are not covered by req.lcm.adp.02. Whenever hitless upgrades are not feasible, attempt should be made to minimize the duration and nature of impact.
req.lcm.adp.04	should support declarative specifications of hardware and software assets for automated deployment, configuration, maintenance and management.
req.lcm.adp.05	should support automated process for Deployment and life-cycle management of VIM Instances.
req.lcm.cid.02	should support integrating with CI/CD Toolchain for NFVI and VIM components Automation.
req.asr.mon.01	must include integration with various infrastructure components to support collection of telemetry for assurance monitoring and network intelligence.
req.asr.mon.02	should support Network Intelligence capabilities that allow richer diagnostic capabilities which take as input broader set of data across the network and from VNF workloads.
req.asr.mon.03	must allow for the collection and dissemination of performance and fault information.
req.asr.mon.04	The NFVI Network Fabric and Network Operating System must provide network operational visibility through alarming and streaming telemetry services for operational management, engineering planning, troubleshooting, and network performance optimisation.
req.sec.gen.01	must provide tenant isolation.
req.sec.gen.02	must support policy based RBAC.
req.sec.gen.03	must support a centralised authentication and authorisation mechanism.
req.sec.zon.01	must support identity management (specific roles and permissions assigned to a domain or tenant).
req.sec.zon.02	must support password encryption.
req.sec.zon.03	must support data, at-rest and in-flight, encryption.
req.sec.zon.04	must support integration with Corporate Identity Management systems.
req.sec.cmp.02	must comply with all applicable standards and regulations.
req.sec.cmp.03	must comply with all applicable regional standards and regulations.
req.sec.ntw.01	must have the underlay network include strong access controls that comply with ISO 27001 and adhere to the V1.1 NIST Cybersecurity Framework.
req.sec.ntw.02	must have all security logs stored in accordance with ISO27001.
req.sec.ntw.03	must have the underlay network incorporate encrypted and/or private communications channels to ensure its security.
req.sec.ntw.04	must configure all of the underlay network components to ensure the complete separation from the overlay customer deployments.

RA1: Chapter 5 Interfaces and APIs describes the baseline version regarding to Openstack Service APIs.

OpenStack Service	Link for API list	Baseline Version
Identity: Keystone	https://docs.openstack.org/api-ref/identity/v3/index.html?expanded=#identity-api-operations	Version 3.10
Compute: Nova	https://docs.openstack.org/api-ref/compute/	Version 2.1
Networking: Neutron	https://docs.openstack.org/api-ref/network/	Version 2.0
Imaging: Glance	https://docs.openstack.org/api-ref/image/v2/index.html#images	Version 2.0
Block Storage: Cinder	https://docs.openstack.org/api-ref/block-storage/v3/index.html#api-versions	Version 3.0
Object Storage: Swift	https://docs.openstack.org/api-ref/object-store/	Version 1.0
Orchestration: Heat	https://docs.openstack.org/api-ref/orchestration/v1/index.html#api-versions	Version 1.0
Acceleration: Cyborg	https://docs.openstack.org/api-ref/accelerator/v1/index.html	Version 1.0

[michaelfix]

Yesterday I had checked all the content of RA2 and RA5 to find if there are any meta-data items missing.

@jiaqiang-cmcc - hi, this great! Are you thinking this will go in section 3.4 of RI-1 Ch 3 PR #813 ? I believe it does.

[jiaqiang-cmcc]

OK, I will try to put above summary tables to the existing PR.

@msidana I haven't done that before, I mean, updating someone else existing PR as a co-author. In case I meet any trouble with git, I will let you know for help.

[michaelfix]

@jiaqiang-cmcc - very easy, and convenient - here's how:

1. go to the PR #813
2. click Files Changed (1)
3. next to the "Viewed" button, find the three dots ("...") and click those dots, select Edit File
4. make your changes
5. scroll to the bottom - change the default subject line to something meaningful, add a brief description, and click commit changes

[jiaqiang-cmcc]

@mf4716 Thanks a lot for your detail instruction, now my tables had been added into the existing PR #813

Let's wait for more contents from @msidana (Manik), @opensource-tnbt (Sridhar)

[michaelfix]

Glad to help @jiaqiang-cmcc !

@msidana , @opensource-tnbt - any additional review/comments for this ticket and the related PR #813 ? The only thing I can think of is a comparison needed for Prague comparing what was delivered, vs. the NFVI Required State info in this RI Core Chapter 3. If you agree, would you (are you) putting this together for the slide?

[msidana]

@mf4716 No comments on this PR.

[michaelfix]

@opensource-tnbt (Sridhar), @rrajesh70 (Rajesh) - any additional review/comments for this ticket and the related PR #813 ? The only thing I can think of is a comparison needed for Prague comparing what was delivered, vs. the NFVI Required State info in this RI Core Chapter 3. If you agree, would you (are you) putting this together for the slide?