wg-SDN call notes, 11/6/2014
kevin mayeshiro, email@example.com
Dan Schmiedt, firstname.lastname@example.org
Michael Van Norman, email@example.com
Michael Lambert, firstname.lastname@example.org
Dale W. Carder, email@example.com
Rich Cropp, firstname.lastname@example.org
Deniz Gurkan, email@example.com
Bill Chimiak, firstname.lastname@example.org
0. Agenda bash
Bill Chimiak: 100G port SDN-capable switch from KVIUM/Xpliant
1. GEC21 impressions:http://groups.geni.net/geni/wiki/GEC21Agenda/EveningDemoSession
and plenary http://groups.geni.net/geni/wiki/GEC21Agenda/Plenary
Federated environment for GENI - GPO contract with NSF is ending at the end of 2015. What are the transition plans?
Lessons learned from DYNES - a similar project transitioned into a decentralized project
Internet2 support of GENI is stitching, connectivity, multi-dimensional and complicated
wg-sdn network engineers support/maintain end points for GENI
Workgroup expectations going forward in support of GENI infrastructure
Chairs articulate research/practical/operational/service support expectations and submit to Internet2 (after circulating within the wg for comments/feedback)
Sites: unless there is support and maintenance of the software, may end gradually
Software maintenance: any of the software developers support and maintenance commitments? NSF funding, sustainability?
Enabling science data transfer may be a driving application or usage scenario that may sustain the infrastructure's existence, and gradually, it would become integrated into the internet as it is
Self-sustain if there are applications/research (USIgnite's goal)
2. Tech Exchange impressions, vendor SDN panel, others?
Vendor SDN panel: no extra information that we did not know of
Scott Shenker's talk: interesting perspective with ISP focus, edge-based management of programmability (not access, multiple hops later, but, not core either, core may stay as it is with MPLS, other sophisticated technologies), middleboxes should be served and enabled with edge-based programmability
3. SDNTrace discussion and solicit feedback from the WG on scope, aim, and participation
Basic problem definition:
The community needs a tool which will give the traditional "traceroute" capabilities along an OpenFlow defined path, regardless of whether the path is a layer 2 IP, a layer 2 non-IP, or a layer 3 path.
Create an ethernet frame based tool.
Should not be an IP only tool
Can be a CLI command and/or an Application definition that will run on top of a generic controller
* Must support multiple upper level protocols, not just IP
* Must support the capability to inject frames from this tool into the SDN path, without being on an end host that might not support the tool yet, i.e. a router. (application on controller?)
* Frame definitions must track at least the following:
** DPID/switch name
** Local Organizational Identifier: i.e. AS number, unique ID
** ingress interface
** egress interface
** next hop DPID, if known from LLDP or some other mechanism
*** must be able to identify gaps
- path A-B-C-D (A-.-B-D C is not participating in the protocol with ABD)
* Must be able to provide portion of 12-tuple header upon which control plane will execute action
* Frames must be scalable to allow more definitions of things to track and provided feedback, i.e. topological feedback, etc.
* Tool must provide raw text feedback.
* Tool may provide JSON feedback.
* Each controller must respect defined path route frame, process appropriately and pass it onwards for more processing
Eric Boyd would like to be in the loop.
Grover Browning interested in participating.
Please provide feedback and participate if interested as a wg.
4. AL2S update, Internet2
GPO learning switch - first other controller (different from OESS) on AL2S
GENI requires VLAN reservations (which is possible with OESS), does GPO learning switch implementation provide anything else other than VLAN-based flows?
5. Any other business?
(how does one get edit access to the wiki?)More detailed instructions are here: