This is the list of ExoGENI Use Cases sent to ​exogeni-design@geni.net. When information is exchanged it will be captured here for each use case. Also, any document that is refereed to with a URL was attached to the page for historical reference. Following are notes attributions:

JS: Josh Smift     JC: Jeff Chase 

ExoGENI Use Cases

There are 8 ExoGENI Use Cases that were discussed in the ExoGENI design review. The Use Cases were also seeded in the mail list ​exogeni-design@geni.net for discussion. Note that the 6 experimenter use cases all assume that the experimenter is using the GENI AM API (e.g. with the OMNI client).

Experimenter Use Cases

Use Case 1

I want to reserve some resources within a single ExoGENI rack. "Resources" includes both compute and network resources in this use case and in the five that follow.

Use Case 2

I want to reserve some resources in multiple ExoGENI racks, and have them all connected at layer 2.

Use Case 3

I want to reserve some resources in one or more ExoGENI racks, AND one or more other resources that are connected to NLR or Internet2 at layer 2, and have them all connected to each other at layer 2. (These other resources might be GENI resources or might not be; let us know if this makes a difference.)

Use Case 4

I want to reserve only some OpenFlow resources in the ExoGENI rack, to connect some non-ExoGENI resources at a site (which are connected at layer 2 to the ExoGENI rack dataplane switch) to some non-ExoGENI resources at another site (via NLR or Internet2). (Aka "how do I use just the OpenFlow switch to connect a site network to an upstream network without using any ExoGENI compute resources".)

<JS>I was going to follow up on this one; here's a concrete example of two
    ways that I think it might work, which I'm hoping y'all will say either
    "yes, it'll work that way" or "no, it won't work that way" about each.

    Background for both cases: Alice (experimenter) has (a) some computers in
    her lab at Enormous State University, which are on an OpenFlow network
    that she controls; (b) some other resources at other campuses, on OpenFlow
    networks, that are connected to the GENI mesoscale network, on VLAN 3715
    say. She wants to connect these two sets of resources at layer 2, via the
    OpenFlow switch in the ExoGENI rack, which connects to both (on port X to
    the GENI mesoscale, and port Y to campus).
    
    The FOAM Way: She uses FOAM to allocate some flowspace for her traffic. 
    In FlowVisor terms, she requests flowspace like
    
      in_port=X,dl_vlan=3715
      in_port=Y,dl_vlan=3715
    
    A FOAM admin (not RENCI; we predict that we will draft a campus admin to
    do this) reviews and approves her request (or it's automatically approved
    by FOAM's (forthcoming) policy engine).
    
    (This may get slightly more complicated if her OpenFlow network isn't
    directly connected to port Y, i.e. if it needs to traverse some campus
    switches (and VLANs) first, but let's start with the simple case.)

    The ExoGENI Way: She uses ExoGENI to allocate a VLAN, whose endpoints are
    "port X" and "port Y". (Or something like that? I'm a little fuzzy on this
    part -- in particular, how does her VLAN get translated onto 3715 via X,
    and what happens on the campus side?) This functionality may not exist
    yet, but might soon.

    This is vague and probably incomplete and perhaps entirely wrong. Please
    feel free to say "no no no no" and explain how it'll really work. :^)
   
    Relatedly: Is this "the on-ramp", or is that something else?

<JC> Let me generalize your example.  Suppose your fixed static VLANs V1 and V2 
     are adjacent to ports (interfaces) X and Y somewhere in the ExoGENI network.
     Port X is on switch(X), and port Y is on switch(Y).  These might not be the
     same switch.

    Suppose first that the VLANs V1 and V2 are not shared, i.e., the slice owns all 
    flows on the VLANs.

    Then the problem is to provision a point-to-point virtual Ethernet link (VLAN) 
    between switch(X) and switch(Y) as part of your slice, and stitch it to V1 on 
    one end and to V2 on the other end.    This is a problem of external stitching: 
    somehow the stitching API needs you to be able to prove to ExoGENI that you own 
    that V1 and V2, and if it does, then we'll be OK.

    If switch(X) and switch(Y) are OpenFlow switches, and you want to register a 
    controller there, then it is the same, except that you want to skip the stitching 
    steps: instead, you want your virtual link to terminate on the edge switches.  
    With a better hybrid mode we might be able to stitch and use OpenFlow at the same 
    time, but this kind of "real" (to me) hybrid mode is not in the forseeable roadmaps
    for switch vendors.  The weak support for hybrid mode may turn out to be a pretty 
    deep problem.  We're still working through the implications.   For example, Ilia
    has pointed out that we're not sure whether a controller can touch any traffic 
    that enters and/or exits a non-OF-aware circuit provider or RON, since ports 
    facing those networks weren't planning to be in OpenFlow mode.  But that's a 
    separate issue.

    Leaving that aside, both of these cases should be doable.  There are some limitations 
    in our NDL request model that prevent us from requesting virtual links that terminate 
    at interfaces of named switches: we need this for all the OpenFlow cases, but currently
    the virtual links must terminate at interfaces of virtual hosts.  But we can fix that.

    But there's a deeper authorization problem here that gets at the heart of your question. 
    If V1 and V2 are shared, then how is ExoGENI to know what flows on them belong to you? 
    The issue here is that you want to bridge traffic from a shared link onto a private link. 
    FOAM might be a solution to this problem, and we have no objection to its use to authorize 
    flows manually.   ExoGENI itself has no sharing of virtual links among slices.  (Except 
    by on-ramp, which is not implemented.  On-ramp is a stitch between private links owned by 
    two different slices, by mutual consent of both slices.  It is the moral equivalent of 
    slices peering their virtual networks.)

    I didn't directly address the exact case you mentioned: switch(X) == switch(Y).  That 
    case is unique because the slice doesn't need to allocate any resources from the aggregate 
    (except flowspace).  This is a good question.   It should be possible for a slice to use the 
    stitching API to prove to ExoGENI that it owns external adjacent VLANs V1 and V2, and have it
    authorize your OpenFlow controller for flows on those VLANs, whether you allocated anything 
    from that aggregate or not.  This should work.  We will have to think about this some more.

    There is a new paper draft that says more about ExoGENI.   It has some overlap with the 
    design document, and some of the same figs, and it is still missing some figs, references, 
    polish, etc.  It is still a draft, but the text itself is pretty tight.  section 4 in particular 
    is highly relevant.  You can find it at http://www.cs.duke.edu/~chase/exogeni.pdf.  We welcome 
    comments. 

Use Case 5

Same scenario as (2) above, but I want the relevant network resources to be OpenFlow-controlled.

Use Case 6

Same scenario as (3) above, but I want the relevant network resources to be OpenFlow-controlled.

Note: If there's more than one way to do some of these (e.g. "you can either talk to an individual rack SM, or to the ExoSM"), we'd be interested in knowing that too, and in hearing some compare-and-contrast about the different options.

Operator Use Cases

Use Case 7

An update is available for some part of the software/firmware in the rack; I want it to be installed. (Related question: How are currently-running slivers affected by updates to various components?)

<AH> 14) No real SW update plan is in place.
    This isn't a surprise, but it's an ongoing concern. We would of course
    love to see a package repo for all pieces that they commit to
    maintaining. We probably want an item by item list of who maintains it,
    how it is updated, and the expected impact on experimenters when it is
    updated.
<CG>Using outside knowledge: i'd be a little surprised if they didn't have a
    package repo, given that Victor O maintains the duke-neuca CentOS repo
    already, so they have this power in-house.  Should we explicitly ask
    about/and or encourage that?  I think using a repo at RENCI would be
    perfectly fine --- what we really want is to be able to use packaging
    to easily verify whether things are up-to-date, right?

Use Case 8

Something in the rack is misbehaving; I want to identify which resources are causing the symptoms, which sliver those resources are currently allocated to, which slice that sliver is a part of, and who the owner of that slice is. (Corollary: I receive a report of past misbehavior from a resource; I want to identify the sliver/slice/owner who had that resource at the time.).