SDN BoF/Side Meeting - IETF-82, Taipei
Thursday, November 17, 2011   
1740-1940 Afternoon Session III

AD          Adrian Farrel
Chairs   Lou Berger and Wes George      
Minutes Dan King           

Jabber Room     http://www.ietf.org/jabber/logs/sdn@jabber.ietf.org/               
Mailing list         http://www.lucidvision.com/mailman/listinfo/sdnp       

Meetecho           http://www.meetecho.com/ietf82/recordings#SDN

Agenda

Administrivia and Agenda Bash (Chairs) [10, 10/120]

Purpose of the meeting (AD) [5, 15/120]

·         Please don’t dive into the different VPN solutions

·         This is not working group creation BoF.

·         This is an informational gathering exercise.

·         Would like to identify the “killer application”.

·         Need to avoid solutions and focus on the architecture.

·         Finally, key objectives of the session are to understand who will be willing work in this area, who will go away and write code and who actually has problems they need to solve. 

SDN Problem Statement and Scenery (Tom/Ping/Dimitri) [15, 30/120]
Draft: http://tools.ietf.org/html/draft-nadeau-sdn-problem-statement-01

·         The document builds on a side meeting in Quebec.

·         Intention of SDN “Enables network applications to request and manipulate network services and allows the network to provide feedback to the applications”.

·         Chairs requested questions are held until end of presentations.

Relationship to other efforts    
- ONF Introduction and Overview (Dave Ward) [10, 40/120]

·         Presenting on behalf of ONF / Dan Pitt

·         Dave was asked by Wes George if a formal liaison was required. Dave thought yes, and stated that Dan and Russ are in communication regarding this issue.

·         - ONF & IETF (Dave Meyer) [10, 50/120]

Use cases/Examples     
Software Driven Networks: Use Cases and Framework  (Dimitri Stiliadis) [10, 60/120]
Draft: http://tools.ietf.org/html/draft-stiliadis-sdnp-framework-use-cases-01

·         Some concern from Chris L?? Going back to your logical block diagram slide,  why going over between multiple layers versus having controllers…. Presenter highlighted that it was a logical representation and that it may be necessary to stich technology together. Chris responded that complexity is increased if many elements are capable of creating state. Presenter agreed that there are multiple ways to solve the problem and don’t want to get caught up in a specific solution.

·         Ted Harding suggested that better terminology is possible from an applications area perspective, and that the term application service provider may be better. And further clarification of terminology would be beneficial.

·         Lou Berger (co-chair) reminded group that the focus for today’s session is to discuss purpose / context and not specific solutions.

Software-Defined Network (SDN) Use Case for Bandwidth on Demand Applications  (Shane Amante) [10, 70/120]        
Draft: http://tools.ietf.org/html/draft-pan-sdn-bod-problem-statement-and-use-case-01

·         Paul (?) highlighted that potential solution components are being discussed/worked on in other SDOs.

·         The presenter Shane Amante outlined that a common language does not exist that describes the network topology. This would be required to model the network in a uniform way, and allow application modelling on top. Ed Crabbe responded that network language modelling exist, in fact a problem is that there are too many available. Shane disagreed and mentioned that network modelling is required for physical and logical components.

·         Lou Berger raised the fact that service descriptions are not well defined.

Software-Defined Network (SDN) Problem Statement and Use Cases for Data Center Applications (Ping Pan) [10, 80/120]               
Draft: http://tools.ietf.org/html/draft-pan-sdn-dc-problem-statement-and-use-cases-01

Cloud Bursting Use Case
(Dave McDysan) [10, 90/120]     
Draft: http://tools.ietf.org/html/draft-mcdysan-sdnp-cloudbursting-usecase-00

Framework for Software Defined Networks
(Tom Nadeau) [0, 105/120]         
Draft: http://tools.ietf.org/html/draft-nadeau-sdn-framework-01

Traffic classification, filtering and redirection for end-system IP VPNs
(Pedro Marques) [0, 105/120]   
Draft: http://tools.ietf.org/html/draft-marques-sdnp-flow-spec-00

Identifying the work items and General Discussion
(All)

Joel: I see number of problems, different presentations. When you ask “do you want to work on problem”, which problem?
Lou Berger: Did you read any of the documents?
Wes George: The question would be to room. Where do you see commonality, some problems are unique. Others will overlap.
Kireeti Kompella: A lot of good stuff presented. Now Google “Cisco AON” (Application-Oriented Networking), Cisco states this product is no longer being sold. Juniper has an SDK as well.
David Black: I am looking at use cases. There is something here somewhere. I am just not sure what it is. What are the small numbers of things to make useful progress and how do you judge that?
Shane Amante: The speakers are right, there are a wide set of uses cases, but look at the last question (see slides) and start there. Architecturally, maybe we should be looking at the problem top down.
Ping Pan:  We (SDN draft authors) have been told to narrow it down, (specifically) which use cases are important.
Wes George: The chairs perspective regarding use cases was not to define the problem merely to think about the space and to find commonality.
Igor Gashinsky: The problem statement was a good starting point. We should look at thus top down. All these use cases can be generalized as requiring an API for automation.
Wes George: Define automation, network provisioning? Is this for soft state as well?
Chris Liljenstolpe: I agree if we include hard state and soft state, the API call would affect paths.
Lou Berger: What makes that soft?
Chris L: This would live for the ephemeral rather than long living state, maybe there a need for programmable API.
Lou Berger: Good comments. Is there a need for programmable API?
Ed Crabbe: Inter-domain yes. We are looking at common description language and services. You can provision service types, you can FEC with OpenFlow, but you cannot do that with PCE. Global brokers could navigate what potential services are available via south bound APIs.
Unknown???: I see commonality between solutions than problem statements. I am not sure if each of the problems needs a standard, not even sure the IETF is the right places. The only relevant question we can address is the last question on the list. Otherwise we have huge problems, and big solutions.
Wes George: So to paraphrase, we do not want to boil the ocean. We do not want individual problem statements one generic issues.
Luyuan Fang: I would like to get help on VPN4DC, where we focusing on layer-3. We have all kinds of common elements to do the provisioning and mapping. The question is top down or bottom up. Only looking one problem, it does not work on other things. We cannot cover everything but we need to get on right path.
Wes George: Do we have “time is of the essence” problem, we (IETF) are not known for speed. This is exploratory BoF, we are talking at least one more BoF, are we already quite far behind the curve.
Luyuan Fang: We would like to see it happen (soon).
Ning So: In the last few days we have seen various approaches, top-down, bottom-up and CSO. The problem space is large enough, the need is varied enough. Maybe we need to try multiple solutions and synchronise (results).
Lou Berger: So one theme is really important here, that is to narrow scope of activity. That is counter to what you (Ning So) said. A formal problem definition that’s narrow is required.
Igor: I am confused, people mention orchestration, VM/Zen/Openstack/Amazon all have orchestration. If we talking about meta language to describe orchestration. We have three choices, a) boil ocean, b) figure out state (pick any random model), c) xLAN, L2/L3, and defining standards as to how they should be stitched, these are tractable problem statements.
Wes George: I tend to agree.
Charlie Perkins: When I heard provision, TR69 ITFN (Dan King - International Tropical Farmers Network???) from large standards groups that tried to create common language for controlling diverse equipment. We need to narrow scope, maybe it’s worth a gap analysis to see what is needed. OpenFlow is assembly language for control, not the control model. The Cisco AON is illuminating.
Lou Berger: A gap analysis will be important once there is WG, but we are bit away from that.
Dave Meyers: I heard three times, time pressure, IETF stake in ground, etc. I am sympathetic to reason, but that is poor rationale to forming a WG. We should put some thought into it, currently this is not the right criteria.
Shane Amante: We have plenty of IETF tools and a good understanding. We should be looking at using the tools to construct a variety of things (solution?) in a seamless fashion. My observation is that a common description language to describe network topology diagrammatical,  is important for multi-domain and interoperability.

Shen: Topology representation and interoperability are important.

Summary
(Chairs/AD)

Co-chairs Poll 1: Is this an area the IETF should work on? ”A pretty good number”
Co-chairs Poll 2: Who thinks the IETF should not work on this? “A few, but notably less”
Co-chairs Poll 3: Which direction, top-down (architectural approach)? “Again a good number, but probably less than #1”
Co-chairs Poll 4: Which direction, bottom-up (use cases/solving problems)? “Some, not as many”
Co-chairs Poll 5: Which direction, both? ”chairs think the sum of the two, an AD thinks there were more for poll #1, clearly it was close.”

 

Co-chairs: In general a strong statement that the group thinks we have something to work on within the IETF. As this is a non-working group forming Bof, the next question to answer is what do we need to do in order to hold a working group forming bof. It seems the group has said that  there needs to be a better definition of the problem of what we need to solve. This includes use cases and a formal problem statement. Are there other things the Ads would like to see before meeting again?
Adrian Farrel:  After 8 weeks of heavy effort. We could not write charter now; we still do not have enough to work on. These documents are good but have not got us to where we need to be.  The use cases prove we need to do the work, and we can create architecture. Ideally I wanted to see a “killer app”.
Wes George: The things that I would like to see, are Tom and Ping creating generic architecture level problem statement, where we can focus the definition of concepts.
Lou Berger: I agree we have a nice set of documents, we want one document with multiple use cases and problem statement, we need straw man architecture.

Adrian Farrel (AD): Sees use cases as important justification for work, but still not clear that there is a real ‘killer app’.

Wes George: proposes a problem statement with architectural framework. Authors may want to take a pass at this.

Lou Berger: proposes a slight modification: The current documents can be the foundation for a consolidated document which contains multiple use cases and unified problem statement. And that a second document provide a strawman architecture, together with the first document, may be sufficient for the ADs to consider a WG forming BoF.


Adrian Farrel Poll 1
: If we had WG to work on something in this space, who would write text?  A fair number of “heros”.

Adrian Farrel Poll 2: Is this work for the Routing Area? A small number of hands (Adrian off the hook)

Adrian Farrel Poll 3: Is this work for the Operations Area? More than routing

Adrian Farrel Poll 4: Is this work for the (realtime) Applications Area? Again not an overwhelming number.

Lou Berger: Part of the problem is that there are multiple interfaces and that some may belong in one area, others in a different area.

Adrian Farrel: It is instructive that there are many who want to do the work, but few have a good idea of which area should do the work. Please communicate with the ADs and the mailing list.