anuket-project / anuket-specifications Goto Github PK

One of the feedback of former chapter 6 was as follow :

"can we add HW hardening to edge cloud items ?"

We suggest to extend the feedback to a wider perimeter and clearly define what are the differences that we see between Edge Computing and Datacenter if there are any.

Any opinions are most welcome on the topic as this issue might be general for all the Reference Model.

Per PG, update to be completed by next Monday.
PG to update terms in chapter 1
PG to provide reference for vApp

Incorporate NF-VI interfaces: NFVI- VIM interfaces

Specific Action

• JB - Action - can have performance results? not necessarily pass/fail of a test.
• JB - Action - Ch. 10 address resiliency is part of testing to be done.
• JB - Parking LOT. NEED TO DEEP DIVE DIALOG HERE> Performance and # of resources needed for a particular service provider is a big concern for VNF Vendors.
• JB P3 - NFVI must be architected to allow High Availability and Resilience for hosted VNFs.
• Add testing guiding principle and test case that NFVI should not be SPOF
• Add also, NFVI may evacuate nodes under certain circumstances, and thus VNFs are expected to provide additional availability/resiliency on their own to achieve their targets
• Add also: Frames (or packets) performances requirements should come with acceptable packet loss rate for the VNF, and for each of its interfaces as some interfaces are dataplane, others are management, others are east/west HA; OVP could test the VNF resilience to the packet drop
• Assess need to identify acceptable latency requirements per interface?

Karine to provide update/PR to chap 4; input will need to be propagated to additional chapters for Storage-Intensive.
Diagram includes SDN-C; Need to remove from diagram

Problem:
Various sections (terminology, architecture, infrastructure abstraction) use VNFs and CNFs interchangeably, describing them as "just different workloads of an NFVI". Consequently, functionality for enabling and managing containers is wrongly allocated to the NFVI/VIM.

VNFs and CNFs work on different abstraction-levels, though:
VNFs are (groups of) VMs and build on infrastructure-level abstractions (machine, network, disk / block storage) which is what NFVIs/VIMs provide.
CNFs are processes build on OS-level abstractions (process groups, network sockets, file sockets, ...) which is what an OS + container runtime + container orchestration platform layer on top of an infrastructure layer provides.

Proposed fix:
We need to a) remove any statements suggesting CNFs (like VNFs) would run / consume resources / be managed by the NFVIs/VIMs directly and b) introduce an application orchestration layer on top of the NFVIs/VIMs that runs CNFs and decouples them from infrastructure resources.

Consequences if not fixed:

• confusion of which functionality belongs into infra vs app layer and consequently, which services need to be exposed by NFVI/VIM and which not
• misalignment with industry standard practice (public cloud, OpenStack vs Kubernetes, ...) of cleanly separating infra and app layers
• losing benefit of running same container/app orchestration platform on different NFVIs/VIMs technologies and ability to "swap out" / mix-and-match

Once terminology approved, please update 3.2 accordingly.

Reviewers : Mark S, Tom K

Hi Beth:
Please address this PR.
#123

@[email protected] suggested the following text for 1.3

All NFVI APIs must ensure Interoperability (multi-vendor, components substitution), drive Simplification, and come from Open Communities and Standards Development Organizations. Through such APIs will NFVI resources be discovered/monitored by management entities, configured on behalf of VNFs and consumed by VNFs.

As per standard community setup procedure.

i.e. a CODE_OF_CONDUCT.md needs creating and populating appropriately.

This relates to #156 about the need to add RL-1 (technology agnostic) reference model description including use cases that explain how the reference architectures should be operated upon from various actors perspective (VNF Developer, Cloud Service Provider, Cloud Service Consumer).

Ch1: Beth to provide updated language for Arch fork PR

feedback

• Entire HW Host Profile (Network) needs to be reviewed.
• Define what networking and tenant needs are intra vs. inter.=> linked to chapter 3 with definition of tenants
• Table of NIC configuration specify that prot speed is physical
• Number of PCI slot to be reviewed

we need to strengthen this part.

Specific Action

• JB - Action - are tests that legitimately belong in OpenStack, or stay in OPNFV?

Specific Action

• JB - Action - need to consider degrees of 'passing', clarify conformance vs. performance. Need to analyze upstream reuse vs. new.
• Ensure clarification of:
  : JB implementations to be certified not the model and ref arch (they are documents/artifacts)
  : JB reference implementetion needs to pass all tests

The following issues belong in CH2-4: VNF drivers and where they live. How to expose hardware? Lose benefits of SRIOV? Etc.
Defining acceleration interfaces.
How exactly will ref model and ref arch certifications work?
Exposition of acceleration technologies to VNFs?
Acceleration embedded into VNFs or into NFVI?
Comment RH: VNFs suppliers will not support all the acceleration technos offered by NFVI, VNFS care about what NFVI is
Certification? OVP NFVI certifcation program, expand OVP to CNTT objectives

Currently includes RL-0 Reference Model
RL-2 Reference Architecture -- first version based on OpenStack

IMHO, there is wide gap between the RL-0 abstract model and the RL-2 OpenStack based High Level Reference Architecture. Suggest a cloud-technology agnostic RL-1 model.

As proposed during the meeting, before adopting Chapter specific meetings, we need to cleanup the existing documents and remove any redundancy.

This is an issue to capture the comments and notes from the F2F in the Etherpad.

2. GAPS (Day 1):
   IT and ML workloads -- Need to define the types of workloads and cover at least to a certain extent, IT as well as VNF (network functions). This needs to be spelled out in the section on what is not covered.

1. Terminology with respect to VNF profiling requirements. Need additional clarity around profiles. ch01
   JB - Clarifications needed.
   BFC - Lots of clean up on wording required overall, but Chapter 1 has the definitions, so important to get correct here.

2. Tenant is defined in Chapter 1 and in Chapter 3 are different. Which one should we consider here? Need to define the tenant in more detail and reconcile the differences.
   JB - Clarifications needed. Slicing vs. Tenant, etc.
   After the definition is done use the definition in a consistent way. BFC -- Agreed.

3. Release 1 MVP is only Infra and VNFs; CNF-s will be partially supported in Release 2
   JB - clarify position and look at best way to support/define CNF articulated. (also impacts Ch. 3)+1 (high level only in CP1)
   Can this be clearly stated in the document and can we remove the refernces ot CNF-s from the Release 1 branch to avoid confusion? Overall CP1 is missing the use cases, once these are added, much of the confusion should be resolved.

4. CNTT should collaborate very closely with the respective API workgroup of SDOs (ETSI, MEF, TM Forum). To collate the relevant APIs from these SDOs would require special permission since information might not be available to the public. eg. MEF LSO APIs & TM Forum OpenAPIs are accessible by members only.
   JB Ch. 1 and 7. And also how CNTT community operates outside the document.
   [G0]: ETSI NFV OpenAPI-s are accessible for everyone here: https://forge.etsi.org/gitlab/nfv.
   OpenStack API-s: https://docs.openstack.org/stein/api/

In 5.1
"A NFVI SW profile is a set of virtual resources with specific behaviour, capabilities and metrics."

Needs rewording

Various comments recorded against PR need to be resolved.

Comment from Paris Meeting: Chapter 03 Infrastructure Abstraction - GAPS (Day 1):

related to the Etherpad issue "Discovery of Resources"

Specific Action

• JB - Action - Get proper language to use, how to describe test cases so they can be implemented in best possible way.

Specific action

• JB - Action - Ensure CNTT transparency is important to collaborate w/OVP and ONAP, SDK PTL - need deep dive sessions for this (Katherine L./Huawei)
• JB - Action - identify what has been done before

Outputs

• Schedule meetings with key partnership to exchange information and deep-dive into partner processes
• Incorporate inputs from key partnerships into Chapter 10, leveraging process, definitions, test cases, etc

Chapter 1.6 needs a comment explaining the scope that includes both NFVI resources and interactions with external components.
Assignee: @karinesevilla

we don't see the benefit of this change.

We will keep HW and SW for now

We need a licence for the CNTT documentation that is being produced.

i.e. LICENSE.md to be created and populated appropriately.

Specific Action

• JB - Action - Verification will show which validation it passed, lifecycle management, etc. -- need to clean up relationship between CNTT, ONAP, etc.
• JB - Action - need to define where the test cases would live? What is the handover between CNTT and OPNFV.

Add to Chapter 6

feedbacks

• Be clearer about what is the speed unit of execution, speed, standard metrics, etc. similar have technology to define KPIs.
• How does chip architecture get accomodated. Can we do it from operational model, then down from there.
• CPU architectue is missing from the Compute profile
• Would like to see CPU speed as part of model/profile. and speed of architecture. e.g. m4, m5, c5...
• Simultaneous MultiThreading (SMT/HT) is hardware specific, maybe we need to make it optional or remove it?

During the F2F we said that CPU architecture should be parking lot however some CPU characteristic (eg speed) should be present .

we need to strengthen this part.

Specific Action

• Action - what is the acceptable packet loss in the model? ch03 to define, mapping in ch04
  JB Clarify about KPIs, benchmarking, other parameters, options, extensions, methods in the KPI area in which chapters?
  Metrics and Benchmarking: ETSI NFV TST009
• Include information on how to view Conformance (to standards, functional and perf benchmarks)

Once terminology is approved, please update figures accordingly.

Assignee: @karinesevilla

Specific Action

• Action - add VNFs that are being certified in ONAP (link to ONAP requirements somewhere in model)
• Action - what is the acceptable packet loss in the model?
• Action - Connect work done on alarm correlations w/ONAP OMS? PTL synergies with CNTT) for Service Assurance

Table 3-8: should contain max allowed packet drop rate?
Table 3-6: would it make sense to indicate whether HyperThreading has impact on performance (recommendation to enable or disable it)?

Specific Action

• Reach out and discuss involvement in Chapter 10 with:
  Gergely Csatari [email protected]

Based on feedback from the group, the suggest is to rename Chapter 3 to NFVI Components or Abstraction, which is more description than the term model.

#60

A proposal / PR to be created once #100 has been merged.

good question

maybe we have to removed that row from the table 5.1?

Specific Action

• JB - consider environmental requirements +1

Standard practice for communities is to have a CONTRIBUTING.md file which details the steps needed to be able to contribute.

Per mtg 2/7/19 ASawwaf to update or withdraw.

Lots of feedback on that topic

• Network attached storage
• Tenant vs storage networking
• In memory storage vs physical HDD/SSD => different characteristics and use

we need to strengthen this part.

Recognize that there maybe a conflict between "standards/open" and "interoperable"
Add as an action item to Chapter 11: Gaps