NOTE: NFVRG scheduled 2 sessions at IETF92
– both on Thursday, Session 1 from 1300-1500, and session 2 from 1740
– 1840. Both sets of minutes are included below, in session order.
NFVRG IETF 92
Thursday, March 26, 2015 Thursday
Afternoon Session II (Gold)
1300 – 1500
Chairs: Diego Lopez
(diego.r.lopez@telefonica.com)
Ramki Krishnan
(ramki_krishnan@dell.com)
Note takers: Sarah Banks and Anoop Ghanwani (for the first
session)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Welcome and administrative matters
-
Mailing
list: https://www.irtf.org/mailman/listinfo/nfvrg
-
Web site: http://trac.tools.ietf.org/group/irtf/trac/wiki/nfvrg
-
Slides: http://www.ietf.org/proceedings/92/slides/slides-92-nfvrg-10.pdf
-
First official meeting
Scribe and note takers
-
Sarah Banks
for notes
-
Anoop Ghanwani for notes in the first session
-
No Jabber
scribe
Agenda/Agenda bashing
-
First
session covering existing and new drafts
-
Second
slot essentially focused on recent results, especially open source efforts
-
Slides: http://www.ietf.org/proceedings/92/agenda/agenda-92-nfvrg
Update on existing drafts:
DevOps for Software-Defined Telecom Infrastructures
draft-unify-nfvrg-devops-01
Presenter: Catalin
Meirosu
Slides: http://www.ietf.org/proceedings/92/slides/slides-92-nfvrg-0.pdf
-
Introduction
-
Lots of work
happening on network virtualization
-
Purpose is
to have a discussion opener within NFVRG, describe a set of principles, and
identify challenges related to developing a variety of tools to support these
principles
-
Roles
identified (service, VNF developer)
-
DevOps principles
identified (see slides)
o
Deploy
with repeatable reliable process
o
Develop
& test against production like systems
o
Monitor
and validate operational quality
o
Amplify
feedback loops between developers and operators
-
Discussion
of challenge areas (stability, consistency, availability, partitioning,
observability, verification, troubleshooting)
-
Stability:
itÕs very challenging in a software defined infrastructure to have control
loops that would work correctly in the presence of failure
-
Consistency,
availability and partitioning: what combination is most appropriate for
software defined infrastructures? Are there scenarios when we can choose just 2
of them, and if so, which two? Software defined infrastructure changes how
these tradeoffs have been done.
-
Observability:
Trade off between network observability and scalability;
and weÕd like to have an automated method of monitoring functionality from a
logical forwarding route to virtual instances
-
Verification
– can we expect orchestration and control to log every change?
-
Troubleshooting:
The biggest problem is around automated workflows and the use of active
measurements
-
Performance
Metrics: In an operator environment, we have different organizations, some
vendors, some third parties that develop the VNF, and others that operate the
infrastructure, and itÕs not always possible to use the same techniques that
were possible in the DevOps world
-
Next Steps:
Further comments and feedback are welcome
-
Discussion
o
Ramki: You talk a
lot about general principles, but how is DevOps
impacted by keeping these principles in mind? Will you talk about that?
o
Presenter:
From the point of view of this draft, what we want to identify is a set of
challenges, not how to solve these challenges.
o
Ramki: Could we
tie these two, and add a little more detail to the DevOps
draft?
o
Steve
Wright, ATT: You defined a couple of roles on the first slide, do you see
additional roles being defined as this work continues? As you started to allude
in the comments about applying DevOps in operators,
there might be complexities you donÕt see when itÕs contained in a particular
administrator org, do you see other issues with identifying trust issues with
other roles, is this part of your frame work?
o
Presenter:
Interesting questions, regarding the roles we identified, theyÕre preliminary,
we welcome comments for additional roles; the same goes with trust boundaries.
At this time, we havenÕt really considered trust boundaries within this draft.
o
Steven
Wright: You might want to think about a system integration role
o
Presenter:
Yes thank you
NFVlaaS Architectureal
Framework for Policy Based Resource Placement and Scheduling
draft-krishnan-nfvrg-policy-based-rm-nfviaas
Presenter: Ramki
Krishnan
Slides: http://www.ietf.org/proceedings/92/slides/slides-92-nfvrg-1.pptx
-
Overview
-
Updates
since last IETF / New Additions / New Authors
o
Architecture
framework.
o
Policy
2 (HA requirement). This is being done in OpenStack
Congress and will be demo'ed at Openstack
Summit.
o
Goal:
Practical and implemented in open source.
o
Future.
¤ Separate openstack
module for handling placement and scheduling.
¤ Policy engine -- measurement collector
API / info model definition
-
Next Steps?
-
Call for RG
draft?
-
Discussion
o
Raj Jain:
question about placement – is the network a bottleneck at all in the
consideration of placement?
o
Presenter:
in this version no, but in future versions, yes – in choosing the
Congress engine, we wanted to make sure it wasnÕt just restricted to compute,
but other functions as well
o
Aaron
Jacobsen: have you taken into consideration traffic demand, as part of your
scheduling?
o
Presenter:
yes, this is like what Raj asked – weÕre planning to add this, yes.
o
Diego
– can I see a show of hands for those who think this document isnÕt ready
o
Michael Scharf: I wonder if the document is ready, there are few
examples, very specific and selected projects; wouldnÕt it make sense to make
this a bit broader, and examine a few other options, rather than such a focused
view?
o
Presenter:
Adoption shows that thereÕs interest in this work, it doesnÕt mean we canÕt
expand on the cases and grow the document. You want to adopt this because you
want to expand and grow the work.
o
Michael Scharf: I find it interesting, but too early, and IÕd like
to see other solutions rather than just the OpenStack
solution
o
(Speaker at mic, from WU) – I support the previous speaker
– it needs to be a little bit more mature before it becomes a WG
document.
Elasticity VNF
draft-zu-nfvrg-elasticity-vnf
Presenter: Robert Szabo
Slides: http://www.ietf.org/proceedings/92/slides/slides-92-nfvrg-2.pdf
-
Overview
-
Problem
statement
o
NFV
allows scaling up / down.
o
Pool
of VNFs for scale up/down.
o
VNFs
are part of a VNF forwarding graph with end-to-end guarantees.
o
Multiple
NFVI POP for HA.
o
Must
consider the service graph when creating additional VNFs for scale up.
o
Must
be considered as a multi-constraint problem
-
Discussion
o
Mehmet
(Comcast) – you are considering the network as a fixed entity – it
could be a cloud entity – how would you make this statement?
o
Presenter:
yes, thatÕs a good point, weÕll have a talk later on
about this and take this into account. In this case, we consider the network as
a standalone resource.
o
Alex (Nokia)
– what are you going to standardize here?
o
Presenter:
ThatÕs an interesting question – the VNF scaling should be handled by a
VNF agnostic manager – itÕs independent of the service function itself
o
Alex: ThatÕs
not fully correct – it depends sometimes how the vendor decides to put in
the change
o
Diego:
ThatÕs not always true, there can be some cases when the developer of the
function can/want to retain how you scale in or scale out – but OTOH, VNF
is only a piece in the machinery, if the network service provider wants to
require that they want to orchestrate how they perform scaling, itÕs OK where
they would do that
o
Alex: I
agree, there should be some freedom for the vendor also
o
Presenter:
OK, but if you have a VNF from one vendor, and a VNF from another in a chain,
you have to consider them as one when scaling, because of the dependencies
o
Ahmad Muhanna (Huawei): VNF arch is for wireless operators, not
Joe Service Provider – thereÕs a delicate process of instantiation of VNFs
– I share the comments of Alex, what do we have here to standardize.
o
Diego
– we are not standardizing anything, this is not an IETF group
o
Presenter:
this has architecture implications the resource part is not so easy if it goes
beyond a single PoP. For these kinds of use cases, we
have to consider how to possibly solve this
o
Ahmad: I
want to highlight the problem of a VNF that spans over different VMs or
different virtual components, and simply replacing a single box with several
virtual VNF components is probably a performance challenge.
o
Ramki: Take a
look at the analytics draft, and see how to take this forward
o
Diego: We
hope you take this draft beyond the problem statement phase
o
Presenter:
We hope to.
Verification of NFV services: Problem Statement and Challenges
draft-shin-nfvrg-service-verification
Presenter: M-K Shin
Slides: http://www.ietf.org/proceedings/92/slides/slides-92-nfvrg-3.pptx
-
Update since
IETF91
o
Changes
- New title (focus on research problem rather than architecture), coauthor
added, verification framework is revised based on NFV Phase 2
o
Motivation
- Incomplete or inconsistent configuration of VNF and forwarding graph
o
Lists 6
properties that need to be checked.
-
Review of 3
options for the verification framework
o
Verification
manager in MANO
o
OSS
service
o
VNF
instance
-
Discussion
o
Steve Wright
ATT – Targeted at the topology of the service draft, but there might be
other things to consider, like the pinning of a
particular VNF.
o
Presenter:
We agree, we will do that
o
Steve
Wright: YouÕre trying to verify something thatÕs already been deployed, but
verification can apply at different times in the life cycle, do you discuss the
consequences of doing this at different points of the life cycle?
o
Presenter:
Not yet, but we could look at this and discuss what you mentioned
o
Catalin, Ericsson:
An observation about your options – there are variations; you wonÕt be
able to measure the variations if you place this at the orchestration layer
o
Presenter:
at this point we arenÕt discussing architectural issues, we will consider your
point
o
Catalin: that
depends very much on the requirements you want to verify
o
Mehmut, Comcast:
Start with verifying those first 5 interfaces, and then see how far we can go
o
Ahmad Muhanna (Huawei): you have a verification server emulate
the function itself – the architecture you are proposing might not be the
best architecture we should consider; if you want to verify one of the VM or
isolation in the network, you want to make sure the virtualization server can
be a VM – by detaching it from the MANO or OSS, youÕve isolated it form
the function itÕs supposed to do.
o
Presenter:
If we have a standardized item like that, we have to go to the NFV group
o
Ahmad
(Huawei): we are a research group, and we need to look at an architecture that
makes sense.
o
Raj Jain: if
you put in a new function, you want to test it out – think about fcaps – will it meet the performance I want, no
loops, etc, and security
o
Steven
Wright – this seems to be targeted at one time, first deployment –
is that the problem youÕre trying to solve, or are you trying to deal with the
ongoing validation of the lifecycle? Are you assuming the environment is
static, or are you assuming change?
o
Presenter: I
think there are too many aspects – the authors wanted to provide what is
the problem when the operators configure the vnf
– if they develop the verification service, there are too many options;
we didnÕt check into all the options
o
Diego:
Instead of talking about service verification, reshape the draft to talk about
forwarding graph verification, something unique to NFV
o
Presenter:
OK
o
Ramki: If you
could think about working proactively instead of reactively, it would add
further value
Resource Management for Dynamic Service Chain Adaptation
draft-lee-nfvrg-resource-management-service-chain
Presenter: S Lee
Slides: http://www.ietf.org/proceedings/92/slides/slides-92-nfvrg-4.pptx
-
Changes from
IETF91
o
Problem
definition refined: Resource
scheduling needed; NFP update vs VM scaling.
o
Added 2 use
cases: path optimization and end
point mobility
-
Applied to a
SFC use case
o
First result
out of the RG
-
Discussion
o
Diego: This
seems very relevant with the previous draft about elasticity. I encourage you
to work together to see if you can collaborate.
Unifying Carrier
and Cloud networks: Problem Statements and Challenges
draft-unify-nfvrg-challenges
Presenter: Robert Szabo
Slides: http://www.ietf.org/proceedings/92/slides/slides-92-nfvrg-5.pdf
-
Update: Split problem statement and challenges
o
Multi-level
- Compute, storage, networking
o
Joint
abstraction layer for software and network resources
o
Orchestration
problem for compute and network.
¤ Can't communicate networking
requirements to OpenStack.
¤ Dependencies - TOSCA, chef recipes
o
Motivation
discussion
o
Measurements
and analytics
-
Looking for
feedback, want to move towards RG draft
-
Discussion
o
Mehmet Toy,
Comcast: Some of the terms are confusing, can you clarify
o
Presenter:
Today the cloud is assumed to be a software resource, and has a network path.
But when you request VMs but not really the networking path, what we try to
show here is that itÕs not enough if you consider compute resource, that you
have to add the network part, because you want to define how the networking
behavior within that cloud domain should look like. ThatÕs why we want to
exercise joint control over this.
o
Al Morton,
ATT: I see on your slides benchmarking twice. Please, come join us in BMWG
New proposed drafts:
Towards recursive virtualization and programming for network and
cloud resources
draft-unify-nfvrg-recursive-programming
Presenter: Robert Szabo
Slides: http://www.ietf.org/proceedings/92/slides/slides-92-nfvrg-6.pdf
-
Overview
-
Motivations
-
Summary
o
Recursive
approach with joint network and compute
o
Go
through a service chaining use case
o
Lots
of back and forth if network is not considered
-
Discussion:
o
Diego: A
colleague of yours was complaining that NFV was not supporting recursion, and I
find it interesting that youÕre talking a lot about recursion
o
Presenter:
Are we supporting recursion?
o
Diego: We
need to, yes
o
Ramki: With
recursion, the value isnÕt very obvious; we need to be hierarchical, yes, but
perhaps we can demonstrate the value with some examples, itÕll make the draft
more meaningful and powerful.
o
Anoop, Dell: This
seems to be a multi constraint optimization problem – fix one, optimizer
the other – but ultimately if you try to optimize both, you run into
problems, and maybe youÕre suggesting by using recursion you are suggesting you
an solve this problem
o
Presenter:
Yes; we are arguing that you do not need to separate the resources. People
assume that if go with cloud, you request VMÕs, and thatÕs all. If you want NFV
to put into a service, we always have a networking issue. We can separate this,
but then we should have these networking considerations attached to the VM
request, because they should be considered jointly. You can go first for
network optimization, and then check your compute resources, or you can go for
compute selection, but then consider the bandwidth. However you solve this
algorithmically, might be hard. We want to keep the constraints and
requirements together.
Policy Architecture and Framework for NFV Infrastructures
draft-norival-nfvrg-nfv-policy-arch
Presenter: Ramki
Krishnan
Slides: http://www.ietf.org/proceedings/92/slides/slides-92-nfvrg-8.pdf
-
Scope
o
Looking
at business rules and also at network, compute, storage and energy constraints.
-
Policy
intent vs what happens in each element.
-
Local vs global policies.
-
Conflicts
in policy and resolution.
-
Hierarchical
policy framework.
-
Conflict
resolution has to be handled at scale.
o
Implementation
complexities when you apply policies one at a time or in one shot at a box
level.
-
Proactive
vs reactive conflict resolution.
-
How do
policy engines communicate?
-
Discussion
o
(Ramki) I need my glasses
o
(Diego)
YouÕre getting old, Ramki
o
Raj Jain, Washington
U: One more dimension – cloud provider has a policy, cloud tenant has a
policy – there might be some conflicts - I donÕt know if the pub/sub model will
solve this – multiple cloud providers might have policies that differ
amongst themselves, and then those in turn can differ from the tenants policy
o
Presenter:
By global/local, we are not restricting this to 2 levels – there can be
more
o
Steven
Wright: I suspect we need to be a bit more concrete about what types of
policies we are taking into account, prior to bringing into
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
NFVRG IETF 92
Thursday, March 26, 2015 Thursday
Afternoon Session III (Gold)
1740 – 1840
Other activities and recent results:
These are
documents intended to be a view of different activities and recent results
within the RG.
Introducing Open
Platform for NFV (OPNFV)
Presenter: Dirk Kutscher
Slides: http://www.ietf.org/proceedings/92/slides/slides-92-nfvrg-11.ppt
-
OPNFV is a carrier-grade, integrated, open source
reference platform for NFV
-
Project Goals – working with relevant
different open source projects, taking them, integrating them, improving them,
and promoting OPNFV as the preferred open reference platform
-
NFV Initial Scope: NFV Infrastructure (NFVI), VIM
(Virtual Infrastructure Management)
-
Upstream OSS Projects Integration – works
directly with upstream standards bdies (ETSI, etc)
-
NFV Projects and lifecycle (see slides)
-
Project Overview (Automation, Fault, Carrier
Grade, Tools)
-
First release – Arno – end of April
2015 (OS Juno, ODL Helium, Cceph, OVS, CentOS)
-
Discussion
o
Robert: Any integration between these projects?
o
Presenter: Yes
o
Robert: Integration of the different OPNFV
projects?
o
Presenter: Yeah, sometimes theyÕre complimentary,
for sure
o
Carlos: Is the idea to focus on integration, or
new code?
o
Presenter: Both
Virtual Home
Networking (vHN)
Presenter: Don Clarke, CableLabs
Slides: http://www.ietf.org/proceedings/92/slides/slides-92-nfvrg-12.pptx
-
CableLabs
– fully funded by cable operators, 56 cable operators, worldwide
participation
-
Background
o
Home Networks are evolving / challenges –
they donÕt have complete visibility to the end usersÕ devices – but when
the services to those devices go wrong, the SP has limited tools to
troubleshoot
o
Can we use virtualization to help?
-
R&D Approach – Ōlean startupĶ approach
-
Interested in open source solutions and standards
to do interoperability and grow an open ecosystem
-
Lunch time presentation on open source focused a
lot on licensing, but for Don, itÕs about innovation
-
Architecture vision and challenges
-
Discussion
o
Cisco: How is the virtual CPE initiative
different than what youÕve positioned here?
o
Presenter: ItÕs not about differentiating –
itÕs about virtualizing the functions, and virtualizing the CPE is not the goal
o
Bob Briscoe:
Are there any benefits for the end customer, or is it all about you?
o
Presenter: ItÕs about choices for customers, and
improving the service for them.
OpenMANO
Presenter: Diego
Slides: http://www.ietf.org/proceedings/92/slides/slides-92-nfvrg-7.pdf
-
NFV aint cloud applied
to carriers – the network differs from the computing env
in 2 key factors: data plane workloads are huge, and network requires shape, +
E2E interconnections
-
Applying enhanced platform awareness (EPA)
– apply techniques that have been applied before in high performance
computing, like the possibility of using the memory in unconventional ways, you
can use the pages in the memory in different ways, you can locate a set of data
closer in the cache, to improve performance
-
Avoiding bottlenecks in the hypervisor and the OS
¤ You
rely on SW libraries to directly access the hardware – working with
Intel, with RedHat (essentially based on DPDK)
¤ Recently
demoÕed at MWC 2015 (see slides)
¤ OpenMANO – the current orchestration systems
werenÕt supporting what they needed
¤ github.com/nfvlabs/openmano
-
Enhanced performance aware VIM, directly connects
VNFs to the OF switches, currently running without VNFM
-
VIM is not based on OpenStack
– OpenStack doesnÕt support the EPA; you take
OS, you make some models, youÕre locked into a version for OS, but openMANO extensions have been submitted to OpenStack
-
Discussion
o
Question from Mic: what
do you mean by carrier class behavior?
o
Presenter: Performance that is acceptable for our
operational guys to substitute the physical for the virtual; something that
provides a consistent performance; when you make the deployment, youÕre gonna get 10 gigs, 10 megs, 1 meg – the same
predictable performance
o
Aaron (University of Wisconsin): Excited by this
– how does the number of different ways youÕre splitting the traffic
affect your switching?
o
Presenter: We are focused on a few projects,
assigned a tight schedule, the service chaining is very limited, not more than
3-4 functions. The stitching of the functions is done by the OF controller; we
have plans to explore general function chaining later on.
o
Roland Bless: YouÕre using DPDK, are there issues
with isolation?
o
Presenter: Yes, on the tricks here, for each
process, we have a set of resources assigned
o
Roland: So youÕre limited by
the number of cores, etc?
o
Presenter: When deploying functions in the data
plane, yes
Reliability of
COTS Hardware
Presenter: Bhumip Khasnabish,
ZTE
Slides: http://www.ietf.org/proceedings/92/slides/slides-92-nfvrg-9.pptx
-
Can we expect the same behavior from COTS that we
get from traditional vendor hardware?
-
See slides – original paper is mentioned as
link
-
For this session, the slides should be reviewed
–theyÕre heavy on the math, and need review by readers to understand the
ask
<< EOM
>>