February 28, 2013
wg-sdn call
Attending:
Dale Carder - dwcarder@wisc.edu
kevin mayeshiro (kmayeshiro@ucdavis.edu)
Eric Pouyoul / ESnet (lomax@es.net)
David Crowe, Oregon, crowed@nero.net
Michael Van Norman (mvn@ucla.edu)
Chris Small, Indiana University (chsmall@indiana.edu)
Grover Browning, gcbrowni@iu.edu, IU, I2
Jeffry Handal - jhandal@lsu.edu
Charles Chambers - cchambers@central.uh.edu
Bill Owens - owens@nysernet.org
Eric Boyd - eboyd@internet2.edu
Rich Cropp - rac111@psu.edu
Michael Lambert - lambert@psc.edu
Jeff Bartig, University of Wisconsin - jeffb@doit.wisc.edu
Scott Brim, Internet2
1) Agenda bash
2) Eric Pouyoul (of ESNet) will share his impressions from USIgnite developer’s workshop on network abstractions from user/application developer’s perspective
3) Questions this workgroup is interested in answering:
- Quick guide to starting an OpenFlow testbed
- Vendors and updates on OpenFlow implementations
- IETF and ONF standardization status
- ?
4) Proper ISP Platform: Juniper MX-80 or Cisco ASR9k
- Experiences for SDN or Openflow?
- Who do we believe will or is doing it better?
USIgnite: application developer's perspective
few network engineers at the USIgnite - not very deep understanding of the network
Build network services using SDN: cost effectives, more capabilities, technology-awareness
Are we really satisfying the needs of users and applications?
How do we see the network?
APIs that application developers can use: northbound, etc.
Transfer of files from A to B - if it does not happen within T give up
Know when network will work
Emergency/hospital services over network - user information sensitivity to privacy on network
Policy - behaviour perspectives from top - bottom (instead of technology-specific)
Adaptive application development to network behaviour
Socket API is all that is available to an application developer - nothing else can be provided at this time
More mechanisms for applications to react/cooperate with network
Best effort service with current setup of network abstractions - that's why applications are more reactive
Network does not have a feedback mechanism for resource allocations - provisioning with better information on the network availability - not easy
2 directions:
1. technology keeps progressing and view is from bottom up
2. applications may be equipped with more abstraction (how?) from network; applications written on the network with network-awareness; user can see flows
Network is an end-to-end system - difference from a regular PC resources (CPU, memory, bus, etc.) - PC will have some troubleshooting available to OS and applications for failures/performance - in a network, there are no tools to do so
ISP platforms emerging for SDN:
MX-80: MX-240 and higher is different from MX-80 (big difference--x86 vs PPC)
Code works on Juniper MX-240 as I2 has experienced
Cisco code may be a bit behind. No results but not too ready yet.
I2 will be sharing test results of platforms soon.
Cisco ASR9k - I2 and LSU testing?
non-Cisco Controller works with Cisco equipment, but Cisco controller does not work with Cisco - mostly based on OVS-base
NPU?
I2: basic functionality seems to work (Cisco)
IU (Chris): amazon usage, mininet s/w, web browser-based training sessions, multiple VM sessions with GRE tunnels over Amazon
AWS Openflow image
https://console.aws.amazon.com/ec2/home?region=us-west-2#launchAmi=ami-30b23900
before mininet 2, more up-to-date OVS than mininet 1.0
New OVSDB protocol release: forwarding abstractions WG (future revisions of OFConfig?)
Next things to be done on a spec from ONF is closed!
Features tables? Controller - switch negotiation of resources?
OVS: open source project that anybody can contribute
Management plane: proprietary implementations? more generalization in the core, less in the edge, vendor strategies, orchestration approaches may be closed, QoS setup is a very immediate need particularly cross-domain
OFConfig: stuff can be done within OF protocol
OVSDB: OVS switch, software switch focus
OFConfig: NetConf protocol, hardware implementation focus
Bill: Bridged GRE tunnel btw pica8 switches FIU and NY - how would it work? L2 WAN, end point configurations, lab/sandbox connectivity for controller trial, application trials, etc.
OVS - pica8 - other end points: OF-capable end points (GRE tunnel capability must)
pica8: switch interfaces to be used (instead of the management interface at eth0)
"ovs-vsctl" options are key!!!!
ONLab: FlowVisor?
Ali - FV next time
SDN and IP peering - ppt + demo
RouteFlow