Changes from Version 1 of MinutesFrom01Nov2007

Author:

trac (IP: 127.0.0.1)

Timestamp:

03/26/08 18:04:59 (2 years ago)

Comment:

--

MinutesFrom01Nov2007

@@ +1 @@
+
+
+== !ProtoGENI Project Meeting, 01 Nov 2007 ==
+
+=== Agenda ===
+
+{{{
+From: Jay Lepreau <lepreau@cs.utah.edu>
+Sender: lepreau@flux.utah.edu
+To: testbed-nops@flux.utah.edu, eeide@flux.utah.edu
+Subject: Re: GENI reading list
+Date: Wed, 31 Oct 2007 17:14:17 -0600
+
+[...]
+
+Folks: for tomorrow please read the first document below.  If you
+really don't have time, read the second (but you'll still have to read
+the other later, so would take more time total).
+
+[...]
+
+ o GENI Architectrue Redeux. June 2007.
+    http://www.cs.princeton.edu/~llp/arch_redeux_v0.3.pdf
+
+    An update to the GENI Architecture document (GDD-06-11) to reflect the
+    material incorporated into the Facility Design document. If you are going
+    to read only one document, this is probably it.
+
+ o A Minimal Definition of GENI's Narrow Waist.
+    http://www.cs.princeton.edu/~llp/arch_abridged.pdf
+
+   An abridged version of the Architecture document, focusing on the definition
+   of key abstractions, but sacrificing completeness. If you have time for only
+   the Reader's Digest version, this is the document to read.
+
+Leigh had mentioned XML'izing some of our resource stuff.
+That's the plan.  See the first few pages of this doc
+(the back is just long examples).
+ o RSpec.
+    http://www.cs.princeton.edu/~llp/rspec-draft-v0.4.pdf
+
+    Expands upon the Resource Specification (rspec) section of the full
+    Architecture document.
+}}}
+
+-- Main.EricEide - 02 Nov 2007
+
+=== Notes from the Meeting ===
+
+'''Who/When'''
+
+   * attendees: Jay, Rob, David, Mike (phone), Leigh (phone), Eric (@3:40 PM)
+   * start @ 3:00 PM
+   * end @ 4:35 PM
+
+'''Brief GENI Q&A'''
+
+   * '''The GMC''' defines the GENI API, including interfaces to GMC, CM, SA, MA,
+     etc.
+      * There may be many implementations of the GMC.
+   * MAs are owners of resources.  There will be multiple SAs (i.e., EU, 
+     NSF-GENI, etc.).
+      * Parts of the MA interfaces may be private.
+   * What is Utah?  Utah is an owner/operator of our resources (an MA), as 
+     well as a portal.
+      * We are also an SES (slice embedding service), but that's part of being
+        a portal.
+      * We will need to choose to make parts of Emulab available as individual
+        components, or as one big aggregate component, or potentially both!
+   * Do we need to implement the whole GENI architecture (all the interfaces)
+     so we can interact (federate) with other prototype GENIs?
+      * Jay: we didn't promise interaction/federation in the proposal.
+      * Jay: we want to formulate our own APIs before federating.
+      * Jay: relates to Emulab federation; perhaps could do both at once.
+      * The GENI docs form a hazy picture of what's needed; we can change the
+        docs and convince other people.  We '''will''' find things that need
+        changing.
+      * Desired: code, fast.
+
+'''How does existing Emulab relate to GENI?'''
+
+   * We could have a CM for each testbed PC, and a CM for networks that connect
+     them.
+   * Emulab could also be a component aggregate, which could talk to individual
+     CM interfaces on each PC/switch
+      * Rob: a complex configurable link '''is''' a component.  We would have a
+        frontend to switches and delay nodes.
+      * Making this distinction might be hard, if we do the aggregate CM in
+        terms of the node/switch/etc CMs.
+      * Jay: figure out how links have CMs later.
+
+
+'''Jay: what do we do first?'''
+
+   * Cluster pcs
+   * Virtual pcs
+      * Do we start with PlanetLab nodes today, using our portal?
+      * Do we layer GENI atop the NM; wait for PlanetLab?  Need to hack the PLC
+        code? 
+   * Programmable routers?  Not at first.
+      * NetFPGA: could do a simple thing where we just export access to the
+        hardware to a single user, let them program it... but not at first.
+      * jtw's routers: wait until he develops an NM for them, then use that.
+   * Wireless: 802.11, SDR
+      * Mike: "virtual access point component"?
+      * Maybe phase in the more "advanced" wireless support (i.e., all the
+        virtualization).
+   * Jay: just deploy a wide-area Emulab?
+      * Only a few things are missing
+      * It would be useful in the short term to people
+      * Must send HW around the world
+   * HomeNet
+      * This gets us into federation...
+      * ...unless we deploy this stuff ourselves: a Utah HomeNet
+   * Sensors: yes
+   * StarGates: no
+   * Cisco routers: no
+
+'''Security'''
+
+   * Chains of certs of auth/perm
+   * We need to do multiple levels, but said we wouldn't (why is it hard?)
+      * Jay: policy aspects are hard; but mech?
+      * side issue: multiple leases: one for slice, one for ticket (ugly).
+      * Could exploit slice lease times for revocation, perhaps (why do chains
+        make revocation worse?) 
+         * Eric: hard because must walk up the chain?
+         * Caching midchain hurts, because revocations must be pushed to root
+
+'''Action items'''
+
+   * Mike: understand GENI's "virtual" abstractions and how they relate
+      to our stuff, especially in terms of wireless
+      * e.g., "virtual access point"
+      * Are some of our abstraction just "handy bundles" of resources?
+   * Straighten out the security
+   * David: figure out the "NodeManager thing", vservers, etc.
+      * Presumably we run the PlanetLab Node Manager, but...
+      * Do we run PLC, or do we have ELC?
+   * Leigh: figure out why we're unfaithful to the current standard way of
+     making XMLRPC servers; SOAP/WSDL stuff too.
+
+-- Main.EricEide - 02 Nov 2007<br/>
+-- Main.DavidJohnson - 06 Nov 2007
+
+
+