In this article, I am grouping all NFV related questions that I have been asked throughout the last online NFV Sessions and I hope that this may contribute to enriching the Community knowledge and NFV awareness in general.

I am also adding a link to the Session slides and video recording.

Q1: What's the role of SDN with NFV?

The terms NFV/SDN have always been used jointly and that might give the impression that SDN is a basic element in the NFV Architecture. SDN is an important concept and derived technology that greatly improves the control and management of the NFV infrastructure network. Conversely, the functional blocks of an SDN architecture can be deployed in the form of virtualized network functions hosted on an NFV infrastructure. However, SDN is not a mandatory technology to fulfill NFV.

Clause from First NFV White Paper, Oct 2012. 

NFV is highly complementary to Software Defined Networking (SDN),

but not dependent on it (or vice-versa). NFV can be implemented

without an SDN being required, although the two concepts

and solutions can be combined and potentially greater value accrued 

In NFV Context, SDN is commonly referred as "DC SDN" and in an OpenStack environment, for example, it is deployed as a backend for neutron.

If it exists, neutron relays all networking API Call to SDN or SDN may get it directly from a northbound system (e.g. NFVO). In this way, it handles all networking control and management for the infrastructure and thought to enable many use cases that can’t be realized using neutron such as Network Automation, Service Function Chaining, etc.

Q2: What is the difference between NFVO Vs VNFM?

NFVO and VNFM are both functional blocks of the NFV-MANO, Management, and Orchestration Architectural Framework.

The VNFM is responsible for the Life Cycle Management (LCM) of VNF(s). This includes supporting interface operations and execution of workflows for:

• Instantiate VNF (create a VNF using the VNF on-boarding artifacts).

• Scale VNF (increase or reduce the capacity of the VNF).
   
• Heal VNF (corrective actions to repair a faulty VNF, and/or its VNFC instances and internal VNF Virtual Link(s))
   
• Change VNF flavor (changing the flavor, i.e., the deployment options, of an already deployed VNF)
   
• Operate VNF (changing the state of a VNF instance)
   
• Modify VNF information (support VNF configuration and information changes).
   
• Change external VNF connectivity (changing the external connectivity of a VNF instance)
   
• Terminate VNF (release VNF-associated NFVI resources and return it to the NFVI resource pool).

The VNFM is also responsible for VNF performance, fault and configuration management.

On the other hand, NFVO is the Functional block within the NFV-MANO Architectural Framework that manages the Network Service (NS) lifecycle together with VNF lifecycle (supported by the VNFM) and NFVI resources (supported by the VIM) to ensure an optimized allocation of the necessary resources and connectivity.

NFVO Functions can be classified into two main categories

• Resources Orchestration
   
• Service Orchestration

Please have a look at the below comparison

VNFM Vs NFVO

NFVO is also responsible of NS performance and fault management as well as VNF package management. Similarly, as with VNF LCM, NS lifecycle is related to a number of supported operations and execution of workflows, such as those used to instantiate, scale, heal and terminate an NS, as well as a diverse type of updates, e.g., adding/removing VNF instances to/from an NS, etc.

Q3: What is the best practice for VNF deployment? Is VM based or Container based?

Most of the current Telco NFV deployments are based on VMs and that actually suits most of the current VNF architecture provided by the well-known telco vendors.

However, more recent implementations are starting to introduce VNFs based on containers. The use of container-based virtualization is getting more considered, due to the industry momentum introduced by the requests for cloud-native VNFs. It is there in the VNF roadmaps for most of the vendors but not before 2019 in my opinion.

Q4: You mention that M2000 & U2000 (EMS) has a similar role of VNF Manager, don’t you think it must fit in OSS part?

Not really since VNFM is doing Life Cycle management of the VNF like instantiation, Scaling, etc which is not the role of EMS responsible of FCAPS (fault, configuration, accounting, performance, and security).

However, some vendors merge both solutions into one product and sometimes, VNFM can do what we call day-Zero configurations so it behaves like an EMS in that case.

But again, they are different. In my opinion, VNFM shouldn’t be part of OSS unless it is a generic one and merged with NFVO for one platform for E2E Orchestration.

Q5: Can you give examples for NFVO in Market?

There are many vendor-specific solutions such as NEC NetCracker Orchestrator, Cisco NSO, Ericsson Cloud Manager, Huawei Cloud Opera, Nokia Cloud band, and other Open Source projects/products such as Cloudify, Tacker, & rift.io. (rift.io is like a commercial deployment of Open Source MANO).

There are two well-known Open source initiatives in the Market 

• Open source MANO (OSM) - ETSI OSM is an operator-led ETSI community that is delivering a production-quality open source Management and Orchestration (MANO) stack aligned with ETSI NFV Information Models and that meets the requirements of production NFV networks
   
• Open Network Automation Platform (ONAP) - A Linux Foundation project, ONAP is a joint collaboration between AT&T ECOMP (Enhanced Control, Orchestration, Management & Policy) and Open-O (Open Orchestrator) initiative. 

Q6: What is the difference between horizontal and vertical scaling?

Please refer to the below comparison

Scale Out/In Vs Scale Up/Down

Horizontal Scaling can be classified into two types

• Scale out term refers to a process where one or more instances/VMs are added to the existing application.
   
• Scale in term refers to a process where one or more instances/VMs are removed from existing application.

Vertical Scaling can be classified into two types

• Scale up term refers to a process where resources (CPU/Memory) are added to an existing instance/VM.
   
• Scale down term refers to a process where resources (CPU/Memory) are released from an existing instance/VM.

Scaling is triggered automatically whenever a certain pre-configured threshold (e.g. CPU Utilization) is crossed or manually by an administrator intervention.

For example, an auto scale policy may imply that system should Scale out if CPU utilization exceeds 70% & Scale in if CPU Utilization goes below 20%.

In NFV environment, Scaling can be triggered from the below sources

• VNF/VNFM
   
• VIM (Virtual Infrastructure Manager)
   
• EM (Element Manager)
   
• OSS/BSS
   
• Manually by an operator

Q7: Please explain if the VIM of NFV and the heat engine of the OpenStack - are they the same or separate?

Well, Actually OpenStack with all the corresponding components (Nova, Neutron, Cinder, Heat, etc.) fits in VIM Block acting as the Virtualized Infrastructure Manager in the NFV ETSI Reference Architecture.

The Confusion comes sometimes about the difference between NFVO & Heat. 

Heat is an orchestration Engine that lies in the infrastructure layer and it provides some sort of “stacks” that can be automatically deployed over a certain PoD or DC let me say. Where NFVO has a bigger umbrella doing Service and Resource Orchestration across multiple Data Centers and the concept itself extends to an E2E Orchestrator who is doing the same across different domains and for both VNFs and PNFs.

There might be some interaction between NFVO/VNFM and heat in some deployments in case of VNF Instantiation or Scaling but it is not mandatory to use Heat generally.

Please refer to the below comparison

Heat Vs NFVO

Q8: A lot of packet processing such as DPDK features work in specialized HW such as ATCA. how vendor assures performance on commodity HW but not on proprietary?

DPDK requires compatible HW, namely compatible Network Interface Cards (NIC) and CPU models. However, unlike some other acceleration technologies, DPDK does not require specialized processors. In the latter case, specialized processors can be added to a commodity server (e.g. SmartNIC with an embedded processor) to enable off-loading part of the traffic processing from the main general-purpose processor to these specialized processors.

Moreover, although initially designed for the x86 ecosystem, DPDK is not a vendor-specific feature and recent versions are not related much to a specific hardware. Nowadays, DPDK is an open source community-driven software solution (software libraries) for enhancing packet processing. 

It is a large ecosystem. With a lot of supporting NIC Cards and processors. It is not tied to a certain HW or vendor solution.

However, guaranteeing the performance requires joint lab/testing work between the vendors along the vertical NFV Stack. 

Q9: Does OpenStack have its own hypervisor or do we use VMware?

The strength of OpenStack lies in the fact that It has a pluggable architecture when it comes to integrating with Hypervisors, SDNs, etc.

OpenStack supports KVM natively and supports ESXi, Xen, and other hypervisors by deploying the right plugin. However, the native hypervisor for OpenStack is Linux QEMU/KVM and it is considered as the defacto Hypervisor for OpenStack. and this is the case of most of OpenStack NFV deployments.

Q10: Can we have EMS and VNFM in a single entity?

EM and VNFM are functional blocks providing different functionalities as specified in the NFV Architectural Framework. However, actual implementations can, as with many functional architectures, subsume into one single entity both functionalities.

Q11: How do you evaluate the operators’ contributions in NFV and in OpenSource initiatives?

The first NFV White paper published in Oct 2012 was a result of a cooperation of Tier-1 Operators such as AT&T, BT, Deutsche Telekom, Verizon, NTT docomo, Chine Mobile, and other operators.

Since that time, the ecosystem has expanded to reach more than 300 companies/organizations, including 39 network operators, in the ETSI NFV ISG.

NFV ISG was spun as an operator-led industry initiative to raise awareness and foster all industry stakeholders to provide interoperable solutions following NFV vision. Operators’ contribution has extended to participate directly in Upstream communities like OpenStack and mid-stream communities such as OPNFV and starting market-leading Open Source initiatives such as OSM and ONAP in addition to the standardization efforts done by all in ETSI NFV and other SDOs.

Q12: What is the exact role of Hypervisor?

A hypervisor is simply a piece of software that partitions the underlying HW physical resources (CPU, Memory, Storage, Networking), generates Virtual Machines, & allocates the portioned resources to them.

Virtual Machine, on the other hand, behaves typically as a physical server that has all the ingredients needed for a physical server (CPU, memory, storage, NIC).

The role of the hypervisor in NFV is of the “virtualization layer” enabler of the NFVI for the case when virtualized compute resources are delivered in the form of a VM.

Please refer to the below comparison for more details on the hypervisor types

Native Vs Hosted Hypervisors

Q13: Can operator reuse existing Hardware/infrastructure that is near end of life to be part of NFVI. e.g 2G infrastructure if the operator is decommissioning it?

Most of the old telco platforms are special-purpose Hardware that can’t be used decoupled from their application software and that’s actually is one of the main pain points and drivers for NFV.

Whether specific hardware can be reused may depend on a case-by-case basis, upon analysis by the operator and equipment suppliers.

Q14: Why NFV for Mobile Core is now introduced (LTE/EPC) and not before particularly in CDMA PS Core (PDSNs) and other NFs like BSC/RAN? 

Selection of Network Functions that are to be virtualized is subject to many criteria either from the Operator side or the vendor side.

Factors that can influence what network functions are delivered as virtualized include the network function software readiness to be run on a virtualized platform, market demand, end of life of existing hardware, and others. One of the other factors is the network function goal itself.

One of the main factors is the Network Function characteristic. For example, if it is a heavy transcoding workload, Vendor may postpone the virtualization of such function till the virtualized infrastructure is capable to deliver such requirements with the expected performance metrics.

Q15: Could you please explain or refer to any groundbreaking achievements that allowed NFV growth lately?

NFV Kick-off was in Oct/Nov 2012. The technology took some time to mature and for the Telco Community to embrace. In my opinion, the tough competition with the new market players such Public cloud providers (Amazon, Google, etc) and the OTT threats to Mobile Operators revenue have accelerated the operators' adoption for NFV/Cloud. Also, the maturity of open source products such as OpenStack has provided a good motivation lately.

Q16: What percentage of NFs do you think could be virtualized?

Every enterprise has to put its own virtualization roadmap according to its strategy. What to be virtualized and when. Theoretically, all Network Functions can be virtualized and even bare metal deployments can be governed by a common NFV management.

Q17: In the standard, there are two interfaces between VNFM and VNF and same as VNFM EMS for VNF both are the same function?

The Ve-Vnfm-em reference point is used for exchanges between EM and VNF Manager and The Ve-Vnfm-vnf reference point is used for exchanges between VNF and VNF Manager. They share some common functionalities, for example, the VNF indicator interface which is the information supplied by the VNF or the EM to provide some indication of the VNF behavior. VNFM can use these indicators in conjunction with virtualized resource data to perform auto-scaling decisions.   Also, both reference points share most of the operations of the VNF Lifecycle Management interface produced by the VNFM and consumed by the EM and/or VNF.

One of the differences is the VNF Configuration Interface which is available only on the Ve-Vnfm-vnf - The VNF Configuration interface on the Ve-Vnfm-vnf reference point shall support setting of initial virtualization-related configuration parameters for a VNF/VNFC instance.

Q18: Can we have independent VIM, VNF Manager and NFV Orchestrator running. e,g, from different vendors?

Yes. This will be a multi-vendor setup. In this case, system integration efforts need to consider all three reference points between VIM, VNFM and NFVO. The REST APIs that ETSI NFV is specifying are intended to enable multi-vendor solutions.

Q19: Does the VNF Manager is kind of cloud management platform?

VNF manager is the entity responsible mainly of the VNF Lifecycle management and that may extend to some Configuration management functions.

In the context of NFV the cloud management platform within the MANO Framework will be the VIM (Virtualized Infrastructure Management).

OpenStack is an example which is comparable with AWS and Azure for public clouds.

Q20: Please give an example of VNFM and is it vendor-specific or not?

Normally, there are two categories or two wordings used in the market

• Specific VNFM- This maps to a vendor (VNF) dependent VNFM managing its own VNF.
   
• Generic VNFM- This maps to a vendor-independent VNFM that can manage 3rd party VNFs. 

An example of Commercial VNFMs is Cisco ESC, Nokia Cloud band, Ericsson Cloud Manager, etc which can also act as a generic VNFM for 3rd part VNFs.

Tacker is a good example of an open source generic VNFM. ONAP, for example, is recommending the generic VNFM model.

Q21: OpenStack community has made many modules, which are the modules for VIM functionalities?

OpenStack platform with all modules can be positioned in NFV VIM Functional Block.

Q22: NFVO & VNFM can be on combined with same module/node?

NFVO and VNFM are functional blocks providing different functionalities as specified in the NFV Architectural Framework. However, actual implementations can, as with many functional architectures, subsume into one single entity both functionalities.

Q23: How OpenStack provide support to Tier one operators since it is an open source product, and how CSP can rely on it without reliable support?

Getting an open source product doesn’t mean that you don’t get a support. For sure, you have the option to download the vanilla version from OpenStack and deploy it by yourself and getting the support by your own developers and engineers but that’s very aggressive direction. Normally, you get the market distribution of open stack and you get licenses and support from the supplier such as RedHat, Mirantis, etc. The support is there and on top of that, you have the community support. It is really a large ecosystem that backs the technology and guarantees the continuous innovation.

Q24: Does NFV focus only on virtualizing the telecom network functions?

Any enterprise or environment that share the same Characteristics and the requirements of NFV (For example, Carrier-grade performance, High availability, Telco-like Workloads) can leverage the potentials of NFV and the framework defined by ETSI NFV.

Q25: Which NFV Functional blocks does the RedHat Director or Contrail Server Manager belong to?

For RedHat OSPD, it is part of RH Under-cloud i.e. deploying OpenStack so NFV doesn’t explicitly determine an architectural framework for such Management/deployment tools and that applies as well to Contrail Server Manager. However, I’d put it in the VIM Functional Block due to the close relation with the virtualized infrastructure.

Q26: How ETSI NFV architecture fulfill MOBILE EDGE COMPUTING?

Mobile Edge Computing or Multi-Access Edge Computing is one of ETSI Focusing area

http://www.etsi.org/technologies-clusters/technologies/multi-access-edge-computing

The Mobile Edge Host is based on NFVI hosting the Mobile Edge Applications. So basically, MEC is leveraging ETSI NFV principles and concepts.

Standardization of both technologies is being carried by ETSI.

I am pointing to one specification that is currently in progress. 

ETSI GS MEC 017: "Mobile-Edge Computing (MEC); Deployment of Mobile Edge Computing in an NFV environment". 

I believe that once it is published, it will clearly explain the relation.

Q27: What is the level of acceptance for operators to take up very high throughput services?

There are some standard RFCs benchmarking testing that can be run but what I do recommend is to build the lab environment on premises and do the testing in-house. Also, 3rd party testing/Consulting Companies such as EANTC plays a good role in this domain.

Q28: What are your expectations for ONAP and OSM?

I hope they merge to avoid industry fragmentation.

Q29: Contrail now needs OpenStack; does Juniper now position it as a part of VIM as a replacement for Neutron instead or besides SDN Controller?

Contrail as a DC SDN is positioned as a backend for neutron. So, it is implicitly taking the role of neutron. Some vendors draw SDN as a subset of VIM and some others draw a new Functional block under the VIM but I believe it is best positioned in the VIM Functional Block.

Q30: Does each vendor should either follow OSM or ONAP?

My recommendation for the vendors to have presence and contributions in both initiatives and try to have a flexible modular design for MANO solution that is compliant to ETSI and gives the customers flexibility to add Modules/Features that best suits Customers’ requirements.

Q31: What about Tacker? Is it promising? As a VNFM, will that contradict the point that the VNFM vendor should be the one who does the VNF Or Tacker will be an NFVO or a generic VNFM or both?

Tacker is an open source generic VNFM and NFVO solution and two years back, I saw that a very promising project but for some reasons, I couldn’t see commercial deployments. Also, with more and more open source initiatives doing the same thing, this may impact negatively open source initiative when it comes to market adoption. 

Q32: Why we need to use SDN as NFVO can make its function?

This is not true as the two entities have different roles. NFVO is mainly responsible for Network Resource Orchestration and Service Orchestration while the DC SDN is responsible for the overlay DC networking.

When it comes to the networking part of the network service; The Inter-VNF path or links is defined as part of Network Service Descriptor or VNF Forwarding Graph Descriptor which is part of NFVO functionalities. This info can be pushed to VIM (e.g. Openstack) or SDN which uses this info to provision to create the Service networking.

So, we may say the definition comes from NFVO and configuring the agents/hosts is being done by VIM/SDN.

Q33: From performance point of view, is it enough to monitor the application layer KPIs or it is a must to monitor cloud layer performance as well

From FM/PM perspective, Operator must do the E2E monitoring for the whole vertical stack for NFV. So, getting the application counters and alarms from EMS is not enough to have the full stack visibility. SW/HW Faults and counters need to be monitored by introducing the relevant infrastructure monitoring tools.

Having the right set of tools in hand will allow operators to have an efficient RCA engine for the network services and VNFs. Faults and performance reports related to virtualized resources should be reported by the NFVI to the VIM and propagated/correlated by the VNFM and NFVO up to the OSS and/or the EM or the VNF itself. The NFVO and the VNFM may also take some immediate actions on some events.

Q34: Is it true that NFV-MANO does not take into account physical network functions?

No. The NFVO can manage hybrid network services combining VNFs and PNFs. However, NFV-MANO does not manage the lifecycle of PNF resources. From an NFVO viewpoint, PNFs are black-box entities exposing a number of connection points.

Q35: Is it true that NSs can be nested but only one level of nesting is permitted?

No. There is no theoretical limit to the number of nesting levels. Although in practice this number is expected to be low.

Q36: ETSI specifies REST APIs enabling multi-vendor interoperability at some of the reference points of the NFV Architectural Framework. Can I use these APIs if my architecture differs from the NFV architectural framework?

It all depends on how significant are the differences. For example, the APIs specified in ETSI NFV-SOL 003 for the or-Vnfm reference point can hardly be used if the functional split between the NFVO and the VNFM does not comply with ETSI standardization or if the two functional blocks are subsumed into a single entity. However, this does not prevent using the APIs specified in ETSI GS NFV-SOL 002 for the Ve-Vnfm reference point. Moreover, the APIs specified in an ETSI GS are independent of each others. For example, different APIs specified in ETSI GS NFV-SOL 005 can be consumed by different OSS components.

Below is the link to the recorded session.

Understanding NFV Online Session

Thanks and see you in next article.