Changes between Version 31 and Version 32 of OpenFlow/FOAM


Ignore:
Timestamp:
08/29/12 14:55:49 (12 years ago)
Author:
Josh Smift
Comment:

Updated sliver approval workflow, in light of auto-approval

Legend:

Unmodified
Added
Removed
Modified
  • OpenFlow/FOAM

    v31 v32  
    177177== Sliver approval workflow ==
    178178
    179 This section describes our workflow for approving slivers at BBN (those which aren't auto-approved).
     179This section describes our workflow for approving slivers at BBN.
    180180
    181181FOAM sends e-mail about new slivers to the FOAM admin e-mail address that you configured when you set up FOAM. If further communication about a sliver request is needed, we copy that address on the e-mail, so that everyone will see it. We also send mail to to that address when we approve or reject the sliver (or if we review the request and we're not sure whether to approve or reject it), so everyone knows who did it.
    182182
    183 Using the commands below, decide whether to approve it:
    184 
    185  * Get a list of pending slivers, and look for the new sliver in that list.
    186  * Get the sliver URN from the slicename.
    187  * Show the sliver's basic info, to confirm that we've got the right sliver URN:
    188    * Verify that the email field is valid, so that we and FOAM can contact the experimenter later about the sliver.
    189  * Show the sliver's rspec, to confirm that it matches the owner's description of what they're asking for:
    190    * Public information about common requests is on [ggw:GeniAggregate/GpoLabOpenFlow the GPO Lab OpenFlow aggregate info page].
    191    * For more complicated requests:
    192      * Look up the DPID in our inventory and find out what switch/VLAN it is.
    193      * Look up the hosts the experimenter asked for in our inventory, and make sure the ports the experimenter requested make sense.
    194  * Show the sliver's flowspace, and confirm that it matches the rspec, and doesn't contain anything dangerous, such as:
    195    * Look for flowspace rules that match '''any''' packet -- the third field in each rule -- as these might indicate a subtle error in the rspec.
    196    * Check to make sure the rspec and flowspace don't include multiple cross-connects, unless the experimenter has convinced us that they understand the risks and will be careful.
    197    * Check to make sure the rspec and flowspace don't include I2 plnodes (ganel, gardil, sardis) and NLR VLANs/cross-connects, or NLR plnodes (bain, navis) and I2 VLANs/cross-connects.
    198 
    199 If we conclude that the sliver is ok, approve it:
    200 
    201 {{{
    202 foamctl geni:approve-sliver -u $sliver_urn --passwd-file=/opt/foam/etc/foampasswd
    203 }}}
    204 
    205 If we conclude that we should definitely not approve the sliver, reject it:
    206 
    207 {{{
    208 foamctl geni:reject-sliver -u $sliver_urn --passwd-file=/opt/foam/etc/foampasswd
    209 }}}
    210 
    211 If we're not sure, do nothing, which will leave the sliver as Pending while we get more information.
    212 
    213 Regardless, send e-mail to the admin address saying what we did, so everyone's in the loop. (One convenient way is to reply to the notification message about the sliver.)
     183If a sliver is automatically approved, FOAM will also send mail when that happens. If the automatic approval fails (e.g. because FlowVisor is down, because the new sliver uses the same controller as an existing sliver, etc), the admin *won't* get mail; https://openflow.stanford.edu/bugs/browse/FOAM-288 is tracking that bug in FOAM.
     184
     185If a sliver isn't automatically approved, it'll show up in the pending queue, and have pend_reason set to some text explaining why the sliver wasn't automatically approved.
     186
     187Some reasons to reject a sliver that wasn't automatically approved:
     188
     189 * It includes multiple cross-connects.
     190 * It includes an I2-connected MyPLC plnode (ganel, gardil, sardis) and an NLR cross-connect, or an NLR plnode (bain, navis) and an I2 cross-connect.
     191 * It overlaps with something, and the existing sliver is more legitimate than the new one (e.g. someone's trying to use someone else's subnet).
     192
     193We generally follow up to the rejection e-mail message from FOAM, copying the experimenter, to explain why we rejected the sliver.
     194
     195Some reasons to approve a sliver that wasn't automatically approved:
     196
     197 * It includes a VLAN tag, but is otherwise fine to approve.
     198 * It includes an entire DPID and no ports, but is otherwise fine to approve.
     199 * It's something that we don't want to automatically approve for everyone, but are making a specific exception for in the case of this sliver/experimenter.
     200
     201Since this is new, this list is still a little vague, and deciding whether to approve a non-auto-approved sliver is something of a judgment call, since in theory any safe sliver should be auto-approved, and thus any non-auto-approved sliver has a pretty high chance of being unsafe in some way. If we find a type of sliver that isn't auto-approved, but that is always safe to approve manually, we'll add more details here.
     202
     203Regardless, we always send e-mail to the admin address saying what we did, so everyone's in the loop. (One convenient way is to reply to the notification message about the sliver.)
    214204
    215205== Managing FOAM slivers ==