[Sdn] Draft minutes for IETF96/Berlin SDNRG/NFVRG/NMRG joint meeting on Managing Virtualized and Programmable Networks

[Kohei Shiomoto <[e-mail]>]

Dear SDN-RG

Attached below please find the draft minutes of the IETF96/Berlin 
meeting, the SDNRG/NFVRG/NMRG joint meeting on Managing Virtualized and 
Programmable Networks. We appreciate Haomian and Catalin for 
volunteering to take the minutes and Will for jabber scribe during the 
meeting. Please let us know if you have any comments and corrections.

Best regards,
Dan and Kohei

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
IETF 96 - Joint meeting SDNRG/NFVRG/NMRG on Managing Virtualized and 
Programmable Networks
Friday, July 22, 2016
10:00-12:00 Friday Morning session I
Session Chairs: Laurent Ciavaglia(NM RG), Diego Lopez(NFV RG), and Kohei 
Shiomoto(SDN RG)
==========================================

-----------------
0. Introduction
Laurent Ciavaglia, Diego Lopez, and Kohei Shiomoto
5 Minutes

(Presentation Summary)
Goal of the meeting: investigate problems, challenges and gaps for NFV / 
SDN. Speakers asked to outline research directions and applicability to 
IRTF/IETF discussions, working groups and work.

(Q&A)
No Questions discussed.


-----------------
1. Network operator Challenges for Commercial SDN Environments
Ariel Gu (China Mobile)
10 Minutes

(Presentation Summary)
DCs with SDN/NFV deployed at large scale, public cloud with 2000 servers 
and private cloud with 3000 compute nodes. Challenges brought by SND/NFV:
-    Large amounts of information, fault localization and topology 
visualization
-    OAM for new encapsulation like VXLAN
Challenges in the management architecture: telemetry is not widely 
supported by vendors, so not mature to use right now.
Information collection: need to be extensible (e.g. large scale) and 
high-performance
Topology of each levels should be displayed dynamically on both tenant 
and administrator sides.
Network monitoring challenges: need to monitor both at tenant and admin 
levels.
E2E fault detection made more complex by the virtualized environment.

(Q&A)
No Questions discussed.

-----------------
2. Techniques and tools for the management and operation of NFV and SDN 
networks
Evangelos Haleplidis
10 Minutes

(Presentation Summary)
SDN/NFV changes the network from box-oriented management to 
resource-oriented management. RFC7426 shows a model of architecture for 
this network. An attempt was made to map RFC7426 onto the ETSI MANO 
architecture. University of Patras built a DSL using the FORCES spec 
that allowed defining a network of resources and managing it.
Future directions:
-    Common set of abstractions needed, both for hypervisors and network 
functions

(Q&A)
Haomian: Clarification; the abstraction model discussed here is 
function, not network;
Evangelos: Yes, we don’t want to repeat the IETF WG works. There are 
enough abstraction models, we need a common set of functions.

-----------------
3. SDN Architecture and Use Cases for PCE-based Central Control
Adrian Farrel (Olddog)
10 Minutes

(Presentation Summary)
Talking about the evolution of PCE, in relation to two drafts in the PCE 
WG and the TEAS WG. PCE isolates computation from the actual 
establishing of a path. The larger use case right now is in transport 
networks. PCE evolution went through one function to a hierarchical 
architecture to current work on including it in SDN controllers. Working 
out where the PCE fits in SDN is debatable, although the function 
clearly exists. PCE-based Central Controller ? using the word 
“controller” instead of “orchestrator”. This enables an opportunity to 
have a hybrid, node-by-node and controller-to-node control in the 
network that functions both horizontally and vertically.

(Q&A)
Kostas: A minor consideration from me: for PCE is it the first solution 
in SDN southbound? That’s from historical perspective. The other thing 
is now there are hierarchical PCEs and a lot of drafts. It seems the 
content here is to fitting PCEP into a combination of 
hierarchical/recursive and multi-domain scenario, which has been 
published a few years ago. Have you looked at the previous work 
published in this RG? Have you seen some other research work doing this 
problem instead of PCE?
Adrian: Yes, I think you raise a good point from a different angle, on 
why PCE/PCEP instead of other protocol in the SDN scope. The answer is 
typically from deployment and from implementation. It would be nice to 
implement or deploy 10 protocols (if you have PCE)to the same or 
crossing-spaces. IETF have 3 protocols (PCEP/BGP-LS/RESTYANG or JSON) on 
the same interface; I am not going to judge the pros and cons for the 
operators. The slides here is just to show what people already have with 
PCE. Hopefully research can help announcing that the 3 approach are 
becoming overlap with each other, and it will be functionally okay or 
functionally broken, performance okay or performance broken, complexity 
okay or complexity broken. The industry society, I don’t think they will 
do that because everybody cares about money.
Kostas: I am getting off the tunnel, I didn’t follow much about the 
progress, is it open source for research community?
Adrian: it’s going on.
Dan King: yes, in ONOS.
Pedro: what is the network/controller model? You talked about PCE as a 
central controller, is it the same with PCE running as an APP on the 
controller?
Adrian: Well, there are many Hierarchical controller and may be 
confusing, as people may not have same definition with what controller 
is. Anyway, controller controls a device. PCE-based box talks via PCEP.

-----------------
4. Network Scheduling in Software-defined Environments
Tal Mizrahi (Marvell and Technion)
10 Minutes

(Presentation Summary)
What would happen if all the nodes would have synchronized clocks and 
NMS/controller could tell the nodes to perform operations in a 
timely-synchronized manner. Using timed network updates could be done in 
OpenFlow, I2RS, FORCES, etc. Scheduling the updates guarantees no 
blackholes during updating multiple nodes. Using timestamps instead of 
time (as they showed at SWFAN’16) could create a number of opportunities.
Synchronization is rather expensive. China Mobile have about 1M base 
stations synchronized at 1 us (reported in the TIC TOC group).
The authors proposed TimefFlip, timestamping based TCAM Lookups meaning 
we could define time applicability for TCAM loops. This is not expensive 
in term of TCAM resources. Benchmarked on a Marvell switch.
New feature in OpenFlow 1.5 for timed updates, and also an experimental 
RFC for Netconf.
Future work: Netconf, I2RS, PCE, FORCES.
Dataplane timestamping already considered in SFC, but also of interest 
for NVO3.

(Q&A)
Stewart Bryant: Excellent work, however, go back to the idea of flipping 
and forwarding on the scheduling. We had worked on the similar topic 
before. The problem we (and everybody) have is we double size the flip, 
you need one entry for the old stuff and one entry for new. And that 
will particularly bring you problem when the network is large-scale and 
cross-forward.
Tal: Right, I agree, so if you want to replace the entire flip, you have 
the old one and the new one in practise, then you are right, there are 
double buffering. But if you want to do gradually, I mean each time you 
update a few, you don’t need that.
Stewart Bryant: you have to have the whole thing there to deal with such 
as critical failure to the network. The network requires you, for 
example, the ring structure, I think it changed.
Tal: Right.
John Dowdell: Presentation very interesting. On Monday we did make this 
happen to work.
Boris Khasanov: This presentation reminds me a debate that occurs 
sometime before: which one is better, sync protocol or async protocol? I 
would love to see the (followup) work;

-----------------
5. Authentication and Authorization in Wired OpenFlow-based Networks 
using 802.1X
Frederik Hauser (Uni-tuebingen)
10 Minutes

(Presentation Summary)
Status quo: highly insecure approaches, MAC-based and web portals. They 
investigated the use of 802.1X in an SDN environment, bringing the 
Authenticator as an application on the SDN controller which is compliant 
to standards and makes no changes to the endpoints. Another extension 
was introducing a network-wide session database for identity based 
network control, supporting both fine-grained and complex admission rules.
Future work: deploy to larger testbeds

(Q&A)
Laurent: already deployed? In lab or campus?
Frederik: It was just in the lab.
Laurent: are you going to real deploy it?
Frederik: The next step is to moving to bigger test.

-----------------
6. Limitations of Optimization for Multi-site NFV Network Service Delivery
Andy Veitch (NetCracker)
10 Minutes

(Presentation Summary)
Orchestration for SDN and NFV are separate and independent, while the 
combination of them is expected to reduce OPEX and CAPEX. They are 
involved in a number of activities reviewing the state of the art and 
potential implications for IETF. Two use cases presented, where network, 
compute, storage are considered all together.

(Q&A)
Hui Deng: speak for OPEN-O; that project try to integrate SDN/NFV 
orchestrator; I see here you put the agent into separate SDN/NFV 
orchestrator.
Andy: more historically, you have a PCE/SDN controller that has not have 
the orchestrator function, and cannot provide virtual services. What the 
resource are available to Data Centers? What is going on in the network? 
Thus information is not available then.
Hui Deng: looking at the architecture, we do have similar project about 
drivers to interconnect DCs and provide L2vpn, L3vpn; the challenge 
would be the bounder issue, especially for update;
Andy: agree, the challenge should be response time, as there is a lot of 
interaction. This time duration also depends on what information do you 
want to report/receive on the interface.
Hui deng: Suggest to have a look at OPEN-O;
Andy: there are a few open source projects.
Diego: please go offline discussion on open source project.

-----------------
7. SDN Controller Performance Evaluation
Yimeng Zhao (telecom-paristech)
10 Minutes

(Presentation Summary)
Currently, there are few tools to evaluate the scalability of SDN 
controllers. High availability is really difficult to prove. Results 
shown for evaluating centralized controllers. Different python 
interpreters may affect performance as much as 4 times, and setting such 
as hyperthreading were found useful for Java-based controllers. Also 
evaluated distributed controllers (ODL and ONOS). They exhibit control 
latency due to synchronization. An efficient synchronization system is 
needed for distributed controllers.

(Q&A)
Pedro: you compare performance from different implementation; too many 
dimensions, should compare apple to apple; need more about background 
information
Yimeng: we do have different controller implementations in different 
scenario,
Pedro: I do have some doubt on
Boris: Can you help share the report?
Yimeng: Yes
Diego: like to see the report shared in SDN RG.
Samuel Jero (Purdue): what is missing in the presentation is what you 
did to get these numbers. Are we talking about switching, or routing. 
Could you tell more about the methodology? can you share more 
methodology how you get these numbers?
Yimeng: several OSes were used to generate packet requests. Part on 
C-bench and some on vswitch;
Samuel: I encourage you to use more realistic conditions.
Yimeng: We do need and deeper investigation on testbed.
Sara Banks (BMWG co-chair): please look at the use cases from BMWG, and 
please send the test report to BMWG as well.
Uri Ezur (Intel): testing the controller in isolation without end 
stations is very theoretical. In order to allow the community to 
reproduce the results, detailed descriptions and identification of 
bottlenecks would be need to be included in the report.

-----------------
8. VNF Benchmark as a Service
Robert Szabo (Ericsson)
10 Minutes

(Presentation Summary)
Goals for VBaaS are to extend ETSI NFV by defining complementary 
functional components that define interfaces and VBaaS workflows.

(Q&A)
Uri Elzur: try to measure the performance about VNF in different DCs? Do 
you need to go the resolution to go through the NFV? Did you distinguish 
between the performance on network and the performance on NFV?
Robert: Yes, fully distributing. We have scenarios that fix on one side 
and compare on the other side.
Uri Elzur: would like to see splitting two components.
Diego: Please move the discussion offline.

-----------------
9. The abstract art of composing SDN applications
Pedro Aranda (Telefonica)
10 Minutes

(Presentation Summary)
Management of programmable networks need to evolve. Foreseeable 
evolution paths include treating network functions as software 
libraries, better abstractions and integrating machine learning 
mechanisms. The NetIDE project provides one mechanism to support 
software development for networks. Application composition is a 
challenge, as it may create conflicts for accessing basic resources such 
as flow tables.
Better abstractions:  Java, Python libraries are not intent, they are 
just low level abstractions. A discussion on intent definitions, related 
to work from IBNEMO and ODL-NIC as first steps in the right direction.

(Q&A)
No Question Discussed. (due to time-limit)

-----------------
10. Control as a minimal common denominator for future networking
Artur Hecker (Huawei)
10 Minutes

(Presentation Summary)
Transition from code from vendors tested on some devices, to untested 
code from 3rd parties. So how can we go forward from this?
SDN promised software-defined networking, but the programmability is 
actually quite limited to largely traffic switching. Also, there is 
insufficient protection e.g. the programming model is very basic.
They propose “unified control” through a resource-to-resource protocol 
suite dedicated to establishing and maintaining control but without 
presuming a specific usage. Two dimensions of unification, spanning both 
horizontal and vertical interactions. The purpose is to create a 
capability that allows producing self-* control planes, e.g. a 
network-OS kernel.

(Q&A)
Diego:Thanks Artur, please use the list for further discussion.

-----------------
11. Discussions
Not Discussed. (due to time-limit)

-----------------
12. Closing
Not Discussed. (due to time-limit)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++