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.