NFVRG Interim Meeting, NEC Laboratories Europe, Heidelberg

Tuesday 1 December 2015

1500 - 1730 CET

 

Chairs:  Pedro Aranda (pedroa.aranda@telefonica.com) - Acting

Diego Lopez (diego.r.lopez@telefonica.com) - Remote

                   Ramki Krishnan (ramki_krishnan@dell.com) - Remote

 

Note takers: Saverio Nicolini & Diego Lopez

 

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

 

Welcome and administrative matters

Presenter: Diego Lopez

Slides: https://www.ietf.org/proceedings/interim/2015/12/01/nfvrg/slides/slides-interim-2015-nfvrg-2-0.pdf

-       Mailing list: https://www.irtf.org/mailman/listinfo/nfvrg

-       Web site: http://trac.tools.ietf.org/group/irtf/trac/wiki/nfvrg

-       Proceedings: https://www.ietf.org/proceedings/interim/2015/12/01/nfvrg/proceedings.html

-       Pedro Aranda as acting chair in Heidelberg

-       Diego Lopez and Ramki Krishnan connected via WebEx

-       Saverio Nicolini and Diego for notes

-       20 attendants in total, 14 remotely via WebEx

-       Diego presents the main goal of the meeting: complete the discussion that could not be finished at the latest IETF, plus discussion on potential new interest areas for the RG

 

Draft updates and project reports

 

VNF orchestration and automated resiliency with VNFPOOL in service chains

draft-bernini-nfvrg-vnf-orchestration

Presenter: Giacomo Bernini

Slides: https://www.ietf.org/proceedings/interim/2015/12/01/nfvrg/slides/slides-interim-2015-nfvrg-2-1.pdf

-       The work in this draft is currently funded by the Trilogy2 European project

-       At v01. Orchestration framework for automated deployment, provisioning and composition

-       Main goal is to integrated ETSI NFV with VNFPOOL architecture

-       VNFPOOL is a concept for resiliency of stand alone VNFs

-       This draft wants to put VNFPOOL into an operator's data center, with an orchestrator (NFV-O) and an SDN controller for providing pools of VNF in service chains

-       There is the introduction of a VNF pool manager

-       Asking for adoption: either merging with another draft (resource management in service chains) or as a new item of the RG

-       Covering intra-DC and inter-DC concepts plus integration of control plane and management plane

-       Discussion

o   Giacomo: Is the proposed merge aligned with the chairs’ ideas?

§  Diego: Indeed. happy to see it and hoping this will include more documents in the future

o   Bhumip Khasnabish: benchmarking measures on how to maintain resiliency

§  Giacomo: It could be an interesting

-       Flash update on orchestration challenges for NFV including review of current orchestration frameworks. The draft is the merge of two previous drafts with the objective to get adopted by RG

 

Leveraging Segment Routing for Service Function Chaining

No current draft

Presenter: David LeBrun

Slides: https://www.ietf.org/proceedings/interim/2015/12/01/nfvrg/slides/slides-interim-2015-nfvrg-2-2.pdf

-       Use IPv6 segment routing as a starting point, but they would like to have segments to do more than just routing, thus to also represent a service

-       An application tells the kernel the segment and this get mapped to a service, the service application is implemented in a VM

-       Use cases: packet accounting, DPI, encryption, compression, proxy, video transcoding

-       Implementation architecture and performance evaluation presented

-       Asking for a feedback how to have direction towards RG

-       Discussion

o   Diego: More an application of segment routing to implement NFV in general

§  Yes. Working on the initial assessment before going for a full methodology for building NFV graphs 

o   Pedro Aranda: So you are addressing the implementation of the forwarding graph using segment routing

§  Yes

o   Bhumip: Any other use cases in mind?

§  We are looking for additional use cases

§  Bhumip: Would you consider reliability as well as accounting? Addressing the whole FCAPS?

§  We will probably consider this

 

NFVI PoP network topology: Problem statement

draft-bagnulo-nfvrg-topology

Presenter: Juan Brenes

Slides: https://www.ietf.org/proceedings/interim/2015/12/01/nfvrg/slides/slides-interim-2015-nfvrg-2-3.pdf

-       NFVI PoPs are the physical places where NFV is going to be deployed, especially in interconnection

-       Design considerations including which measurements are going to be used to decide which are the best configurations

-       The draft discusses the topologies that are going to be used, depending on the size of the DC and which services are going to be offered

-       Also analyze traffic types (cross-through, pop generated, pop terminated, intra-pop)

-       Distribution of the traffic among these categories, including locality, is a key factor in the design of the PoP

-       Another key factor is how the service deployment will be done, including performance and licensing

-       Other service parameters that affect the design: number of servers, number of different SFCs, how often they are changed (since it generates a lot of control traffic)

-       Next steps are to do simulations for comparisons and analytical models

-       Discussion:

o   Bhumip: A general datacenter or a PoP with some datacenter components?

§  More likely the latest

§  Bhumip: "Policy and regulation” rather than just “law” in the requirements to be considered

o   Ramki: Have you considered the difference between vSwitches and physical switches?

§  NFV allows you to use servers as switches, so we must consider this definitely

§  This discussion to be followed on the list

o   Diego: More the number of instantiations (SFPs) rather than classes of chains (SFCs)

§  Yes

o   Giacomo: All functions considered are local?

§  Yes

o   Bhumip: What simulation tool?

§  Currently using a version of NF3

 

VNF Benchmark-as-a-Service (VBaaS)

draft-rorosz-nfvrg-vbaas

Presenter: Raphael Rosa

Slides: https://www.ietf.org/proceedings/interim/2015/12/01/nfvrg/slides/slides-interim-2015-nfvrg-2-4.pdf

-       Gain information autonomously about VNF benchmarks metrics, from FP7 EU UNIFY project

-       Related to NFVRG in terms of policy-based resource management and VNF performance modelling

-       Aims at defining complementary functional components to ETSI NFV

-       Components are service function, information base for benchmark profiles, different APIs

-       Process walk through was explained

-       Usage is benchmarking, dimensioning and verification

-       And can be used to for recursive orchestration as a service

-       Discussion:

o   Ramki: Could this be part of the VIM?

§  It could

§  Robert Szabo: This follows a black box approach for the VNF

§  Diego: Do not overload the VIM

o   Ramki: VBaaS VNF profile and the interaction with the orchestrator. How do you capture the difference in performance in the model?

§  Performance models can be included in the benchmarks and then will end up in different profiles

o   Ramki: There are different kinds of VNFs. How do you deal with them

§  Robert: You have different flavors for instantiation and something similar should be used

§  VNF developer can specify metrics and interfaces

o   Diego: Sure this does not belong more to Analytics than Performance modeling or Resource management?

§  We are discussing about this and open to discuss

o  

oDiscussion on VNF benchmark profiles is deferred to the list

Recursive Monitoring Language in Network Function Virtualization (NFV) Infrastructure

draft-cai-nfvrg-recursive-monitor

Presenter: Catalin Meirosu

Slides: https://www.ietf.org/proceedings/interim/2015/12/01/nfvrg/slides/slides-interim-2015-nfvrg-2-5.pdf

-       Automatic way to decompose/aggregate monitoring data in different layers, from FP7 EU UNIFY project

-       An example is about e2e delay computation or aggregate CPU usage (taken from the draft)

-       Looked into a language called Datalog (subset of Prolog) with declarative rules and queries

-       Deed a way to represent network function - function graph (link, descendant and node)

-       Specified generic requirements for query engines: provide capabilities to parse and interpret the query, retrieve the NF-FG created by the NFV infrastructure, query the database where the monitoring results are stored, have an interface between the users of the language and the query engine

-       No discussion about interactions with the orchestration stack

-       Showed an example for the e2e delay and the CPU aggregation case, the ground rules could be provided dynamically by a NFV-O

-       Want to receive feedback and provide additional templates to align with NFVRG drafts evolution

-       Discussion:

o   Suggestion to make this one of the core components of an analytics architecture

o   Diego: Do you advocate for a general publish/query engine?

§  Yes: Ground rules provided by the MANO stack according to the lifecycle of the services, rule templates are defined by the operator to specify what can be queried

o   Bhumip: Why Datalog?

§  It allows for building a query engine in a recursive manner –

§  Ramki: Datalog seems suitable to express policy rules as well

o   Pedro: What is the relationship of Datalog with recursive orchestration?

§  Show an example of backtracking through the Datalog ground rules

§  Pedro: So the connections resides on support for recursion

 

NFV Reliability using COTS Hardware

draft-mlk-nfvrg-nfv-reliability-using-cots

Presenter: Bhumip Khasnabish

Slides: https://www.ietf.org/proceedings/interim/2015/12/01/nfvrg/slides/slides-interim-2015-nfvrg-2-6.pdf

-       Addressing resiliency part of the NFVRG charter

-       Addressed comments on section 1, 3 and 6

-       Shows various backup schemes, some of them better in terms of availability and reliability

-       Simulated different data centers models and derived availability numbers

-       4 type of data centers with different reliability scores

-       Found that 5 9s reliability can provided with COTS hardware with application level backup but can only achieved for type3 or 4 data centers (dual path IT equipment, etc.)

-       Data center maintenance impact is negligible (since it is "scheduled down time")

-       Going to release v2 resolving last comments received and hen ask for RG adoption

-       Policy used for resource management and backup has an impact on reliability, would be good to see updated in this direction

-       Discussion:

o   Ramki: The doc covers resiliency aspects, but more connected to high availability

§  It is about evaluate the options you have and how they perform, especially when dealing with backup schemas

o   David Dolson: I’ll send you some comments on the list