Changes between Initial Version and Version 1 of DecommissionedGeniAggregate/NLROpenFlow/ExpansionPlan


Ignore:
Timestamp:
01/12/16 15:25:08 (8 years ago)
Author:
hdempsey@bbn.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DecommissionedGeniAggregate/NLROpenFlow/ExpansionPlan

    v1 v1  
     1[[PageOutline]]
     2
     3THIS PAGE IS OBSOLETE.  NLR no longer exists, so these resources are not available, but we have kept the page for historical reasons.
     4= NLR Expansion Plan =
     5
     6NLR is adding three Pica8 switches to their GENI !OpenFlow backbone deployment; this page describes the plan for this expansion.
     7
     8= Hardware =
     9
     10Model: Pica8 P-3780 - 48 x 10GE SFP+ Ports[[BR]]
     11[[BR]]
     12Tech Specs: [http://www.pica8.com/documents/pica8-datasheet-64x10gbe.pdf]
     13
     14= Firmware =
     15
     16There are two firmware options for the Pica8: L2/L3 and OVS.
     17
     18L2/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.
     19
     20OVS - 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.
     21
     22The 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.
     23
     24Barnstormer Softworks (BSSW) has expressed some interest in creating an OVS firmware with SNMP support, which would be very much worth considering.
     25
     26= Topology =
     27
     28The new switches will be deployed in Kansas City MO (NLR KANS), El Paso TX (NLR ELPA), and Houston TX (NLR HOUS). They'll add more paths to the current ring, as seen below:
     29
     30[[Image(NLR Proposed GENI Backbone.png, 80%)]]
     31
     32= Testing =
     33
     34The switches will be tested in the NLR lab before being deployed, in three phases (which don't correspond at all to the deployment phases below).
     35
     36== Phase 1 testing ==
     37
     38This phase tests the basic operation of the switch, and is complete.
     39
     40 * Boot in L2/L3 Mode (Complete)
     41 * Basic configuration template (Complete)
     42   * Username/Password
     43   * SNMP
     44   * TACACS
     45     * Unable to login with "backdoor" username/password if TACACS is enabled.  Until this is addressed, TACACS isn't an option
     46     * Unable to configure remote port. Pica8 is aware and will address in future revision.
     47   * SSH Enabled / Telnet Disabled
     48   * Syslogging
     49 * Basic !OpenFlow configuration testing (Complete)
     50   * Enable !OpenFlow globally
     51   * Connect to !FlowVisor
     52   * Verify resource advertisement remotely
     53
     54== Phase 2 testing ==
     55
     56This phase tests the Phase 1 deployment configuration, with static flows in the switch. Target completion date: 2013-12-06
     57
     58 * Layer1Transport testing
     59   * layer1transport configured on NLR FOAM with test rules
     60   * Configure switch with connection toward layer1transport service
     61   * Generate traffic from BSSW test host
     62   * Verify basic traffic connectivity
     63   * Performance testing?
     64
     65== Phase 3 testing ==
     66
     67This phase would test a future BSSW firmware release.
     68
     69 * BSSW to develop "newer" version of OVS software
     70   * SNMP/TACACS enabled
     71   * CLI similar to L2/L3 Mode
     72 * Future testing?
     73
     74= Deployment =
     75
     76The switches will be deployed into the field in two phases (which don't correspond at all to the testing phases above).
     77
     78== Phase 1 deployment ==
     79
     80In 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.
     81
     82Deployment schedule:
     83
     84 * By 2013-12-13: Finish writing MOPs
     85 * By 2013-12-20: Ship hardware
     86 * By 2014-01-03: Hardware mounted and connected to control/management networks
     87 * Week of 2014-01-06: Mainteance windows for GENI dataplane cutover
     88
     89All three switches will be deployed in parallel.
     90
     91=== NLR HOUS deployment ===
     92
     93 * Mount/Power
     94 * Connect to NLR Out-of-Band
     95 * Connect to NLR !FrameNet for In-Band Management / Control-Plane Traffic
     96 * Verify basic IP Connectivity
     97 * Establish connection to Layer1Transport on NLR FOAM
     98 * Break existing SUNN to ATLA GENI backbone and insert new switch into path
     99   * Port 48 --> Atlanta
     100   * Port 47 --> Sunnyvale (Soon to be El Paso)
     101   * Port 46 --> Kansas City (New Connection / Disabled at this moment)
     102 * Verify GENI backbone connectivity
     103
     104=== NLR ELPA deployment ===
     105
     106 * Mount/Power
     107 * Connect to NLR Out-of-Band
     108 * Connect to NLR !FrameNet for In-Band Management / Control-Plane Traffic
     109 * Verify basic IP Connectivity
     110 * Establish connection to Layer1Transport on NLR FOAM
     111 * Break existing SUNN to HOUS to ATLA GENI backbone and insert new switch into path
     112   * Port 48 --> Atlanta (Soon to be Houston)
     113   * Port 47 --> Sunnyvale
     114   * Port 46 --> Denver (Disabled at this moment)
     115 * Verify GENI backbone connectivity
     116
     117=== NLR KANS deployment ===
     118
     119 * Mount/Power
     120 * Connect to NLR Out-of-Band
     121 * Connect to NLR !FrameNet for In-Band Management / Control-Plane Traffic
     122 * Verify basic IP Connectivity
     123 * Establish connection to Layer1Transport on NLR FOAM
     124 * Break existing SEAT to DENV backbone and insert new switch into path
     125   * Port 48 --> Chicago
     126   * Port 47 --> Denver
     127   * Port 46 --> Houston (Disabled at this moment)
     128 * Verify GENI backbone connectivity
     129
     130=== NLR DENV maintenance ===
     131
     132 * Connect 10GE Port (28) toward El Paso
     133
     134== Phase 2 deployment ==
     135
     136In 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.
     137
     138On 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.)
     139
     140The 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.
     141
     142FIXME: 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.
     143
     144=== Final topology/configuration ===
     145
     146 * Connect all 3 switches to NLR !FlowVisor
     147 * Enable 3rd direction on all 3 switches (and Denver HP)
     148   * El Paso --> Denver
     149   * Houston --> Kansas City
     150 * Remove Layer1Transport connectivity on all switches?