NFVRG IETF 96 Berlin

Monday, 18 July 2016 - Morning Session (Room Bellevue)

10:00 – 12:30

Chairs: Diego Lopez (diego.r.lopez@telefonica.com)

Ramki Krishnan (ramki_krishnan@dell.com)

Note takers: Sarah Banks, Linda Dunbar, Dirk Kutscher

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

Welcome, administrative and general matters

Presenter: Diego Lopez

Slides: https://www.ietf.org/proceedings/96/slides/slides-96-nfvrg-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/96/nfvrg.html

- Sarah Banks, Linda Dunbar, Dirk Kutscher for notes. Dave Dolson acted as jabber scribe

- Document review request

- Update of the near-term work items

- Seungik Lee as new editor of the resource management draft, together with Robert Szabo

Update on Adopted Drafts

draft-irtf-nfvrg-policy-based-resource-management

Presenter: Robert Szabo

Slides: https://www.ietf.org/proceedings/96/slides/slides-96-nfvrg-1.pdf

- Change in editors

- Changes in v01

- Review of next steps

- Proposals for next step

- Acknowledgements

- Discussion

o Ramki: how do you facilitate people who want to contribute images but want to wait for discussion?

§ Robert: Discussion should happen on the mailing list, content merging on the github

draft-irtf-nfvrg-gaps-network-virtualization

Presenter: Carlos Bernardos

Slides: https://www.ietf.org/proceedings/96/slides/slides-96-nfvrg-2.pdf

- History of draft

- Objectives (identify and describe open research challenges for network virtualization)

- New Structure of the document as it is right now

- IRTF/IEFT initiatives considered

- Next Steps

- Discussion

o Diego: Value in attempting publication; can you structure it a little more around the areas

§ Carlos: Yes, it’s worth doing; now that we have the topics, it’s easier to match the topics with the areas, as well as identifying topics/areas that are not yet covered

o Pierre Lynch: Testing as a missing challenge – have you considered that?

§ Carlos: A good suggestion, we will consider that for the next revision

o ?/China Telecom: configuration of the VNF functions

§ Carlos: If you can send an email to the mailing list so we can have a discussion on this, that would be good

§ Yes

Update on Existing Drafts

draft-natarajan-nfvrg-containers-for-nfv

Presenter: Ramki Krishnan

Slides: https://www.ietf.org/proceedings/96/slides/slides-96-nfvrg-3.pdf

- Recap of first version

- Benchmark Setup

o Iperf for VNF workloads

- Benchmark – instantiation items (Service agility/elasticity)

o Syn flood and measure the time for the VNF container to respond

o Unikernel fastest to come up – standard kernel is the slowest

- Benchmark – throughput

o No NICs involved

o Containers/unikernels are similar and best throughput – VMs are way off

- Benchmark – RTT

o Containers are the best

o Variation of the ping flood – positive test

- Benchmark – Image size

- Benchmark – Memory Usage

o Container is the smallest (process approach running on Linux)

o VMs largest

o Top to measure usage

- Comparison Discussion

o (See document)

o Overall choice is not black or white – use case and vendor solution availability dependent

- Next Steps

o Requesting for RG adoption on the mailing list

- Discussion

o Kostas Pentikousis: what’s the purpose of the draft, and why doesn’t that go into an academic kind of paper instead. Are you expecting others to contribute tests here too?

§ Ramki: If you have good suggestions, please send them on the list.

§ Kostas: would it be interesting for more people to add more tests or confirm the tests?

§ Ramki: regarding adoption, if there’s interest, we’d like to adopt

o Dave Dolson: you made a statement in the test about testing without using NICs – from hosts only? For a VM there’d be a vNIC

§ Ramki: we avoided the pNICs

§ Dave: Is this a fair comparison then, if there’s a vNIC that needs to be emulated?

§ Ramki: it’s a good question – we tried to minimize anything with physical – but Felipe should be the best one to answer. Send the question to the list.

o Georgios Karagiannis: currently you have used Intel – are you planning to use ARM64?

§ Ramki: Sure, completely open of course

§ Diego: It’s not about whether or not they are going to, but YOU can contribute form other platforms

o Uri Elzur: do you have a detailed setup to share? Without this it’s not reproducible, you lose the meaning

§ Ramki: Regarding the setup we can get more details, and the draft describes a reasonable amount of detail. We can make sure more detail is added

o Robert Szabo: How much of the results are independent? What’s your view on this? How much is the VNF vs the VNF environment?

§ Ramki: We have a reference in the draft around a real VNF, we also found that we are not able to define real VNFs. By choosing iperf, we came as close as possible; otherwise it’s a chicken and egg problem.

§ Robert: In the title you say lightweight – do you really want to limit the scope to lightweight?

§ Ramki: even if there’s a HV involved, there’s also the actual VNF that’s a contributor. By lightweight we are taking end to end, including the VNF, into consideration.

o David ?: Do you also plan to use DPDK for the throughput measurement?

§ Ramki: something like DPDK would be an additional test. If you have some thoughts, please contribute them.

o Phil Eardly: Should some of this content be in the content be in the previous document contributed?

§ Diego: What Phil is saying is that some of the discussions here should feed into the gaps doc?

§ Ramki: That’s a good idea

draft-unify-nfvrg-devops

Presenter: Catalin Meirosu

Slides: https://www.ietf.org/proceedings/96/slides/slides-96-nfvrg-4.pdf

- Motivation and outline

- Updates in -05 and -06 versions

- Research challenges for testing

- Next Steps

o Align with charter of the RG by discussing real-time properties with stability, and take suggestions from meeting participants in person or on the mailing list

- Discussion

o Ramki Krishnan: Are you also considering onboarding third party VNFs (you go through an online certification process)

§ Catalin: We try to consider all types of VNFs

§ Ramki: Onboarding such VNFs introduce security challenges, is your testing considering this?

§ Catalin: Security testing isn’t something we’ve considered in the text, maybe we should add some text around this

§ Diego: If we can gather all of the challenges and put them in a single place, that’d be great. Could

- Diego (general comment): Please sign the blue sheets. It helps us get a bigger room. We need one – we have many people standing and even others are at the door

draft-cai-nfvrg-recursive-monitor

Presenter: Catalin Meirosu

Slides: https://www.ietf.org/proceedings/96/slides/slides-96-nfvrg-5.pdf

- Overview – to provide an automatic way to decompose/aggregate monitoring data in different infrastructure layers

o Solution proposal is to define a query language based on an extended datalog syntax, and include pre-defined templates for initial metric examples

- Updates in -02

- Discussion

o ?/Kings College London: In any of the real time considerations, did you consider the light (weight)container as part of this as well?

§ Catalin: In both of these drafts we are a little bit independent of the execution environment – whether it’s in a container, or a set of VNF, it doesn’t matter, so long as we have the resources. Whether the resources represent small or larger containers, it doesn’t matter.

§ ?: where the RTT was considerably lower for containers, does this make sense?

§ Catalin: the deployment would be on a case by case, depending on the scenario, or the vendor, one of them would be adapted.

o Diego: For specifying the collection of data for monitoring, would you consider YANG, or by someone making the request, and translating it into the language?

§ Catalin: currently, YANG doesn’t support recursion, so the language we have here, it takes full advantage of recursion in order to traverse the infrastructure.

o Ramki: Perhaps writing down the information model you’re looking at, you’d get a better look/understanding of what’s recursive (or not)

§ Catalin: I think we should add an example that handles vertical recursion. The examples we have currently are about the aggregation of information

draft-bernardos-nfvrg-multidomain

Presenter: Luis Contreras

Slides: https://www.ietf.org/proceedings/96/slides/slides-96-nfvrg-6.pdf

- Rationale

o Goal is to permit programmability, flexibility, and automation, but also agile contracting of services, including VNFs

- NFV reference framework

- Multi-domain problem statement

o There are no established mechanisms for providing access to multi-domain environments in a standardized way (e.g.. to facilitate portability of VNCs among NFVI PoPs independently of the owner of such infrastructure)

- Architecture proposition (work in progress)

- Next Steps

- Discussion

o Selgen/University ?: when it comes to multi domain, can be interpreted as different concept domains

§ Luis: Are they different administrative domains? Is that your question?

§ Selgen: what’s the purpose of this draft? To bring the requirement and problem statement, or providing a technical approach to solving this problem?

§ Luis: How feasible are the different interactions, what would be the info that these interfaces could support/handle, to make this ecosystem work/operational

o Ramki: the 5GEx project, where is that in the evolutionary phase?

§ Luis: it defines an ecosystem, and the goal is to define these interfaces, to identify mechanism for multi-domain scenarios

o Andy Veitch: your NFVO is that an extension to NFVO to support NFVO-to-NFVO communication?

§ Luis: yes, to enable service provision across these different domains

o Kostas Pentikousis: Editorial suggestion for slide 5: I counted at least 5 acronyms that I have no idea what they mean

§ Diego: that’s because you haven’t read the draft

§ Kostas: who’s read the draft that isn’t an author or works for the company?

§ (1 hand, Steven Wright)

o Kostas Pentikousis: I wonder if the notion of domain might mean different things to different people

§ Luis: This is just the starting point; (see the recording because I can’t make heads or tails of what he’s saying). This is not radio specific, but it has to do with all the dynamicity that’s expected in 5G.

§ Luis: RFC1116 presents the same administrative domain concept as here.

o Diego: There is an event coming up to analyze the 5G concepts and NFV, how one influences the other, at the coming NFV plenary meeting in Sophia-Antipolis.

o Diego: Anyway, what we are doing here goes beyond 5G

New Proposed Drafts

draft-aranda-nfvrg-recursive-vnf

Presenter: Pedro Aranda

Slides: https://www.ietf.org/proceedings/96/slides/slides-96-nfvrg-7.pdf

- Rationale

o VNFDs are impossible to read – which makes reusability difficult – how can you reuse what you don’t understand

- Easy vs difficult

o Diagram, vs a YAML template

- Alternative we propose

o Why not use NEMO

§ It’s human readable

§ It’s human understandable – you can read it and understand what’s below that

§ Structured like high-level programming languages

- How would this work?

o VNFDs like those in OpenMANO are used as low level blocks

o NEMO allows us to describe VNFs

- This is what we want

o Want to find an easy way to describe VNFs

- So let’s go step by step

o Import VNCD into NEMO

o Provides an example (see contribution)

- Acknowledgement

o Superfluidity project

- No questions

draft-sonata-nfvrg-devops-gatekeeper

Presenter: Diego Lopez

Slides: https://www.ietf.org/proceedings/96/slides/slides-96-nfvrg-8.pdf

- Comes from a project called sonata

o Build dynamic and flexible orchestration framework

o Use mediation systems as the gatekeeper for doing everything

- The components for NFV DevOps

o Catalogs

o Service Development Kit

o Service Platform

o Underlying Infrastructure

- Mediation DevOps

- Mediated Pluggable MANO

- Discussion

o Robert Szabo: Many of the works here are replicated; there are other drafts that seem to adopt this here – could we consolidate the contributions?

§ Diego: That’s why we talk about “find a common path”

o Kostas Pentikousis: DevOps draft would benefit from input from this draft

§ Diego: Indeed (see above)

o Steven Wright: Similar comment – align with the DevOps draft – I’d like to see more definition around the functions of the gatekeeper, rather than proposing another architecture. This draft is very focused on the network service, rather than the VNF

§ Diego: Makes sense

o ?: I propose we go with the architecture

§ Diego: which functions?

§ ?: in the YANG modeling – some of the drafts are not ready, and we’re stuck for months until they’re ready, so for that reason I’d prefer to stick with the architecture

§ Diego: If we go for a merge, I’m sure we can find something in there that’s the right mid term

§ Ramki: Perhaps this is a list discussion

§ Diego: Bring it to the list

Open Source and Project Updates

Practical Implementation Results: Attestation, Remote Attestation, Confinement Technologies

Presenter: Michael Lazar

Slides: https://www.ietf.org/proceedings/96/slides/slides-96-nfvrg-9.pdf

- Disclaimer

o This is an informational submission

- About this presentation

o Takes commercial equipment and puts it together

§ OpenDL, OpenStack, OPNFV, Intel

- ETSI NFV Reference Architecture

- Chain of trust – attestation is designed to produce a secure root of trust

o A launches B, B launches C, but who says that A is actually valid?

- Remote attestation architecture – overview

o When one system can now say I’m trusted, and here is information that I trust and communication has been verified”

- Virtualization – the “root” of the issue

o Virtualization introduces new security implementation challenges

o The concept of “trust”

- Some attach vectors – potential remediation

o There’s the potential for bad BIOS, modified hardware

o Suggested mitigations

- So we have “trusted hosts” everything is good – right?

o We have verified hardware, verified software

o Things start to get interesting

o How the OpenStack architecture (OPNFV) implements the trusted architecture – it’s just a flag, over the whole system.

o If you change the flag, it doesn’t necessarily have an impact, since it’s not built into the scheduler, it’s subject to manipulation

o The attestation server itself is an attack point

o OpenStack supports a binary trust model – hosts are either attested and verified that they’re good, or they are not – no hierarchy, or multiple trust models, as required for telcos, for example.

o You can designate a VM for a trusted host, but by design, in OpenStack currently, untrusted VMs can also launch on trusted hosts by default

o Only compute nodes can be attested/remotely attested. When you think about your SDN services running on Neutron, or any other services that are going, you have critical features and functions that you cannot verify that the OS they’re running on hasn’t been tampered with.

o The person running the virtualized system has pretty much unlimited power. A lot of components running in a single entity and your admin has access to a lot of systems and capabilities that they shouldn’t necessarily be trusted with or have access to.

o If you revoke the hosts trust, anything running on that host will continue to run

o Shared memory

§ In telcos, one of the practical suggestions is to turn it off

o Hypervisor choice matters quite a bit

§ QEMU is great for high performance, but it has known security issues

§ Containers are great, but if the underlying kernel has issues, security related, that impacts access back into the container, since access is shared

o Some thoughts

§ Hardware root of trust isn’t being implemented enough out in the real world

§ Random sampling shows that TXT not enabled and in several cases VT-d was disabled – turn on the basic stuff, that’s important

§ The OAT was released with a BSD licensing model – it hasn’t been widely adopted

§ The binary trust issue should be addressed – in a telco environment, having a single hardware zone is an issue

- Discussion

o Ramki: we talked about the security issues, do they come from more insider threats, or more outside threats – what is the source of the threats?

§ Michael: It’s about when they’re layered together – any one by itself isn’t particularly bad, but it’s when you start stacking them up. People want performance, so they’ll turn off features

§ Ramki: Where does the security problem start?

§ Michael: Both (inside and outsider) It’s not about the individual, it’s the nation states

o Dejan Bogdanovic: Did you think about LI?

§ Michael: LI is a hot topic on the ETSI security group – we’re working on it, we’re hoping to have the normative doc (SEC-13) draft published before September

o Dave: Dolson Trusted guests – I thought you weren’t supposed to assume anything about the guests, the HH thinks about this –

§ Michael: More specifically, you can say this host has been physically verified – that means that it’s gone through a process where the host hasn’t been tampered with. With certain technologies you can take the next step – that the first HV hasn’t been modified. About guests, the catalog, some authorized admin will say this is a sensitive workload that needs to run on a trusted host – if you have 100 HV’s and 20 are trusted, you want trusted workloads to work only on the 20 HV’s that are trusted. The challenge is that by design, it’ll also allow something that isn’t trusted to run on a trusted HV – that breaks the concept of trust.

§ Dave: A guest should be able to determine whether or not it’s running on a trusted system?

§ Michael: when a guest is added to a catalog, someone else is saying that it needs to run on a trusted system or not

o Steven Wright: Are any of your recommendations captured in a best practices doc somewhere, or test scenarios at OPNFV?

§ Michael: This presentation is a subset of an ETSI doc, we’ve had discussions with OPNFV and OpenStack community

o Ramki: It’d be worthwhile to get this into our challenges doc

Network Coding Function Virtualization

Presenter: Angeles Vazquez-Castro

Slides: https://www.ietf.org/proceedings/96/slides/slides-96-nfvrg-10.pdf

- Objectives

- Concepts (main theorem)

- Network coding means you shouldn’t consider a flow as a physical thing

- General benefits and cost

- Examples

- From coding to networking

- Proposal: network coding functional architecture

- NC functional architecture

- To Take home

- Get feedback from NFVRG

- Discussion

o Steven Wright: You’re mixing multiple streams of traffic together

§ Angeles: You may or may not

§ Steven: It would be interesting to see this from the network service perspective, rather than the VNF wrapping.

§ Angeles: I agree, I would love to do this

o Dejan Bogdanovic: Did you compare it to a P4?

§ Angeles: I have not compared it, I agree this should be done

o Diego: Could you write a short draft, could you put your ideas in a document, so we could iterate and provide feedback?

§ Presenter: Yes

Evolution of the PPA Project

Presenter: Ramki Krishnan

Slides: https://www.ietf.org/proceedings/96/slides/slides-96-nfvrg-11.pdf

- PPA Recap

o Flexible infrastructure policy in the open source

o Focus on OpenStack Nova scheduler

- PPA Progress

- No questions

Security Considerations on the Co-Existence of Different Functional Planes Implemented as Virtualized Functions on a Single Compute Node

Presenter: Ramki Krishnan

Slides: https://www.ietf.org/proceedings/96/slides/slides-96-nfvrg-12.pdf

- Network functions – functional class partitioning

- Technology evolution impact

- More on Isolation Breaches

- Next Steps

- Discussion

o Diego: Is there a 3GPP interest?

§ Ramki: Yes

o Steven Wright: By classes you’re talking about a classification scheme, rather than inheritance – a particular VNF could belong to multiple classes. What’s the purpose or the uses of the classification scheme, and how do you know that you have enough classes?

§ Ramki: A good example could be the CPE use case

o Steven Wright: it may be better to take a different approach to the classes – take the problem of migrating existing network functions and cloudifying them, depending on the model, there are 3-4-5 stages you go through. Having classes around that is probably a helpful classification scheme. You might be more interested whether something is more cloud mature or not

§ Ramki: that’s a good suggestion

Update and demo on draft-irtf-nfvrg-unify-recursive-programming and draft-unify-sfc-control-plane-exp

Presenter: Robert Szabo

Slides: https://www.ietf.org/proceedings/96/slides/slides-96-nfvrg-13.pdf

- Reminder on the recursive programming draft

- Topology of BiS-BiS

- Resources & Capabilities

- SFC Control Plane experiment draft

- Use Case

- SW to SFC: Joint Network & Cloud Programming

- Network Scenario (describing what’s on the table in the room)

- Step 1

o (Shows a tool from a web browser projected on screen in the room)

o Demo underway

- On the fly, seamlessly extending this setup to Step 2

o Up till now, the color sensor info wasn’t sent – the robot wants to drive itself off the table

o Now they send the color sensor info – and the robot will stay (and does) on the white piece of paper on the desk

o Putting your hand in front of the robot makes the robot move away from your hand

- Will run a large scale session on Thursday at Bits and Bites

o Will also show the elastic API

- Bits n Bites Scenario

- Summary

- Acknowledgement: EU FP7 UNIFY

- Discussion

o Diego: Take questions to Bits n Bites. Thanks Robert, it’s a proof that it works.