Changes between Version 7 and Version 8 of GeniAggregate/NLROpenFlow/ExpansionPlan


Ignore:
Timestamp:
12/04/13 11:31:39 (6 years ago)
Author:
Josh Smift
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GeniAggregate/NLROpenFlow/ExpansionPlan

    v7 v8  
    33= NLR Expansion Plan =
    44
    5 NLR is adding three Pica8 switches to their GENI OpenFlow backbone deployment; this page describes the plan for this expansion.
     5NLR is adding three Pica8 switches to their GENI !OpenFlow backbone deployment; this page describes the plan for this expansion.
    66
    77= Hardware =
     
    1515There are two firmware options for the Pica8: L2/L3 and OVS.
    1616
    17 L2/L3 Mode -  "Standard" Layer2/Layer3 software that supports traditional switching/routing, as well as Openflow version 1.0 - 1.3.  In this mode, the each port supports both layer2/layer3 and Openflow forwarding at the same time (Hybrid mode), and Pica8 calls this functionality "cross-flow."  This mode has support for the protocols needed by the current NLR operational support model (SNMP and TACACS+).  In addition, the CLI used to configure the device is akin to the standard Cisco IOS-XR CLI (commit changes to apply, editable configuration sub-sections, configuration history).  Openflow support is basic and lacks some of the additional Openflow mechanisms like generating flows locally from the device.
     17L2/L3 Mode -  "Standard" Layer2/Layer3 software that supports traditional switching/routing, as well as !OpenFlow version 1.0 - 1.3.  In this mode, the each port supports both layer2/layer3 and !OpenFlow forwarding at the same time (Hybrid mode), and Pica8 calls this functionality "cross-flow."  This mode has support for the protocols needed by the current NLR operational support model (SNMP and TACACS+).  In addition, the CLI used to configure the device is akin to the standard Cisco IOS-XR CLI (commit changes to apply, editable configuration sub-sections, configuration history).  !OpenFlow support is basic and lacks some of the additional !OpenFlow mechanisms like generating flows locally from the device.
    1818
    19 OVS - PicOS Open vSwitch software mode that only supports Openflow forwarding.  This mode supports the same versions of Openflow as L2/L3 Mode.  The CLI and functionality of the device is more akin to a Linux server than a traditional router/switch.  In this mode, you use two programs, ovs-vsctl and ovs-ofctl, to configure the switch and Openflow functionality on the switch.  This mode lacks SNMP support, and therefore will not work for basic NLR operational monitoring and graphing tools.  Openflow support in this mode is much more advanced and includes the feature to generate IPv4 flows from the switch locally.
     19OVS - PicOS Open vSwitch software mode that only supports !OpenFlow forwarding.  This mode supports the same versions of !OpenFlow as L2/L3 Mode.  The CLI and functionality of the device is more akin to a Linux server than a traditional router/switch.  In this mode, you use two programs, ovs-vsctl and ovs-ofctl, to configure the switch and !OpenFlow functionality on the switch.  This mode lacks SNMP support, and therefore will not work for basic NLR operational monitoring and graphing tools.  !OpenFlow support in this mode is much more advanced and includes the feature to generate IPv4 flows from the switch locally.
     20
     21The OVS mode seems superior from an !OpenFlow point of view, but problematic from a management perspective, to a show-stopper extent, so the initial deployment will use the L2/L3 mode.
     22
     23Barnstormer Softworks (BSSW) has expressed some interest in creating an OVS firmware with SNMP support, which would be very much worth considering.
    2024
    2125= Topology =
     
    3135== Phase 1 testing ==
    3236
     37This phase tests the basic operation of the switch, and is complete.
     38
    3339 * Boot in L2/L3 Mode (Complete)
    3440 * Basic configuration template (Complete)
     
    4046   * SSH Enabled / Telnet Disabled
    4147   * Syslogging
    42  * Basic Openflow configuration testing (Complete)
    43    * Enable Openflow globally
    44    * Connect to Flowvisor
     48 * Basic !OpenFlow configuration testing (Complete)
     49   * Enable !OpenFlow globally
     50   * Connect to !FlowVisor
    4551   * Verify resource advertisement remotely
    4652
    4753== Phase 2 testing ==
     54
     55This phase tests the Phase 1 deployment configuration, with static flows in the switch. Target completion date: 2013-12-06
    4856
    4957 * Layer1Transport testing
     
    5664== Phase 3 testing ==
    5765
     66This phase would test a future BSSW firmware release.
     67
    5868 * BSSW to develop "newer" version of OVS software
    5969   * SNMP/TACACS enabled
     
    6373= Deployment =
    6474
    65 The switches will be deployed into the field in two phases (which don't correspond at all to the testing phases below).
     75The switches will be deployed into the field in two phases (which don't correspond at all to the testing phases above).
    6676
    6777== Phase 1 deployment ==
     
    6979In the Phase 1 deployment, the switches will be put into the field and connected to each other, but only two ports will be enabled on each, and the layer1transport controller will be used to pass traffic between the two ports, with no experimenter control yet.
    7080
     81Deployment schedule:
     82
     83 * By 2013-12-13: Finish writing MOPs
     84 * By 2013-12-20: Ship hardware
     85 * By 2014-01-03: Hardware mounted and connected to control/management networks
     86 * Week of 2014-01-06: Mainteance windows for GENI dataplane cutover
     87
     88All three switches will be deployed in parallel.
     89
    7190=== NLR HOUS deployment ===
    7291
    7392 * Mount/Power
    7493 * Connect to NLR Out-of-Band
    75  * Connect to NLR FrameNet for In-Band Management / Control-Plane Traffic
     94 * Connect to NLR !FrameNet for In-Band Management / Control-Plane Traffic
    7695 * Verify basic IP Connectivity
    7796 * Establish connection to Layer1Transport on NLR FOAM
     
    86105 * Mount/Power
    87106 * Connect to NLR Out-of-Band
    88  * Connect to NLR FrameNet for In-Band Management / Control-Plane Traffic
     107 * Connect to NLR !FrameNet for In-Band Management / Control-Plane Traffic
    89108 * Verify basic IP Connectivity
    90109 * Establish connection to Layer1Transport on NLR FOAM
     
    99118 * Mount/Power
    100119 * Connect to NLR Out-of-Band
    101  * Connect to NLR FrameNet for In-Band Management / Control-Plane Traffic
     120 * Connect to NLR !FrameNet for In-Band Management / Control-Plane Traffic
    102121 * Verify basic IP Connectivity
    103122 * Establish connection to Layer1Transport on NLR FOAM
     
    116135In the Phase 2 deployment, the switches will be reconfigured to be controlled by the NLR !FlowVisor, and the third port on each will be activated, allowing experimenter control and more interesting experimenter topologies.
    117136
    118 FIXME: What happens with VLAN 3715 and 3716 in this phase?
     137On the new switches, VLANs 3715 and 3716 won't cross-connect with VLAN 1750, and we simply won't have campuses connect in to the new switches directly. (Enabling this would be a third phase, which we can plan and carry out if it turns out to be necessary.)
    119138
    120 FIXME: What happens with auto-approval in this phase, now that NLR FOAM has a mix of VLAN-hybrid and non-hybrid switches?
     139The NLR rspecs will be a bit more complicated after Phase 2 is complete: They'll need a new openflow:group for the new switches, and a separate match for them that includes the relevant dl_vlan match.
     140
     141FIXME: What happens with auto-approval in this phase, now that NLR FOAM has a mix of VLAN-hybrid and non-hybrid switches? We don't know for sure, but are confident that this isn't a show-stopper issue.
    121142
    122143=== Final topology/configuration ===