February 28, 2013
Dale Carder - email@example.com
kevin mayeshiro (firstname.lastname@example.org)
Eric Pouyoul / ESnet (email@example.com)
David Crowe, Oregon, firstname.lastname@example.org
Michael Van Norman (email@example.com)
Chris Small, Indiana University (firstname.lastname@example.org)
Grover Browning, email@example.com, IU, I2
Jeffry Handal - firstname.lastname@example.org
Charles Chambers - email@example.com
Bill Owens - firstname.lastname@example.org
Eric Boyd - email@example.com
Rich Cropp - firstname.lastname@example.org
Michael Lambert - email@example.com
Jeff Bartig, University of Wisconsin - firstname.lastname@example.org
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
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
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
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!!!!
Ali - FV next time
SDN and IP peering - ppt + demo