wiki:GENIRacksHome/ExogeniOpenQuestions

Version 1 (modified by lnevers@bbn.com, 13 years ago) (diff)

--

These are numbered questions sent to exogeni-design@geni.net; discussions are captured to track resolution. Questions are crossed out when answered. Person closing a question should adding his/her name to the question with a brief explanation. Any document that is referred to with a URL is attached to the page for historical reference. Following are notes attributions:

AS: Adam Slagell           CE: Chip Elliot         IB: Ilia Baldine             JS: Josh Smift         NR: Niky Riga
AH: Aaron Helsinger        CG: Chaos Golubitsky    JC: Jeff Chase               LN: Luisa Nevers       VT: Vic Thomas
BV: Brad Viviano           HD: Heidi Dempsey       JM: Jonathan Mills           NB: Nick Bastin        TU: Tim Upthegrove

GPO ExoGENI Questions

  • 1. Does ExoSM speak GENI API? (nriga)
    <NR> Yes, ExoSM is just like any Orca SM running in a rack and can
         be thought as a GENI AM that can make reservations in racks
         as well as provide the network connecting resources on different
         racks. Per Ilia comments ExoSM can also give an experimenter
         resources from only one rack by making a bound request that
         bounds all resources to specific rack. My understanding is
         also that all topology information is available to the
         experimenter through the GENI API (listresources) only through
         the ExoSM and not through the rack-local Orca SMs.
    
  • 2. Can you describe the ExoGENI software stack a bit more in the teleconf (Figure 7)? (ahelsing)
    • 2a. Is the AltG API the same as the Orca XMLRPC API at the SM? (ahelsing)
      <IB> Yes.
      
    • 2b. Can you draw the software stack for the worker nodes in the same style as Figure 7 for comparison? (ahelsing)
      <IB> Worker nodes are either turned off (booted and installed using
           xCAT when needed) or run Centos 6.1 with OpenStack worker node
           configuration.
      <JC> The cloud worker nodes also need a cloud node manager installed.
           This requires minor modifications for NEuca.  This is the thing
           that lets us create multiple interfaces on VMs and stitch them
           to other VLANs.
      <JS> Do we understand what controls how many nodes are bare-metal and how many
           are available for VMs? Can this be adjusted on the fly? By whom?
      <HD> The allocation question is a policy question, the mechanism should be defined later - both postponed.
      <HD> Josh to get software stack for Worker node.
      
      
  • 3. Is Eucalyptus or OpenStack used for the compute resources? (chaos)
    <IB> OpenStack
    
    • 3a. If OpenStack is being used, what testing or analysis convinced you to choose OpenStack? (chaos)
      <IB> We've done performance comparision. OpenStack instances boot
           significantly faster (orders of magnitude) due to the use of
           COW for boot images. We can also see a path to making VM
           migration work between ExoGENI sites with OpenStack (could not
           figure it out with Eucalyptus).
      
  • 4. When will ExoGENI racks support xCAT-based bare-metal node allocation? (chaos)
    <IB> My hope by GEC13
    
  • 5. How do bare-metal images get vetted? (hpd)
    <IB> TBD
    <HD> Same as S.27, closing this one, Adam will follow up.
    
    • 5a. Given that VM images are unvetted, why vet bare-metal images?
      <IB> Security concerns. Also bare-metal images are harder to prepare.
           Mistakes will mean users occupy fairly limited bare-metal
           resources just learning how to boot them.
      <HD> Same as S.27, closing this one, Adam will follow up.
      
  • 6. Can we have more detail about disk images: (jbs)
    • 6a. How are central images selected? Is there a central repository? (jbs)
      <IB> For vetted images for bare metal. There may also be a small
           informal repo for sample VM images.
      <JC> For 6a-6b-6c.   ImageProxy can fetch images given a URL.  So
           people can put their images anywhere.  We have software (pod)
           to make it easy for users to upload images and share them.
           The user interface is a little rough, and it is not quite
           deploy-ready, but it could be used.   Ilia's concern (I think)
           is that we don't have budget to run and manage a repository
           server with a lot of disk.  But GPO could certainly host it.
      <AH> 13) Building new VM images takes work. (Q6)
           You have to add NEuca and maybe something OpenStack? This was hard with
           Eucalyptus, but maybe it is easier with OpenStack? Their answer that
           this is documented elsewhere isn't terribly re-assuring (since the
           Eucalyptus documentation wasn't enough for Tom). Do we want to check
           their list of images? Have them add 1 or 2? Have them collect/edit
           documentation for this process?
      <CG> Well, OpenStack may be a lot better for this --- we simply don't know.
           IMHO, the right answer to "this is documented elsewhere" is, "great,
           then it should be easy for you to make a wiki page pointing to usable
           procedures elsewhere".
           Well, actually: i said that, and then thought about the RENCI integration
           of external documentation and internal for ORCA/NEuca, which i have not
           found all that readable when i've tried to use.  So maybe we'd rather
           have them duplicate the steps that an experimenter would use to create
           an image?  I'm not sure here.
      <JS> I predict that we aren't planning to host a repository server. Are we? If
           not, do we think that someone else is? Do we want to push RENCI to do that?
      <JS> Answer: RENCI has a central repository at http://geni-images.renci.org/images/,
           which ExoGENI will use too (or maybe a subdirectory, or some such). Images
           for that repository must be reviewed by RENCI, the GPO, or our delegate.
           All vetted bare-metal images will live here, and a small number of
           commonly-used VM images could be hosted here too. RENCI or GPO will put
           together a nicer index page (it's currently just an Apache DirectoryIndex
           listing, with no comments or explanations)
      <IB> This is correct although as far as the bare-metal nodes are concerned
           the images will be cached in each rack and the booting will happen
           from there. I have put together a small page listing available VM
           images : https://geni-orca.renci.org/trac/wiki/neuca-images
      <JB> I've also rephrased some of the questions a bit from their original forms.
           6a. How are central images selected? Is there a central repository? 
           Answer: RENCI has a central repository at http://geni-images.renci.org/images/,
           which ExoGENI will use too (or maybe a subdirectory, or some such). Images
           for that repository must be reviewed by RENCI, the GPO, or our delegate. 
           All vetted bare-metal images will live here, and a small number of
           commonly-used VM images could be hosted here too. RENCI or GPO will put
           together a nicer index page (it's currently just an Apache DirectoryIndex
           listing, with no comments or explanations)
      <IB> This is correct although as far as the bare-metal nodes are concerned the 
           images will be cached in each rack and the booting will happen from there. 
           I have put together a small page listing available VM images :
           https://geni-orca.renci.org/trac/wiki/neuca-images
      
      
    • 6b. Are there default images hosted at RENCI? What are they? (jbs)
      <IB> We have a few on http://geni-images.renci.org/images/
      <JS> Answer: The exact images haven't been specified, but there aren't in
           principle any reason why we can't publish any images that we decide
           we want, within disk space limitations. We (GPO) will presumably use
           our rack to come up with some, probably focusing on modern and stable
           versions of Ubuntu and Fedora/CentOS.
      <IB> Yes and we encourage multiple locations (URLs/web servers) from which
           the images are served. A directory listing them can be stored in one
           place.
      <JB> I've also rephrased some of the questions a bit from their original forms.
           6b. Are there default images hosted at RENCI? What are they? 
           Answer: The exact images haven't been specified, but there aren't in
           principle any reason why we can't publish any images that we decide we
           want, within disk space limitations. We (GPO) will presumably use our rack
           to come up with some, probably focusing on modern and stable versions of
           Ubuntu and Fedora/CentOS.
      <IB> Yes and we encourage multiple locations (URLs/web servers) from which the 
           images are served. A directory listing them can be stored in one place.
      
    • 6c. Will RENCI also store some user images? (jbs)
      <IB> Only a few.
      <JS> Answer: RENCI will only store experimenter-created images if they've
           been reviewed (see 6a), but ImageProxy can fetch and use an image
           from any experimenter-supplied URL, and RENCI has software that makes
           it easy for experimenters to upload images and share them, although
           it's not quite deployment-ready yet.
      <IB> Yes. Duke team is working on POD (Persistent Object Depository) that
           can fulfill this role. I repeat that this is an optional component -
           a user can create an image and serve it from *any* web server.
      <JB> I've also rephrased some of the questions a bit from their original forms.
           6c. Will RENCI also store some user images? 
           Answer: RENCI will only store experimenter-created images if they've been
           reviewed (see 6a), but ImageProxy can fetch and use an image from any
           experimenter-supplied URL, and RENCI has software that makes it easy for
           experimenters to upload images and share them, although it's not quite
           deployment-ready yet.
      <IB> Yes. Duke team is working on POD (Persistent Object Depository) that can 
           fulfill this role. I repeat that this is an optional component - a user 
           can create an image and serve it from *any* web server. 
      
    • 6d. Will there be instructions for building custom images? (jbs)
      <IB> For VMs yes, although basically OpenStack, Eucalyptus and
           Amazon have pretty extensive guides on how to do that.
      <JS> Answer: RENCI will publish instructions for building VM images, and
           there are good general docs available from OpenStack, Eucalyptus, and
           Amazon too.
      <IB> Here are the current instructions:
           https://geni-orca.renci.org/trac/wiki/NEuca-guest-configuration
      <JB> I've also rephrased some of the questions a bit from their original forms.
           6d. Will there be instructions for building custom images? 
           Answer: RENCI will publish instructions for building VM images, and there
           are good general docs available from OpenStack, Eucalyptus, and Amazon too.
      <IB> Here are the current instructions: 
            https://geni-orca.renci.org/trac/wiki/NEuca-guest-configuration
      
      
    • 6f. Must the experimenter add NEuca? (hpd)
      <IB> NEuca-py tools *should* be added to the image such that post
           boot configuration (IP address assignment to interfaces and
           post-boot scripts) would be done. Without it, bare interfaces
           will still be created based on NEuca INI script generated by
           ORCA for the desired topology and the user would have to
           manually configure them.
      
  • 10. Can we have more information about how the IP Address proxy options in the table on p. 4 work? Do the proxies expose all ports or just ssh? (jbs)
    <IB> Right now only SSH. The plan is to add the ability for the
         user to ask to expose some port ranges in addition to that.
         It's on the todo list and is not complicated.
    <AH> 12) They plan to NAT access to VMs, meaning that experimenter resources
         are only available via SSH or maybe in future specifically requested
         port ranges. (Q10 from original list)
         I think we want to know more here, and clarify our concerns and desires.
         Perhaps those 'future plans' are enough, but we need to know more (like
         a schedule).
    <JS> 10. Can we have more information about how the IP Address proxy options   
         in the table on p. 4 work? Do the proxies expose all ports or just ssh?
         Ilia had said "Right now only SSH. The plan is to add the ability for the
         user to ask to expose some port ranges in addition to that. It's on the
         todo list and is not complicated."
         That sounds good; is there a timeframe for that?
         Just to make sure the goal is clear, the idea is that experimenters may
         want to run TCP or UDP services on their VMs, and make it possible for
         users to connect to those services via the Internet.
    <JS> Answer: The plan is to add this ability, it's on the to-do list, and
         it'll be done by the time the first non-GPO/RENCI racks ship in April.
         (Which of the options in that table are you planning to go with? Or
         will this be a campus-by-campus decision? If the latter, which will
         you recommend? We prefer (C), which seems safe enough if the racks
         are behind a campus firewall, which we assume they will be.)
    <IB> This is a campus-by-campus decision. We can deal with either B or C.
         If there are not enough public IP addresses, we have a proxy
         solution. If there are enough, they can be used as is.
    <JB> 10. In the IP Address proxy options in the table in section 2.1, at the
         top of page 5 do the proxies expose all ports or just ssh? 
         (Experimenters may want to run TCP or UDP services on their VMs, and
         allow users to connect to those services via the Internet.)
         Answer: The plan is to add this ability, it's on the to-do list, and it'll
         be done by the time the first non-GPO/RENCI racks ship in April.
         ISSUE: Which of the options in that table are you planning to go with? Or
         will this be a campus-by-campus decision? If the latter, which will you
         recommend? We prefer (C), which seems safe enough if the racks are behind
         a campus firewall, which we assume they will be.
    <IB> This is a campus-by-campus decision. We can deal with either B or C. If 
         there are not enough public IP addresses, we have a proxy solution. If 
         there are enough, they can be used as is. 
    <JB> Ok, that sounds good.
         One other question about this: The ExoGENI racks will not expect that they
         have a dedicated IP subnet for these interfaces, which they need to route;
         but will instead expect that they'll connect to an existing IP subnet (or
         a newly-created one, I suppose), which the campus will route, right? (That
         sounds fine; I ask because it came up when we were deploying the starter
         racks in Chattanooga and Cleveland, so it may come up with campuses too.)
    <IB> We don't require an entire subnet. A list of available IP addresses is enough.
    
    
    • 10a. Do all outbound connections work for all table options (jbs)
      <IB> Not clear about the question
      <JS> I think the question is: "For all the options in Table N (don't have the 
           number handy, but we should cite it), is it the case that there are no
           restrictions on outbound connections?"
      <JS> The original 10a said:
           10a. Do all outbound connections work for all table options
           I clarified that what we were getting at here was:
           For all three options in that table, is it the case that there are no
           restrictions on outbound connections?
           We assume not, but wanted to check.
      <JS> Answer: Correct, there are no restrictions; all outbound connections
           are permitted. (Although some could be blocked if we needed to for
           some reason.)
      <IB> We will not block any outgoing connections on the racks. We cannot
           say anything for the campus.
      <JB> 10a. For all three options in that table, is it the case that there are
           no restrictions on outbound connections?
           Answer: Correct, there are no restrictions; all outbound connections are
           permitted. (Although some could be blocked if we needed to for some reason.)
      <IB> We will not block any outgoing connections on the racks. We cannot say anything 
           for the campus.
      
    • 10b. How does the proxy work for OpenFlow? (jbs)
      <IB> I don't think they are related.
      <JC> Proxied IP connections go through the management net, so they
           don't touch the OF switch.
      <JS> I think our concern was: If the FlowVisor is reaching out to experimenter
           controllers through the proxy, does that raise any issues? (Relative to
           the alternative of "the FlowVisor connects to experimenter controllers
           directly" -- which may in fact be what happens, if it's on the head node.)
      <JS> Our concern here was: If the FlowVisor is reaching out to experimenter  
           controllers through the proxy, does that raise any issues? (Relative to
           the alternative of "the FlowVisor connects to experimenter controllers
           directly" -- which may in fact be what happens, if it's on the head node.)
      <JS> The original 10b said:
           10b. How does the proxy work for OpenFlow?
           I clarified that what we were getting at here was:
           If the FlowVisor is reaching out to experimenter controllers through the
           proxy, does that raise any issues?
           If outbound connections are unrestricted, and performance of the proxy is
           good, then this is probably not an issue. But we wanted to raise the
           question because it's a situation where dataplane traffic uses the
           management network, so if the proxy was expected to only have to handle
           experimenter SSH, that might not be sufficient.
      <JS> This is superseded by 10a and 10c: There are no proxy/firewall
           restrictions, and no performance issues, that are unique to OF/FV.
      <JS> 10b. If the FlowVisor is reaching out to experimenter controllers
           through the proxy, does that raise any issues?
           Answers: If outbound connections are unrestricted, and performance of the
           proxy is good, then this is probably not an issue. We should make sure to
           test this carefully with the initial GPO and RENCI racks, since FlowVisor
           can generate a lot of control traffic.  
      
    • 10c. What is the expected performance bottle-neck for proxying? (jbs)
      <IB> Packet forwarding is relatively cheap at reasonable rates. The
           bottleneck will be the connection to the campus network.
      <JS> This gets to 10c:
           10c. What is the expected performance bottle-neck for proxying?
           Ilia had said "Packet forwarding is relatively cheap at reasonable rates.
           The bottleneck will be the connection to the campus network."
           Just to put some numbers on this, the theory is that the connection to the
           campus network will not be more than 1 Gb/sec, and we think that the proxy
           can go at least that fast?
      <JS> 10c. What is the expected performance bottle-neck for proxying?                 
           Answer: We expect the connection to the campus network to be 1 Gbit or
           less, and that the proxy can go at least that fast.
      <IB> The answer is above - we don't think the head node will be the bottleneck. It will be the campus connection.
      
  • 11. Is ExoGENI software essentially Orca software? How do they differ? (hpd)
    <IB> Same
    <JC> The software is ORCA (and associated stuff like ImageProxy and
         NEuca), but it is configured in a specific way, so we just say
         "ExoGENI" when we're talking about that configuration.
    
  • 12. What happens to ExoGENI racks and/or rack functionality if RENCI suffers a network or service outage? (ahelsing: watch this, but Ilia agreed to make deployment choices we wanted)
    <IB> Should not be affected
    <JC> For 12, 12b.  Also, old actors cannot see new actors.  Currently
         the actor registry uses SSL connections.  If RENCI goes off
         the net then a site or SM will not be able to restart.  AMs/SMs
         that are running will not be able to refresh their lists, so
         they won't accept any new actors.   If the registry issued
         certs (easy with ABAC), then this problem would go away, but
         it would be harder to revoke...
    <JS> This contradicts 12a.
    <AH> 1) Question 12: RENCI is a SPOF in your design, due to the RSpec   
         conversion service and Actor Registry.
         It appears that a couple (minor?) changes would mitigate this risk. Let
         us know if we're off base here.
    
    • 12a. Will the absence of the RSpec/NDL conversion service mean RSpec-related requests will not work? (ahelsing: RSpec converter being duplicated on all racks)
      <IB> Yes. We can host alternative translators in a number of places
           if it is a concern. We can host a translator on every rack if
           needed and configure its SM to talk to that translator. It is
           a simple stateless web-service.
      <AH> 2) RSpec conversion service is a SPOF. (Q 12a from GPO list)
           I think we'd like them to try running it elsewhere as well.
              a) Make the URL a configuration item in racks
              b) Test running it on the head node, to ensure no performance problems
              or library inconsistencies
              c) Consider running a backup version of the service somewhere. GPO?
      <CG> I think Ilia said this service is stateless and there's no issue running
           it on the individual racks.  So i don't see any reason not to just run
           it on the individual racks, unless it's a serious resource hog.
      <JS> This contradicts 12.
           So that's not "no functionality will be affected". :^p  (I don't think it's
           particularly important to call him on this, just mentioning it as a
           warning to us to keep our eyes open. :^)
      <JS> I think we should ask them to have a translater for each SM, unless
           there's a significant cost to that (in which case we should ask them to
           clarify what the cost is).
      <AH> a) Please install the RSpec conversion service on all racks, and make
           the URL for the conversion service be a configuration parameter. Be sure
           to test the load on the rack head node, once this and the OpenFlow
           pieces are running there.
      <IB> No problems with 12 a or b - this is supported today and is a deployment-time decision. 
      <AH> 12a&b is there now? (RSpec converter URL is a config param and actors
           community on the rack among themselves fine on restart) Great.
           If you are comfortable with this deployment choice (run the RSpec
           converter on all racks), then please plan on it.
      <IB> 12a is there now because we have a way of statically specifying security
           associations between actors in a config file. The actor registry works on
           top of that filling in whatever is missing. So we can configure the ORCA
           actors in a rack to know about each other statically without relying on the
           registry and they will only learn from the registry about other racks.
      <AH> Sounds great
      
    • 12b. What impact will the lack of the ORCA Actor Registry have on racks? (ahelsing: answered questions satisfactorily)
      <IB> Everything will continue running. New actors will not be able to see old actors.
      <AH> 4) Actor registry is a SPOF. (Q 12b from GPO list)
           This is less worrisome. New actors would be cut off. Racks cannot
           restart successfully.
      <AH> 5) The actor registry shows topologies in NDL. Once Ad conversion works
           (GEC13 he says), we should ask them to include a link showing that in
           RSpec as well.
      <AH> b) Please ensure that the 3 Orca actors on a rack can communicate with
          each other after rack reboot without re-talking to the Actor registry.
          IE a rack should work as a stand-alone GENI AM even if RENCI is inaccessible.
      <IB> No problems with 12 a or b - this is supported today and is a deployment-time decision. 
      <AH> 12a&b is there now? (RSpec converter URL is a config param and actors
           community on the rack among themselves fine on restart) Great.
           If you are comfortable with this deployment choice (run the RSpec
           converter on all racks), then please plan on it.
      <IB> 12b is trivial since the converter service can be run anywhere and its
           location is a configuration parameter for the rack SM.
      <AH> Sounds great
      
    • 12c. Any other impacts? (ahelsing)
      <IB> Can't think of any.
      
  • 13. What would fail if the rack Orca XMLRPC interface were disabled? What does the Orca XMLRPC feature do? Is it critical to the rack functions or just another way to use it? (ahelsing)
    <IB> It is another way to use it. Nothing would fail, but we would
         like to keep it. It is integral to the actor (SM) so there is
         no way for it to fail independently.
    <JC> We may plan to add some new management functions through the
         XMLRPC interface, so the answer to this question might change.
    
  • 14. Define ORCA AM Delegation to a broker further---is it double delegated? How is it applied for local broker and ExoGENI broker? (nriga)
    <IB> Probably best to refer to
         https://geni-orca.renci.org/trac/wiki/orca-introduction
    <JC> Double-delegated, but this would be site policy under site
         operator control.  A site could reserve resources for local
         use by not delegating them.  For example, they could buy more
         nodes and reserve them for local use.
    
    • 14a. If delegation to broker is a deployment time decision, what is the plan? (nriga)
      <IB> Delegation must occur for things to work, what is decided is
           how much to delegate. I'd say start with 50/50 for compute and
           probably 80/20 for vlans (local/global)
      <NR> Resources at a local rack are delegated to *either* the local
           broker *or* to the ExoSM broker, i.e. the resources *are not*
           double delegated. The original split will be 50-50, i.e. 50%
           of compute resources, vlan tags etc, will be delegated to the
           local broker and 50% to the ExoSM broker. The percentage is
           configurable and each admin can decide on a different split.
           The reconfiguration probably requires changes in a couple of
           configuration files and a restart of some (??) software. Tom
           believes that this might be more complicated since the broker
           have to address problems with existing tickets.
      <AH> 7) ExoSM owns half the racks. We may end up preferring to go direct to
           the racks. (Q 14a)
           We should have them document the process of changing that allocation,
           maybe even try it once, to be sure this isn't terribly disruptive or hard.
      
  • 15. What will the flowspace look like for ExoGENI OpenFlow slivers? If the flowspace is based on VLAN tags, will this still be doable if the OpenFlow switch runs in hybrid mode? (hpd) (this is an adequate first cut answer and the use cases duplicate this - closing)
    <IB> Here are FlowVisor commands (for two ports one vlan slice):
           $ fvctl addFlowSpace 00:c8:08:17:f4:a6:6a:00 10 "in_port=23,dl_vlan=151" "Slice:ilia2=4"
           $ fvctl addFlowSpace 00:c8:08:17:f4:a6:6a:00 10 "in_port=24,dl_vlan=151" "Slice:ilia2=4"
    <JC> The term "hybrid mode" is not well-defined.
    <AH> 11) The use of OpenFlow vs VLANs, and the capabilities of the switches,
         seems an open and messy question. Josh/Niky/Nick/? need to follow up
          probably.
             - implications of hybrid mode
             - way to do an OpenFlow onramp
             - options instead of a NOX controller per VLAN
             - ways to use OpenVSwitch to do clever things
             - ...
    <JS> This is what I expected, and should work fine, although we haven't
         personally tried it much. We could, when we get bamboo up and running again.
    <JS> Does he mean that we haven't defined it well, or agreed on a definition,
         or something? Or that we don't know for sure what *IBM* is going to implement?
         I think we have a good definition of "hybrid mode", although the
         definition is different on HP and NEC switches, than on what we think the
         IBM switches will do. But if he just means that we don't yet know for sure
         what IBM is going to do, then yes.
    <JS> Do you mean that we haven't defined it well, or agreed on a definition, or    
         something? Or that we don't know for sure what *IBM* is going to implement?
         I think we have a good definition of what we think we mean by "hybrid
         mode", although the definition is different on HP and NEC switches, than
         on what we think the IBM switches will do. But if you just mean that we
         don't yet know for sure what IBM is going to do, then I agree that this is
         an area with some question marks.
    <NB> The definition is exactly the same, for this switch, between NEC and
         IBM (same hardware, same software).  The fact that this switch is
         different from other NEC switches is besides the point.  In an
         OpenFlow world vendors are free to decide what they specifically mean
         by the word hybrid - all that hybrid means is that there is an
         openflow datapath instance and non-openflow instance on the same
         hardware, but how those instances interact is left to the vendor.  The
         two most common implementations of a "hybrid" mode are:
          * VLAN-based hybrid mode - the switch handles all traffic tagged in a
         certain VLAN with instructions from the openflow instance.  This often
         puts limitations on VLAN and QoS handling within the openflow instance.
         * Port-based hybrid mode - you literally just "slice" the switch so as
         it if were more than one switch.  Traffic is divided between
         non-openflow and openflow instance based on what port it comes in on
         or goes out on.
         In both cases transitioning the boundary between the openflow and
         non-openflow datapaths is an implementation detail left to the vendor.
         The IBM switch actually supports both modes currently, but the
         non-openflow datapath in hybrid mode is incapable of anything more
         than L2 MAC learning.
         It's probably also worth mentioning that on this switch, while you can
         create your openflow instance with an id of 1 to 16 possibly leading
         you to believe that you could create up to 16 openflow instances, you
         cannot - you can only create 1 - if you make a new instance, it will
         replace the old one (per NEC).
    <IB> We must be talking about different switches.
         The BNT switch we tested and is in our specs is a 10G/40G 48-port switch.
         NEC does NOT have it yet - I spoke to them about it.
         The NEC switch at GPO is not a BNT switch, since it is 1G/10G and BNT told
         me they do not have a 1G/10G implementation yet.
    <NB> The BNT is an NEC PF 5820.  My comments apply to that switch (not
         other NECs that implement different hybrid modes), and of course to
         hybrid mode in general (just to make sure we were all on the same page
         about what was generally available).
    <IB> The BNT switch I tested cannot do VLAN based OpenFlow (yes, you actually
         configure one VLAN to be OpenFlow, but a VLAN is used only as a port-grouping
         mechanism; its tag has no meaning). The only mode the BNT switch supports is
         port-based separation (and right now all ports have to be on that vlan; hybrid
         mode is coming).
    <JS> So, just to (try to) close the loop on this, all I originally wanted to
         address was Jeff's comment
    
           15.  The term "hybrid mode" is not well-defined.
    
         and my belief is that we do in fact understand what "hybrid mode" means,
         even if we're still not entirely on the same page about whether the IBM
         switch is in fact a NEC PF 5820, or something else.
         Jeff, do you think there's still an open issue here about hybrid mode not
         being well-defined, or are you happy?
    <JC> I was simply observing that there is no specification for "hybrid mode".
         I just want to be sure we define our terms.   We're all in    agreement
         about that, right?  Nick said something about "different hybrid modes".
         As I recall, the original question was:
         15. What will the flowspace look like for ExoGENI OpenFlow slivers? If
         the flowspace is based on VLAN tags, will this still be doable if the
         OpenFlow switch runs in hybrid mode?
         I responded "hybrid mode is not well-defined" because I did not understand
         the second part of the question.  If the question is still live, could I ask
         you to restate it more concretely?  There seems to be some concern behind it,
         and I'm not sure what that concern is.
         More broadly, we're still trying to figure out what the implications are of
         BNT's hybrid mode, and how to use it.  I said something about that in my e-mail
         to this list on 1/12.  I said:
         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.
    <NB> The answer in this case, given different hybrid modes, is generally thus:
         * If a switch implements a port-based hybrid mode (basically
         splitting the hardware into two switches along physical boundaries),
         then the openflow datapath is usually fully capable (with whatever the
         ASIC supports anyhow), which means that you can slice on VLAN tag in flowvisor
         * If a switch implements a VLAN-based hybrid mode (where the
         discriminant to which software path controls the forwarding is the
         VLAN tag) then generally the openflow datapath is *not* permitted to
         match on or modify VLAN tags, which means that you cannot slice on
         VLAN tag in flowvisor.
    <IB> For the switches we have picked the hybrid mode is port-based, we should have
         no problems slicing on VLAN tag. I tested it on the existing implementation
        (all ports had to be in OpenFlow mode).
    <NR> And just to close the loop on this, this was exactly our concern; whether the FV will be
         able to see/modify VLAN tags when the switch is running in hybrid mode.
         It sounds like the switches that are provisioned for the racks will support port-based
         hybrid mode and thus will allow you to create slivers in the FV based on VLAN tags.
         However, it is probably good to keep this in mind when you are talking with the vendor
         to ensure that this will be possible in the new firmware that will support the hybrid mode.
    <JS> Hmm, really? We haven't tried this, but I had thought that something like
         this would work: Say you've got a VM server, which provisions a VM to each
         of two experimenters, and gives each of them a virtual dataplane interface
         on a different VLAN, such that packets leaving the VM are tagged with that
         VLAN; but those virtual interfaces share a physical interface, which is
         connected to a hybrid-mode switch...
         ...Ah, ok, right: So if you want to slice by those VLAN IDs in FlowVisor,
         that port on the switch has to be an *access* port, in an OpenFlow-
         controlled VLAN, so it doesn't strip off the VLAN tags as they come in,
         and sends the tagged packets off to the FlowVisor. This is what you get
         for free with a pure OpenFlow switch; and you can do it on an NEC IP8800,
         but we think you *can't* do it on an HP. (And I don't think we've tested
         performance on the NEC, have we?)
         Anyway, probably not relevant to ExoGENI, with port-based hybrid mode;
         apologies for the tangent. :^)
    <NB> Just to continue this tangent for one email more...
         The HPs can do this, it's what they call aggregation mode.
    <JS> Rephrasing the question: If the general model is that the flowspace
         is sliced based on VLAN tags, will this still work if the OpenFlow
         switch runs in hybrid mode?
         Answer: Yes, this will work, because in port-based hybrid mode, each
         port will either be OpenFlow-controlled or not, and the OF-controlled
         ones will not be part of a VLAN, they'll just be part of a datapath.
         (Note that this might *not* work, however, in VLAN-based hybrid mode,
         because then you've got VLAN tags within a VLAN. This can probably be
         made to work, but it may require additional/different configuration.
         Shouldn't be an issue, but we should keep it in mind in the unlikely
         event that something changes from what we expect about how the switch
         does hybrid mode.)
    <IB> Our BNT/IBM switches will support port-based hybrid mode. We think it
         will work.
    <JB> 15. If the general model is that the flowspace is sliced based on VLAN
         tags, will this still work if the OpenFlow switch runs in hybrid mode?
         Answer: Yes, this will work, because in port-based hybrid mode, each port
         will either be OpenFlow-controlled or not, and the OF-controlled ones will
         not be part of a VLAN, they'll just be part of a datapath.
         (Note that this might *not* work, however, in VLAN-based hybrid mode,
         because then you've got VLAN tags within a VLAN. This can probably be made
         to work, but it may require additional/different configuration. Shouldn't
         be an issue, but we should keep it in mind in the unlikely event that
         something changes from what we expect about how the switch does hybrid mode.)
    <IB> Our BNT/IBM switches will support port-based hybrid mode. We think it will work.
    
  • 16. In figure 1 (ExoGENI Rack overview), how do you expect the Dataplane link to Campus OpenFlow network to be set up and configured? Will it require manual setup? Are there any implications? Do we expect FOAM to be used to request and approve these OpenFlow connections? (hpd) (this is an adequate first cut answer and the use cases duplicate this - closing)
    <IB> Affirmative on FOAM. We assume it is a connection (10G or
         downconverted to 1G) to some OF-enabled campus switch.
    <JC> This link is optional, and it doesn't have to go to an OF
         network.  It can be used to pipe campus VLANs into the switch,
         for interconnection with slices under OpenFlow control.
    <JS> I'll poke at the details of this more in my use case follow-up.
    
  • 17. Is Internet2 Dynamic Network System (DYNES) supported? (hpd)
    <IB> DYNES uses ION (dynamic circuit service on Internet2). ION is
         supported because we support OSCARS - the software behind ION.
    
  • 19. Stitching support:
    • 19a. Confirm ION/Sherpa/OSCARS all comes through the RENCI SM? (ahelsing)
      <IB> Yes
      
    • 19b. Can I connect to racks without the RENCI SM? (ahelsing: but see g)
      <IB> If you have external stitching tool
      
    • 19c. RENCI SM and other racks coordinate via ORCA private interfaces? (ahelsing)
      <IB> Yes
      
    • 19d. What resources are allocated to the ExoSM? (jbs)
      <IB> See 14a plus all the intermediate network providers (LEARN,
           BEN, NLR, I2, ANI, NOX etc)
      <JC> 'Allocated' is a strange term to use.  "visible" would be a
           better term.
      <JS> I think there's a difference between "visible", in the sense of "the ExoSM
           is aware of them", and "allocated" or "delegated", in the sense of "ExoSM
           manages them, and the local SM doesn't".
      
          Side note: Is there any chance we can reconcile terminology here, or are
          we going to be talking about "GENI AM, by which we mean ORCA SM", and
          "ORCA AM, which is not a GENI AM at all", and so on, for the rest of this
          project? :^\
      <AH> We should have them document the process of changing that allocation,
           maybe even try it once, to be sure this isn't terribly disruptive or hard.
      <JS> I think we can assume that they'll document this, plan to try it out,
           and pester them if they don't document it. I think we're set here.
      
    • 19e. Can experimenter go to racks separately for compute and then to the ExoSM just for the links? (hpd)
      <IB> This mode is not supported
      <JC> This is not supported BECAUSE it means that an AM could be
           asked to operate on the same slice by two different SMs/controllers,
           and ORCA does not support this.  (It is a limitation we probably
           should not have.)
      
    • 19f. Who is writing the Internet2 AM? (hpd) (RENCI wrote the code already - closing)
      <IB> The code is already there, we need a physical connection (at
           StarLight would be best).
      
    • 19g. Does Single rack manifest expose external VLAN tag so I can stitch? (ahelsing: they'll do this by GEC13)
      <IB> We'll work on it. We can add an external-facing port as part
           of an internal slice.
      <AH> 1) They do not currently support stitching resources you get from a
           single rack. (Q 19g)
           We should ask them to:
             a) expose the VLAN tag they have allocated in the manifest
             b) accept a VLAN tag allocated elsewhere in their request, and use it if
             it is available (else fail)
           I think this is something we want to get them to do. Definitely (a),
           even better (b). Ilia said they would work on it. I want to press for it
           to be done by GEC13 and in the initial racks.
      <AH> 19g) Please support stitching of rack resources by GENI tools for this 
           year's racks - ideally by GEC13.
           Specifically:
           - More important: Support a request to a rack for compute resources and
           a VLAN out, where the resulting manifest specifies the allocated VLAN,
           such that this can be stitched to the next aggregate in the network.
           - Less important: Accept a VLAN tag in a request for a VLAN that the
           next aggregate in the network has allocated, and try to use it at that
           rack if it is available (failing the request if it is not available is
           expected at aggregates that do not support VLAN translation).
      <IB> 19g.1 will be available.
      <AH> Do you think you'll have this circa GEC13? April? September?
      <IB> 19g.1 We will try to get it by GEC13. It's not that much work.
      <AH> Sounds great
      
      <IB> 19g.2 less likely to be available soon (please show me an RSpec request for this).
      <AH> 19g.2: The closest I have is the sample requests to the PG aggregate in
            gcf/examples/stitching/libstitch/samples:
             http://trac.gpolab.bbn.com/gcf/browser/examples/stitching/libstitch/samples/utah-equest.xml?rev=795c50b86faf82f0fa8696d80005424e0b2089af
      
            Assume you were specifying a VLAN tag to the PG AM to stitch to ION:
            Within the stitching extension, at hop 3, you would specify both
            vlanRangeAvailability and suggestedVLANRange of the allocated VLAN tag.
            Presumably you could do something additionally in the <interface>
            element within the <node client_id="left">
            As I said, this is lower priority.
      <IB> 19g.2 we'll see
      <AH> Sounds great
      
  • 20. Authorization: Orca APIs use what? Same as GENI? To what extent is this not exactly the same policies as the GENI APIs?(see TM comment below)
    <IB> Almost same as GENI. Some validity checks are disabled.
    <JC> I think Ilia interpreted this as a question about "Alt-G".
         Maybe it was.  As for the internal APIs: In the ExoGENI
         configuration every ORCA AM will trust every registry-approved
         SM to validate a request before passing it to the AM.  AMs
         only check that the SM is registry-endorsed.
    <AH> 6) Orca authorization (for their private APIs) apparently use similar
         checks to GENI. (Q20)
         We should ask exactly what they changed, to be sure it isn't worrisome.
         I don't have any real worries here though.
    <TM> This item can be closed. The ORCA APIs will effectively provide the same 
         authorization as the GENI APIs by accepting identity certificates from 
         known and trusted certificate authorities, namely the GPO and ProtoGENI 
         CAs. While the GENI AM API requires credentials, there is no impediment 
         to getting those credentials for any registered user today. It is nonsensical 
         to require ORCA to build out additional infrastructure to require and honor 
         those credentials through their own APIs.
    <JS> Hmm, so I have a question about this: If having a GENI user certificate is
         all you need in order to get an ExoGENI sliver via the ORCA API, does that
         mean that you wouldn't necessary have a GENI slice that contains your sliver?
         If that's not correct, and you do have a GENI slice: Where does that GENI
         slice come from?
         If that is correct, and you don't have a GENI slice: Is that ok, or will
         it cause other problems? (e.g. with things that assume that any allocated
         resource is part of a sliver, which is part of a slice, which is owned by
         a user -- if there's no slice, that chain may break down.)
    <IB> It is correct that in that case there is no slice as far as SA is concerned. 
         This is where we get into the 'what is a sliver and what is a slice' argument. 
         What ORCA creates are in fact slices, not slivers. We just call them slivers 
         when GENI AM API is invoked. 
         I would say that anyone who cares about this, should use GENI AM API on ORCA SMs
         and these problems go away. You get weaker stitching in that case. Tradeoffs, as usual.
    <JC> We agree on a base principle: ExoGENI will allocate resources only to registered 
         GENI users who have been granted rights by a GENI-approved trust root to allocate 
         resources on GENI.
         Is that enough of an answer to close down this item?
         In the short term, if the only way to get proof that a given user is authorized to 
         allocate resources on GENI is for that user to obtain CreateSliver rights to some 
         slice (any slice) on GENI, then that is what we will do.  Once we have that proof, 
         we can use it in various ways.
         Ideally there would be better ways to get that proof, and so the answer may change 
         if and when better ways become available.
         As for "GENI slice that contains your sliver", well...I think it's a long discussion 
         what that means, exactly.  Please, let's not have that discussion now. 
    TO-ADD MORE LN
    
  • 21. What is the Actor registry used for? Is this an alternative non GENI way to authenticate inter-rack communications? (hpd)
    <IB> Yes, it is a way to manually approve actors joining into ExoGENI. There is no GENI way to authenticate inter-rack communications.
    
  • 22. OpenFlow rack as onramp: when will this be supported? (jbs)
    <IB> Jeff Chase wants it yesterday. Realistically some time this year.
    <JC> There is an MS student (Ke Xu ... Jessie) working in this area
         at Duke.  We are not sure what she can do yet.  We might be
         asking her to try some stuff on the GENI OF resources.   I
         think on-ramp is easy, but OpenFlow has to work.  That's the
         hard part.
    <JS> I've heard the phrase "onramp" a couple of times, but don't know exactly
         what it means. Is it just use case 4? If not, is there a definition somewhere?
    <JC> 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.
    
    • 22a. Are there conflicts between FOAM and Orca mechanisms to create FlowVisor rules? (hpd) This question is being replace by the new GPO question 29.
      <IB> Hopefully FlowVisor will flag it.
      <JC> No.
      <AH> 9) Orca uses FlowVisor directly, opening up the possibility of conflicts
           between FOAM and Orca.
           The solution would be for Orca to use FOAM, once a pluggable API there
           exists, but it doesn't yet. ''We need to keep an eye on this.''
      <AH> I'm pretty sure it won't, which is a point in favor of ORCA -> FOAM -> FV
           rather than ORCA -> FV + FOAM -> FV.
      <JS> I'm pretty sure FlowVisor won't -- in particular, there's nothing
           fundamentally wrong with creating flowspace rules in FV that describe
           overlapping flowspaces. But you usually don't get what you want,
           especially if "you" are multiple experimenters who aren't even aware of
           each other's slivers.
      
           To my mind, this is a point in favor of having ORCA talk to FOAM, rather
           than having both ORCA and FOAM talk directly to FlowVisor.
      
           That said, it's certainly possible for both ORCA and FOAM to find out the
           flowspace on the FlowVisor, and to use that to avoid allowing people to
           have overlapping flowspace. But they have to actually do that explicitly.
      
  • 23. A few monitoring items are marked incomplete: Dates& plans? (hdempsey)
    • 23a pubsub event feed to GMOC (is GMOC ok with your plan?): (Chaos is tracking in GST 3369)
      <IB> GEC13
      <CG> Per Jon-Paul, GMOC originally proposed the pubsub model and
           will support it, details TBD.
      <CG> FYI: GMOC has agreed to send someone to tomorrow's monitoring call who
           can talk about the pubsub proposal they made for RENCI.  So we should
           know more by then about what has been proposed for slice monitoring
           data submission (question 23A), what the timeframe is, etc, and ideally
           that will lead to us having a more intelligent opinion about whether we
           like it.
      <CG> 23a. Submitting per-slice/sliver relational data to GMOC:            
           This has been discussed a little bit on the monitoring@geni.net list.
          It sounds like both ExoGENI and GMOC can provide support to get an
          approach involving XMPP's pubsub protocol working.  GPO will work with
          GMOC to make sure that the per-slice/sliver data which is stored can
          be used across experiments with ExoGENI and non-ExoGENI pieces.
          So i think we are all set on this question.
      <IB> I think we're all on the same page here.
      <CG> I want to follow up again on these to make sure we are working from   
           the same assumptions.  If ExoGENI and GMOC can negotiate an approach
           using pubsub or direct nagios communication, and both sides can do the
           respective work to get that interface running, that's fine with GPO.
           Our desire here is just to have some useful data be submitted from each
           rack to GMOC (or polled from each rack by GMOC) reasonably often.
           However, the interface which already exists is the XML-over-HTTPS data
           submission API developed by GMOC.  This API is active and usable for
           time-series (operational measurement) data right now, and GPO and GMOC
           are working to make sure it will be ready for relational data (e.g. slice
           metadata) within the next couple of months.  ExoGENI racks will need to
           interface with these APIs as a minimum offering.
           Again, if ExoGENI and GMOC do the work between you to support something
           you both like better, that's very likely to be a fine substitute.
           Otherwise, the XML-based API is a "least common denominator" solution,
           and RENCI should submit data using it.
      <IB> My main concern is GMOC's work so far has been outside of the GENI I&M 
           framework which may or may not be a good idea. I'm attempting to bring 
           everything under one roof by using the XMPP bus that will also be used for 
           GENI I&M to submit GMOC-relevant data and see if it flies.
      <HD> Ilia,
           This is not going to work.  The GENI I&M framework is not fully implemented 
           yet,  and may not be for considerably longer than it takes for us to field 
           the racks this year.  The GMOC interface predates the I&M framework, and has
           already been in use in the mesoscale for well over a year.  No GMOC-relevant 
           operations data should be submitted via I&M, which is specifically for 
           experimenter-relevant data.  The GMOC has been part of the I&M project in order
           to make sure that it was possible to distribute operations data into the I&M 
           framework if there was demand for that among experimenters.
           It may be that the GMOC evolves their interface to be more like the I&M interface 
           for simplicity and ease of programming, especially for the aggregate providers.  
           However, we can't count on that for Spiral 4.
      <CG> To clarify: we have no objection to the use of XMPP per se --- GMOC's
           generic interface for data submission uses XML sent via HTTPS, but, if
           data is collected or sent some other way, that's fine.  As Heidi said, we
           just want to see operational data transmission from each rack to GMOC's
           operational monitoring database during this spiral.  I believe using
           the existing data submission API is the most straightforward way to do
           that this year.  However, if the anticipated benefits of XMPP outweigh
           the extra work, and the work can be done this spiral, that's fine.
      <IB> There are enough commonalities between what GMOC wants and what the 
           experimenters want that their work and I&M will converge.
           By March we should have an XMPP bus with GENI authn/authz available 
           (as part of our IMF project with Harry) via which we should be able 
           to make data available to GMOC and at the same time make it available 
           to anyone else with proper GENI credentials.
      <CG> I can think of two concerns about using this approach in the short term:
       1. "Proper GENI credentials" sounds to me like an experimenter being
          able to get access to his own experiment's data.  That's not the
          same thing as operational monitoring data [1], which isn't going
          to be per-sliver, but rather might contain some amount of metadata
          about all slivers, and information which is not per se about slivers.
      <IB> You're assuming experimenters only need access to data from their own 
           slices. I disagree. There are circumstances where an experiment in 
           GENI means looking at other experiments.
      <CG> Do you have an implementation for allowing a non-experimenter
          operations group like GMOC read-only access to broader monitoring
          data using a GENI credential?
      <IB> Working on it.
      <CG>  2. On the GMOC end, there needs to be code to use this XMPP interface,
          acquire data, and put it into some operational database at
          http://gmoc-db.grnoc.iu.edu/.  If this is going to be done using
          a new interface rather than an existing one, someone will need to
          write that code.
      <IB> We have example code that can get data from Pub/Sub. 
      
    • 23b thing with U Alaska from individual VMs: VMI would be nice to have, but is not critical for rack design, so i think we are satisfied with what we know here. (Chaos)
      <IB> Need to ask them
      <CG> Question 23B says "thing with U Alaska from individual VMs".  What does
           this question mean, and who asked it?  I am pretty sure it was not me,
           though a lot can happen in two days
      <CE> I believe that RENCI wants to use the U. Alaska "virtual machine
           introspection" software to provide monitoring of what's happening
           inside individual VMs (based on my quick read of the design doc).
      <CG> Ah, thanks Chip.  That's helpful, and, indeed, i see this in section
           4.3 of their proposal: <<Proposal text not enclosed here>>
           To me, this sounds useful if they can do it, and not critical if they
           can't.  Who put it on our list of design review questions, and what is
           your concern about it?
      <HD> Aaron put it on our list and Ilia had no more information about it at
           this point--I think Aaron was just pointing out that the information
           about it was incomplete in the document, which is true.   I've talked
           to Brian from U of A a few times about the VM introspection software
           and think he would be a good collaborative addition to the team if he
           and Ilia work this out.  As you say, it won't be critical if they don't.
      <AH> I put it on the list, and I just wanted a date. They said, in not so
           many words, 'we want to use this'. So I wondered when.
      <VT> The VMI project has a milestone to demonstrate VMI in a Eucalyptus
           cluster environment at the March GEC.  They are working with Renci on
           getting this technology into Eucalyptus clusters that federate using
           the Orca framework (to be demonstrated in July).
      
    • 23c Nagios interface to GMOC (is GMOC ok with your plan?): (Chaos, GST 3369)
      <IB> I don't know if GMOC is fully OK with it, but we prefer Nagios to the homegrown solution.
      <CG> We don't yet know what will be doable for GMOC.  Mitch McCracken,
           the GMOC staffer who maintains the time-series data submission API,
           will be on our monitoring call tomorrow afternoon.  If you or Jonathan
           Mills or someone else from RENCI would like to be on that call and talk
           in more detail about what you'd like to do, what GMOC would need to do
           to support it, and why you prefer it, that would be a good next step.
           Mitch is new to maintaining the API and coming up to speed, so we won't
           make any decisions on the spot, but it would be a good forum for sharing
           information and understanding a bit better what you'd like to do.
           Let me know if you need more information about the call --- i know at
           least Jonathan has attended it before.
      <CG> With GMOC's Mitch's permission, i asked RENCI to send someone to the
           Friday call to talk about operational time-series/event? data submission
           (question 23C).  Mitch's short answer was that he probably wants something
           more centralized than whatever RENCI is proposing, but he's interested
           in understanding more about what RENCI actually wants, and so am i,
           so hopefully they will show up and talk about it, and, again, we can
           use that to figure out whether we like their answers.
      <IB> Jonathan Mills (who was present at the review) also attends the monitoring calls.
           He is in charge of modifying Nagios to our needs.
      <JM> Yes, and I am planning to attend the next ExoGENI monitoring call.
      <CG> At the monitoring call, Jonathan and Mitch agreed that it would
           be easy for RENCI to submit data from Nagios via the GMOC
           time-series data submission API.  They have started working
           on this on monitoring@geni.net.  I am satisfied that there is
           general agreement about what to do.
      <CG> 23c. Nagios interface to GMOC:                                               
           This has also been discussed on monitoring@geni.net, and the consensus
           here is that ExoGENI and GMOC will work together to write a stub
           which sits on each rack's Nagios aggregator, and submits information
           from Nagios's status.dat file to GMOC via some data exchange format
           (probably the GMOC data submission API, but if ExoGENI and GMOC prefer
           something different, that is fine).  This sounds like it should not be
           a lot of work beyond what has already been done to get Nagios working
           on the racks, and it's already being worked on.  So that's great too.
      <IB> I would suggest using the same XMPP pubsub mechanism as is used for
           manifests. They will also have access to the browser interface in Nagios.
      <CG> As long as each rack is submitting its own operational time-series data
           directly to GMOC, i think whatever mechanism is easiest for Jonathan
           and Mitch is fine.  Since operational data might be used to help during
           an outage, we do want to make sure as much data submission as possible
           continues to work during an outage.
      <JM> I have one thing to add, as an alternative way of getting the information
           out of Nagios itself, which is to directly query the LIvestatus broker.
           Livestatus is a Nagios broker module which can be queried in various ways.
           Broker modules are loaded into Nagios when the daemon launches, and thus
           they have direct access to its internal memory tables.  Queries in this
           manner are the fastest because no intermediate action occurs (for instance,
           writing to status.dat is not necessary; neither is writing to a SQL db with NDO).
           Because it is reading object status directly from Nagios's memory, the results
           are always 100% up to date......no time delay.  The broker module is already
           installed on any Nagios installation that I set up, because it is a required
           component of Check_MK.  It can be queried from either a TCP or Unix socket.
           Details can be found here:  http://mathias-kettner.de/checkmk_livestatus.html
           While this method of "getting at the data" has lots of upsides, it could require
           a rethinking of how the pubsub model would fit.  It necessarily shifts us from
           parsing/translating a file on disk (status.dat) to having to actively query something.
      <IB> Querying/polling won't be a problem. This sounds like an interesting approach.
      <CG> I want to follow up again on these to make sure we are working from   
           the same assumptions.  If ExoGENI and GMOC can negotiate an approach
           using pubsub or direct nagios communication, and both sides can do the
           respective work to get that interface running, that's fine with GPO.
           Our desire here is just to have some useful data be submitted from each
           rack to GMOC (or polled from each rack by GMOC) reasonably often.
           However, the interface which already exists is the XML-over-HTTPS data
           submission API developed by GMOC.  This API is active and usable for
           time-series (operational measurement) data right now, and GPO and GMOC
           are working to make sure it will be ready for relational data (e.g. slice
           metadata) within the next couple of months.  ExoGENI racks will need to
           interface with these APIs as a minimum offering.
           Again, if ExoGENI and GMOC do the work between you to support something
           you both like better, that's very likely to be a fine substitute.
           Otherwise, the XML-based API is a "least common denominator" solution,
           and RENCI should submit data using it.
      <IB> My main concern is GMOC's work so far has been outside of the GENI I&M 
           framework which may or may not be a good idea. I'm attempting to bring 
           everything under one roof by using the XMPP bus that will also be used for 
           GENI I&M to submit GMOC-relevant data and see if it flies.
      <HD> Ilia,
           This is not going to work.  The GENI I&M framework is not fully implemented 
           yet,  and may not be for considerably longer than it takes for us to field 
           the racks this year.  The GMOC interface predates the I&M framework, and has
           already been in use in the mesoscale for well over a year.  No GMOC-relevant 
           operations data should be submitted via I&M, which is specifically for 
           experimenter-relevant data.  The GMOC has been part of the I&M project in order
           to make sure that it was possible to distribute operations data into the I&M 
           framework if there was demand for that among experimenters.
           It may be that the GMOC evolves their interface to be more like the I&M interface 
           for simplicity and ease of programming, especially for the aggregate providers.  
           However, we can't count on that for Spiral 4.
      <CG> To clarify: we have no objection to the use of XMPP per se --- GMOC's
           generic interface for data submission uses XML sent via HTTPS, but, if
           data is collected or sent some other way, that's fine.  As Heidi said, we
           just want to see operational data transmission from each rack to GMOC's
           operational monitoring database during this spiral.  I believe using
           the existing data submission API is the most straightforward way to do
           that this year.  However, if the anticipated benefits of XMPP outweigh
           the extra work, and the work can be done this spiral, that's fine.
      <IB> There are enough commonalities between what GMOC wants and what the 
           experimenters want that their work and I&M will converge.
           By March we should have an XMPP bus with GENI authn/authz available 
           (as part of our IMF project with Harry) via which we should be able 
           to make data available to GMOC and at the same time make it available 
           to anyone else with proper GENI credentials.
      
      <CG> I can think of two concerns about using this approach in the short term:
       1. "Proper GENI credentials" sounds to me like an experimenter being
          able to get access to his own experiment's data.  That's not the
          same thing as operational monitoring data [1], which isn't going
          to be per-sliver, but rather might contain some amount of metadata
          about all slivers, and information which is not per se about slivers.
      <IB> You're assuming experimenters only need access to data from their own 
           slices. I disagree. There are circumstances where an experiment in 
           GENI means looking at other experiments.
      <CG> Do you have an implementation for allowing a non-experimenter
          operations group like GMOC read-only access to broader monitoring
          data using a GENI credential?
      <IB> Working on it.
      <CG>  2. On the GMOC end, there needs to be code to use this XMPP interface,
          acquire data, and put it into some operational database at
          http://gmoc-db.grnoc.iu.edu/.  If this is going to be done using
          a new interface rather than an existing one, someone will need to
          write that code.
      <IB> We have example code that can get data from Pub/Sub.
      
  • 24. Rspec support questions:
    • 24a. When will you support GENI v3 RSpecs - part of the GEC13 completion? (hpd)
      <IB> That's the goal. The differences are not that significant.
      
    • 24b. When will you support what RSpec conversions? Can you send sample manifests and advertisements? When can we test?
      <IB> Will send separately. Testing can be done now (Luisa has).
      <AH> 3) Ilia offered sample manifests. We should ask for those - to start
           checking that they include what we expect. (Q 24b)
      
  • 25. Have you tested performance of a single management node with a full load of running software (FV and OpenStack/Euca head and GENI services and monitoring etc.? Or Is FV on a separate VM?
    <IB> Everything but the OpenFlow components. It's not much of a
         load. Supporting FV still an open question in terms of performance
         needed.
    <HD> To Nick: Do you have enough info yet to know whether FV on a VM in 
         ExoGENI rack will be OK at this point?  Have you given Ilia any 
         more info about what FV needs for acceptable performance in GENI?
    <NB> I have no further information from Ilia, and he has not requested any
         information from me in reference to this.  My understanding is that he
         is aware that they have not characterized the FlowVisor workload and
         still need to do so.  (I also have other concerns about software
         interaction and compatibility as expressed on the mailing list).
    
  • 26. On layer 2 dataplane connectivity testing: Do you envision a long running slice where we can allocate VLANs to test as needed? What happens if the AM is unreachable/down?
    <IB> If AM is unreachable, you can't provision a VLAN. When the
         VLAN is up it should stay up regardless of AM status.
    <JS> We should bang on this a little more, and understand whether our
        monitoring stuff will in fact be in a slice, or a non-GENI thing. (I don't
        feel strongly about it, and don't recall now if we concluded that we
        preferred one or the other.)
    <GC> 26. Dataplane reachability testing:                               
       We think it would be a good idea to have two types of tests to go
       with the two types of VLANs:
       * Where the ExoGENI AM is used to provision a VLAN, we'd like to see
         a test which stands up a VLAN, verifies that it can be used,
         and reports to monitoring on whether that entire system (which
         includes the AM, of course) is healthy.  I believe you discussed
         doing something like this already: does what i just said sound
         similar to what you have in mind?
    <IB> I think so. A simple reachability test would not be difficult to do,
         but currently is not a high priority.
    
    <CG> * Where an ExoGENI rack is going to be connected to a static
         (long-standing) VLAN outside of the rack, e.g. to the shared
         mesoscale VLANs or to a longstanding L2 connection to non-rack
         resources at a particular site, we'd like to see a static test
         interface on each VLAN which could be used to verify connectivity.
         It would be ideal if the test interface were non-OpenFlow-controlled
         on the rack, so that it could be used entirely to test "is this
         link up?".  Does this seem reasonable?
    <IB> yes, but not with the current version of the switch which is OpenFlow
         all-or-nothing. When we have the hybrid mode towards the end of the year
         this should be possible.
    <CG> Good point --- if everything on the dataplane switch is
         OpenFlow-controlled, then a non-OF-controlled testpoint is not possible.
         However, i think it would still be possible to place a static test
         interface on a static VLAN which reports to e.g. FOAM.
    <NB> The external VLAN connection can be established and tested regardless
         of the hybrid-ness of the switch.  If the goal is merely to establish
         whether a link an external interface is up or down, this can be done
         within or without openflow, regardless of the state of the switch (the
         ability of a switch to determine port up/down status, electrical,
         protocol, or administrative, is independent of the openflow
         implementation).  If you are truly determined to require a
         non-openflow port to test (electrical?) connectivity, you can do that
         with the current BNT firmware as well (ports can be configured to be
         non-openflow, they just have no real features beyond that of a
         standard L2 learning switch, but those would suffice for this
         purpose), but there's no particular reason why this port can't be
         openflow controlled.
    <IB> I think Chaos wanted to have an interface with an assigned IP address
         internal to the switch that can be used for L3 reachability testing.
    <CG> L2 reachability testing, really.  Sorry if i've been unclear: the goal
         here is to have some tools to detect problems with shared VLANs.  If an
         ExoGENI rack participates in a core VLAN, but can't reach other things
         on that VLAN, then an experimenter might want to know something is wrong
         before trying to provision something attached to that VLAN on that rack.
         In practice, you don't want to provision too many different test
         resources, and there is a tradeoff between having a test which is most
         similar to an experiment ("if this test works, it is very likely that
         this resource is healthy enough for an experimenter to use") vs. having
         a test which gives you more information about what is wrong ("this test
         does not depend on OpenFlow, so, if this test fails, it tells us there is
         a connectivity problem caused by something other than OF on this rack").
         I think it's fine with us to have a test which runs in a sliver, but
         if we're testing a static VLAN to which an experimenter would connect
         by e.g. reserving resources using FOAM, the resource test should use a
         FOAM sliver.  An advantage to setting up a test interface which doesn't
         depend on a local sliver, is that people can use that interface for
         reachability testing without having to maintain that local sliver.  But,
         in fact, all of our core testing uses slivers somewhere --- there's no
         good way around that.  It just has to be feasible for that sliver to be
         used for frequent/automated testing.
    <IB> The easiest way to test l2 reachability is to configure l3 addresses on
         two endpoints of a Vlan. With traditional switches you can  configure an
         interface on a Vlan and assign it IP address (internal to the switch).
         I thought that is what you meant. We do it here periodically (manually)
         between our switches.
    <NB> Sure, I would use FlowVisor or FOAM for the first test (no sliver
         required to know what ports are up, or whether the datapath seems to
         be available at all), and SNMP for the second (also no sliver
         required).
         If you want this information centrally (via GMOC or something) we
         should probably offer a read-only FOAM monitoring API, since getting
         the information via the existing admin API seems like a bad idea, but
         that's a trivial problem.
    <CG> Sorry i never got back to this.  This kind of approach is fine with us         
         for testing of static VLANs, and is indeed what we had in mind.
    

* 27. We want to share the final ExoGENI rack parts list and rack diagram (when you finish it) on the GENI web site. OK with you? (Luisa Nevers, see notes below)

<IB> It's available here:
       https://docs.google.com/document/d/1hzleT6TNmiDb0YkkgqjXxPFJ37P4O6qApLmXgKJHBZQ/edit
<LN> Collected remaining information for the parts list.  See:                                           
     http://groups.geni.net/syseng/wiki/GENI-Infrastructure-Portal/GENIRacks#ExoGENISpecifications 
     Checked on wiring rack diagram and found from Brad Viviano that the diagram will be 
     available after the GPO rack is assembled.
<LN> Email exchange on Feb 13 to gpo-infra included a wiring diagram which is attached as file
     named Rack-diagram-wiring.xls
  • 28. How does a site admin control resources which have been allocated to ExoSM and are controlled centrally by RENCI?"
    <IB> ORCA configuration files. There is an actor configuration file
         (XML) and a resource description file (scary NDL-OWL).
    
  • 29. In the design review, ORCA indicated that they started a NOX instance to communicate with FlowVisor to communicate ExoGENI OpenFlow requests. Nick Bastin said he would like to replace this with an API to FOAM. Nick and Ilia promised to follow up. This question should also address conflicting FlowVisor requests capture in Q 22a. (jbs)
    <JS> Then there was 22a:                                             
         22a. Are there conflicts between FOAM and Orca mechanisms to create
         FlowVisor rules?
         I had said "To my mind, this is a point in favor of having ORCA talk to
         FOAM, rather than having both ORCA and FOAM talk directly to FlowVisor."
         Nick also liked this idea; have you guys talked about it any further?
    <IB> The implementation we have today talks to FlowVisor. We prefer this
         method because it bypasses the need to create OF RSpec. Also, based
         on discussions with Nick, he is unwilling currently to modify FOAM
         RSpec to what we need.
    <JS> Hmm, I think there may be some confusion about this: I don't think that
         Nick was proposing that ORCA should write and submit rspecs to FOAM, but
         rather than ORCA would talk directly to a FOAM API. He plans to write a
         plugin API, which others (or he) can then use to write plugins to talk to
         FOAM via arbitrary custom APIs; most immediately, he says he'd be happy to
         write a custom FOAM API for ORCA. But rspecs don't enter into it at all in
         any case.
         The custom ORCA - FOAM API could look pretty much however you want. For
         that matter, it could be identical to the FlowVisor XMLRPC API -- but
         going through FOAM means that you can be aware of other FOAM slivers, and
         that FOAM is aware of ORCA-created slivers, for free.
    <JB> 29. Will ORCA talk directly to FlowVisor, or to FlowVisor via FOAM?          
         require some FOAM development work, but Nick is eager to work on this.
         ISSUE: Nick and the ORCA folks should talk about timeframes, to make sure
         that Nick can do what the ORCA side needs, in time for them to use it, but
         he doesn't think it would be a problem to get it done very quickly.
    <IB> The implementation we have today talks to FlowVisor. We prefer this method 
         because it bypasses the need to create OF RSpec. Also, based on discussions 
         with Nick, he is unwilling currently to modify FOAM RSpec to what we need. 
    <IB> That's not to say I'm blaming Nick - he has his reasons. FlowVisor at this 
         time presents what appears to me the most stable and easy to program interface. 
         As the code and RSpec evolve in the future we can revisit this question.
    <JS> Hmm, I think there may be some confusion about this: I don't think that
         Nick was proposing that ORCA should write and submit rspecs to FOAM, but
         rather than ORCA would talk directly to a FOAM API. He plans to write a
         plugin API, which others (or he) can then use to write plugins to talk to
         FOAM via arbitrary custom APIs; most immediately, he says he'd be happy to
         write a custom FOAM API for ORCA. But rspecs don't enter into it at all in
         any case.
    <IB> I may be mistaken about the current state of FOAM. I thought it supported 
         GENI AM API, and that requires RSpec. Is there another interface and what is it? 
    <NB> The point here is there *can* be another interface (there are already
         4 API interfaces, soon to be 5 when we add GENI AM API v2), so there's
         not really any problem adding one for exogeni (or, alternatively, just
         making one that looks like the flowvisor XMLRPC interface).
    <IB> I don't have a problem with that when it becomes available. 
    <JS> The custom ORCA - FOAM API could look pretty much however you want. For
         that matter, it could be identical to the FlowVisor XMLRPC API -- but
         going through FOAM means that you can be aware of other FOAM slivers, and
         that FOAM is aware of ORCA-created slivers, for free.
    <IB> I expect a fairly hard partitioning between label spaces that FOAM operates in 
         and ORCA operates in, so this may not be a serious issue, but it may be worth discussing.
    <NB> The intention would be for FOAM to be aware of the sliver URNs if at
         all possible.  Obviously this wouldn't be possible out of the box if
         we merely emulated the FV XML-RPC API, but if we added an extra
         parameter or two to CreateSlice it would be relatively easy
         information to provide.
    <IB> I don't think I followed that. Which sliver URNs? 
    
    <JS> We (GPO) think this would be worth spending a ten minute phone call to
         talk about, and we'd like to help facilitate that (whether you end up
         going this route or not -- we just want to promote communication); any
         chance you'd be available later this afternoon? Or maybe Monday?  
    <IB> That's fine. Next week is better. Please use Doodle.                            
    <NB> The URNs for the slivers which have associated FlowVisor slices.
         (Such that if one asked FOAM, it would know about all the slivers
          which had resources allocated…failing that, at least user URNs).
    <JS> I've craeted http://www.doodle.com/r58q8esy4vawn7q8 as a Doodle poll
         suggesting times this afternoon and tomorrow; I think Ilia and Nick are
         essential, and anyone else who's interested could listen in. (And anyone
         else who Ilia thinks is essential from the ExoGENI team -- Ilia, let me
         know if you have anyone else in mind.)
    
    "Note the message below is in response to a much earlier comment form Ilia
    which stated:  <IB> I don't have a problem with that when it becomes available.
    
    <NB> When which becomes available?  We're looking for some input here - is
         the path of least resistance to emulate the FV XML-RPC API, or should
         we develop something more specialized for exogeni?
    <HD> To Nick: I've seen several emails on the exigent-design list, and it 
         sounds like you, Josh and Iila are planning a teleconf this week.  
         Do you think you'll be able to put enough effort into the discussions 
         to work out a rough agreement for a solution this week?
    <NB> I believe this is conflating two issues:
         1) They have a separate software stack (their AM, not NOX) which
         communicates with FlowVisor outside the visibility of FOAM to allocate
         virtualized resources
         2) They have suggested using NOX to provide baseline control of their
         openflow resources for non-openflow experimenters.  I think many
         people (myself included) believe this is a bad idea, and we should
         explore precisely what they are trying to accomplish and how to best
         execute that.
       
         We are planning on discussing issue (1) this week, but there has been
         no further mention of issue (2).
    <JS> Mm, I'd forgotten about that part. Perhaps because I feel like "they're
         planning to provide a service that we think is a bad idea" seems like less
         of a problem (we can ask them to turn off that service) than "they're not
         planning to do something that we think they'll need to do".
         Nick, should we be more concerned about this than we are?
    <NB> I believe so.
         My general understanding is that because they can't run this switch in
         an "acceptable" hybrid mode (for varying values of whatever that is)
         they have identified a need to still be able to provide their
         non-openflow network service to experimenters, so they're going to run
         a controller to manage these slices and they've chosen NOX.  This is
         at least my understanding.
    <JS> Ah, that sounds plausible. (I had lost the context here, and was thinking
         that they were talking about an even more optional service, which people
         who wanted to use OpenFlow could use if they didn't want to run their own
         controller; but in fact I think you're right, what they're talking about
         is something so that people who don't care at all about OpenFlow don't
         have to touch it at all.)
    <NB> However, I believe they should run in this mode all the time - using
         hybrid datapaths only creates problems and limits functionality for
         the openflow portion of the network.  
    <JS> Could be; that sounds like a conversation we can have with them when the
         switch firmware allows hybrid mode. If the experiment with pure OF mode
         has gone well enough until then, it might be an easy sell -- and so that's
         some incentive to see the pure-OF way work well.
    <NB> That being said, I definitely
         don't think they should be running NOX to provide transport for
         non-openflow users - not particularly because this has anything to do
         with NOX so much as the fact that often when people say "run NOX" they
         mean run one of the NOX sample applications, which are not production
         applications (and certainly don't provide the functionality we would
         desire).  GIven Ilia's apparent lack of interest in writing any code
         to work with the openflow side of their rack, I highly doubt that
         they're intending to write a custom app for NOX to facilitate their
         use case.
    <JS> That all sounds likely to me. This isn't something that we have a lot of
         experience with, because we've mostly been focused on supporting
         experimenters who (a) want to do nifty things with OpenFlow, and are thus
         writing their own controllers; or (b) just want a learning-switch
         controller, but are doing things on such a small scale that NOX 'switch'
         or 'pyswitch' is good enough for their needs.
         You mentioned "production applications"; do you have any insight into what
         *would* fit that bill, but not cost a lot of money? (Or time spent
         convincing a vendor (like BigSwitch or NEC) to donate a production
         controller, or whatever.) Is there in fact a better off-the-shelf solution
         than NOX 'switch'?
    
    Note: Comment below after meeting with Ilia, Josh and Nick.
    <JS> We did! And the main thing that we concluded is that Ilia doesn't think
         there's time before GEC 13 to change how ORCA talks to FlowVisor, so we're
         not going to try to throw together an ExoGENI-specific API to FOAM
         immediately. Instead:
    
         * Nick will continue to work towards the planned API plug-in layer for
           FOAM, which he thinks will be done by GEC 13.
         
         * The first two racks (RENCI and BBN) will have ORCA talking directly to
           FlowVisor, with the understanding that this may have some issues.
         
         * We'll aim to shift to a model where ORCA will talk directly to FOAM,
           after GEC 13. (Or, talk more between now and then about whether this is
           a good idea -- Jeff raised some questions about this, and we generally
           agreed that what we all really want is for FlowVisor to have only one
           administrative master, but that it isn't fundamentally important whether
           that master is FOAM or ORCA... So if ORCA can do everything we need it
           to do -- including managing flowspace for non-GENI resources that aren't
           part of the ExoGENI rack -- then perhaps it makes sense to not run FOAM
           in an ExoGENI rack at all. But we think this that isn't a short-term
           solution, because it would require a way for those non-GENI resources to
           interact with ORCA to tell it what flowspace they wanted, and I don't
           think we have even an idea about what that would be.)
         
         So, with that, I think question 29 from the original list is answered: In
         the first two ExoGENI racks (RENCI and BBN), ORCA and FOAM will both talk
         directly to FlowVisor; we'll continue to discuss between now and GEC 13
         about how to narrow this down to having only one of them do that; and
         we'll aim to implement a single-master solution soon after GEC 13 (and
         definitely before any additional racks ship).
    
         Sound right? Anything else I missed or otherwise got wrong?
    
    
  • 30. External resources (like the mesoscale) have to be manually configured to be available. We should make a list of the resources that could connect and we want connected, and get them to build those in advance. Like the mesoscale.
    <HD> Configuration for meso-scale is worth persuing need answers to Josh's use cases first.
    <IB> There will be a hard partitioning between resources controlled by the ExoGENI SM and 
    other resources.  Changing the partitioning is pretty straightforward and not very disruptive.
    <TU> We are initially planning to hand 10 VLANs that we have provisioned to our FrameNet 
    endpoint and 1 VLAN that is provisioned to our ION endpoint to the ExoGENI team.  Initially, 
    they will control these VLANs with the ExoGENI SM.  WE can give them more VLANs later, 
    assuming it is easy.  We only plan on provisioning a single OpenFlow VLAN to the ExoGENI rack 
    in our lab (1750) to start. 
    <TU> Currently we are thinking about provisioning extra special use OpenFlow VLANs from each 
    mesoscale campus.  We will have to let the ExoGENI team know how to reach these VLANs once we 
    actually provision them.  This should be as simple as provisioning VLANs down to the rack and 
    letting the rack know the VLAN IDs.
    <TU> We are also thinking about having mesoscale campuses have a set of non-OF controlled 
    VLANs.  I think we should just be able to tell the ExoGENI team the VLAN ID and the endpoint 
    (FrameNet, ION, etc) that the mesoscale campus uses, an then the ExoGENI SM should be able to 
    connect to that VLAN.
    

Nick Bastin's Questions

Network:

  • B-1. Why not use FOAM everywhere? (hpd)
  • B-2. Why not run pure OpenFlow and slice on VLAN in FlowVisor w/translation at the rack edge?
  • B-3. How is IP space managed within the rack environment - can experimenters request more / specific IP space? (hpd) (Duplicate of question 10b)
  • B-4. The OpenFlow control channel looks to be extremely throughput constrained.
  • B-5(1). Does the switch not support the ENQUEUE action at all, or does it just not support all the openflow packet-queue structures?
    <BV> B-5. Is there an IPMI connection from the head node to the
         management switch? If so I think that makes for 45 management
         switch ports used.
         o Worker node.  IBM x3650 with Virtual Media Key.  1 port for
           vKVM/IPMI/etc, 2 ports for 1GbE traffic.  Total of 30 (assuming
           10 worker nodes)
         o Head node.  IBM x3650 with Virtual Media Key.  1 port for
           vKVM/IPMI/etc, 8 port for 1GbE traffic.  Total of 9.
         o iSCSI enclosure.  Redundant controllers, each with 2 ports.
           Total of 4.
         o Juniper VPN appliance.  1 WAN port, 1 LAN port.
         o PDU.  1 port (For 208V based PDU's)
        How many ports in total get used on the management switch will
        depend on the connectivity from each campus.  If for example
        we can ONLY get 1 1GbE connection from campus the total will
        be 47 (46 from above, plus campus into the management switch).
        That would be the worst case situation and leaves us 1 open
        1GbE port on the switch.
    <NB> Ok, I was just working off of the table on page 4 of the design
         document that has 44 ports used on the management switch.  It's a
         little hard to reconcile that table with figures 1 and 2, as well as
         the text.  Figure 1 has a red line connecting the management switch
         "to campus layer 3 network", and figure 2 has a line connecting the
         management switch to the Juniper SSG5 (which is not in figure 1), and
         no other connection to an outside L3 resource.  The text in 2.1 states
         "The connections to the commodity Internet via the campus network is
         expected to serve management access by staff as well as experimenters"
         - I read this to mean that all control-plane access (management and
         experimenter) would be coming in over the SSG5.  So, I guess the new
         question is, is there a direct campus L3 connection to the management
         switch, as well as a connection to the SSG5?  Also, do you really mean
         that the SSG5 is connected twice to the management switch?  (I
         understand how that would work, I'm just trying to figure out if
         that's what you mean)
    

Rack Configuration:

  • B-5(2). Is there an IPMI connection from the head node to the management switch? If so I think that makes for 45 management switch ports used.
  • B-6 I am concerned that the head node is under provisioned for all the services it needs to run - 12GB of ram seems low.
    <BV> We don't have empirical evidence that 12GB of memory won't be
         enough. We felt it was a safe starting value, but ensured there
         are free DIMM slots if we need to expand to 24GB or 36GB.
         Although the cost of 2GB DIMM's vs 4GB's isn't significant,
         when multiplied out to 12-14 sites it was enough that we decided
         to start with 12GB.  If we decide later to move to 24GB, we'll
         expand future racks so they come from IBM that way.
    <AH> 15) They haven't tested the head node, when the FlowVisor and FOAM are
         getting actively used, to check for performance problems. It's unclear
         if there is an issue here or not, but the only real solution appears to
         be to double the RAM - which they can do later if necessary.
    <CG> They can do it later if necessary, but why not do it sooner?  I'm curious
         what the actual numbers involved here are: my personal experience has been
         that RAM is (a) cheap, and (b) always the thing you're short of.  I know
         they said they could send a tech on-site, but, for a new installation,
         12GB of RAM should be something like $150.  There's one head node per
         rack, and how many racks the first year?  Again, i don't know the actual
         numbers or tradeoffs, but i think it's very likely that this is cheap
         and may solve a real problem.  So IMHO they should just do it while it's
         early enough to never have to think about it again.
    <NB> Fair enough.  I would also ask that we revisit the plan for all the
         software on the management node to be installed in the same OS
         instance - I really think this should be a virtualized environment
         (particularly because both FOAM and FlowVisor do not currently have
         RPM package builds).  This will put significant constraints on the
         software to use the same JVM versions, etc., or create an integration
         challenge to create separate environments for the software to run in
    
  • B-7. How is the head node configured - do the services run in their own VMs, or do they need to co-exist on the same OS instance? (jbs)
    <IB> The VM option remains open, however currently we are not seeing any
         software conflicts that would require that. VMs will take some
         performance overhead and they may make it more difficult to
         communicate between some elements of the software stack.
    
         We have already built most of the components on our OS of choice -
         CentOS 6.2 and we're not seeing any conflicts. Despite the fact the
         CentOS/RedHat is not always officially supported, there are usually
         instructions for advanced users on how to build the software that seem
         to work.
    <JS> Aha, ok. It might mean that you have to do more ongoing work to track
         updates to those components, if new versions don't build as cleanly, but,
         as you say, we can revisit if it turns out to be a problem. I think it's
         probably fine to call this closed, but since it was originally on Nick's
         list, I wanted to give him (or anyone else with contrary opinions) a
         chance to chime in before I crossed it off.
    <JS> B-7. How is the head node configured - do the services run in their own            
         VMs, or do they need to co-exist on the same OS instance?
         ISSUE: We (GPO) think it would be better if the head node ran VMs, so that
         the various software that needs to run there can run in a more isolated
         environment, on its preferred OS; but it sounds like that's not how RENCI
         is planning to do it at this point. If you prefer the all-in-one-OS
         approach, can you talk more (maybe fork off a separate thread) about why?
    <IB> The VM option remains open, however currently we are not seeing any software 
         conflicts that would require that. VMs will take some performance overhead 
         and they may make it more difficult to communicate between some elements of 
         the software stack.
    <JS> Aha, ok. It might mean that you have to do more ongoing work to track
         updates to those components, if new versions don't build as cleanly, but,
         as you say, we can revisit if it turns out to be a problem. I think it's
         probably fine to call this closed, but since it was originally on Nick's
         list, I wanted to give him (or anyone else with contrary opinions) a
         chance to chime in before I crossed it off.
         We have already built most of the components on our OS of choice - CentOS 
         6.2 and we're not seeing any conflicts. Despite the fact the CentOS/RedHat 
         is not always officially supported, there are usually instructions for advanced 
         users on how to build the software that seem to work. 
    <IB> OK
    <NB> At the very least we're likely to run into the need to move common
         services (like SNMP) to custom ports, but I'm also concerned about
         finding ourselves in a situation where we have conflicts in required
         JVMs or similar (FlowVisor already trips over some known issues in
         commonly distributed JVMs) or Python versions.
    <IB> We use JREs downloaded from Oracle site, not shipped with the distro. CentOS 6.2 
         seems to be reasonable up to date with python (2.6.6 is the stock version ). 
         Which components have SNMP interfaces on them? 
    <JS> My summary is that Ilia is optimistic that there won't be any issues,
         Nick is pessimistic that there will be, Ilia has said that they'll
         revisit if they are, and that this is fine with us for now.
    <NB> Both FlowVisor and FOAM will have SNMP interfaces in the medium term.
         The suggested use case for most installations would be that they would
         disable the FV interface and just use the FOAM one if they were
         running both, but that will be more difficult if FOAM doesn't know
         detailed information about everything in FlowVisor.  Also, I'm not
         saying there are necessarily any problems right *now* with JVM/Python
         versions etc, but this will be an ongoing software qualification
         concern when individual components become available with new versions.
    
  • B-8. PDUs are also useful for remote management if a node gets completely bricked (such that IPMI is useless) - I would think that the marginal cost would be more than worth it. (hpd) (we're helping RENCI to work on in the first couple of rack integration efforts. Ticket #3354)
    <BV> IBM doesn't offer switched PDU's with 120V on their standard
         Bill of Material.  The 208V units on their standard BoM are
         switched and monitored.  For the first 2 racks (RENCI and BBN)
         we are sticking with IBM's standard BoM because to use
         non-standard BoM parts means it can't be assembled in the
         factory and has to goto the "Integration Center" which increases
         the lead time.  So for the BBN rack, we won't have switching.
         We hope for other sites that can only support 120V power we
         will be able to identify with IBM a reasonable switched PDU
         they can install.
    <JS> I've forgotten, can we take a 208V unit? If so, then if that would get us
         a switched PDU, then it might be worth doing.
    <JS> We (GPO) think it would be better if the head node ran VMs, so that
         the various software that needs to run there can run in a more
         isolated environment, on its preferred OS; but it sounds like that's
         not how RENCI is planning to do it at this point. If you prefer the
         all-in-one-OS approach, can you talk more (maybe fork off a separate
         thread) about why?
    <IB> The VM option remains open, however currently we are not seeing any
         software conflicts that would require that. VMs will take some
         performance overhead and they may make it more difficult to
         communicate between some elements of the software stack.
    <IB> We have already built most of the components on our OS of choice -
         CentOS 6.2 and we're not seeing any conflicts. Despite the fact the
         CentOS/RedHat is not always officially supported, there are usually
         instructions for advanced users on how to build the software that
         seem to work.
    

Resources:

  • B-9. Why not allow arbitrary bare-metal images? Is this any more dangerous than arbitrary VM images? (hpd) (Duplicate of question S.27)
    <BV> As discussed briefing in the concall.  The reason to not allow
         custom bare metal images is two fold.  1) The decrease in
         security because users will have direct access to the bare
         metal network interface which connects to the management switch.
         2) The complexity of creating a bare metal image means the
         user would have to have a system identical to the one inside
         the ExoGeni racks so they could load all the hardware drivers,
         etc.  I don't think we've ruled out the possibility 100% and
         if a user provides a compelling reason for why they need it,
         then we can consider it.  But I think we have enough on our
         plates with the initial deployment without adding this level
         of complexity on day one.
    
  • B-10. Where is the storage for the running instances - on the worker nodes? (hpd)
    <BV> We will have the ability to provide storage either on the
         running worker or via NFS from the head.  Long term plans
         include being able to provision raw iSCSI luns from the iSCSI
         unit with a slice and make those available as well.
    
  • B-11. What are the average IOPS available for each VM on a fully loaded (max running VMs) worker node?
    <BV> Each worker has 2 hard drives.  1 146GB 10K RPM SAS and 1 600GB
         10K RPM SAS.  In the case of a VM worker, the OS (CentOS 6)
         will be installed on the 146GB drive and all the VM's storage
         will be installed on the 600GB drive.  In a bare metal install
         the user would have access to both and could use them as they
         saw fit.  The "standard" rating for a single 10K RPM SAS spindle
         is 180 IOPS.  There are 6 drive slots on each worker, we can
         add more spindles, but for each spindle we add, we remove 1
         worker because of the cost (i.e. 9 2.5" 600GB SAS spindles =
         about $4000, or the cost of a worker).
    
         In all the infrastructure designs it was a delicate balancing
         act between available funds and performance.  Our goal being
         to build something that was usable today but extensible for
         the future.  The first 2 racks are our on the job training.
         We fully expect that after these first 2 racks we will tweak
         the hardware configurations with IBM and hopefully have a
         smooth flow from IBM's integration center to the other sites
         for the remaining 10-12.
    
    <NB> This seems optimistic - the latency of a 10k rpm spindle with a 2.5"
         platter is 3ms, and the IBM 5433 (the 600GB drive in question) has a
         4.2ms average read seek time (writes are slower, but we'll be
         optimistic here for the purposes of this discussion), which makes for
         ~139 IOPS (1 / 0.0072).  Of course, neither of these numbers are
         particularly useful if we don't have an idea of the workload - more on
         this below.
    <NB> I've been doing some math on the back of some napkins and I think that
         might be a net positive tradeoff for total VM capacity based on a
         variety of workload calculations (although factoring bare metal into
         this makes that calculus more complicated).  I still have some work to
         do on this, so I'll followup later with my thoughts.
    
    

Adam Slagell's Questions

Software/Firmware Update

  • S.1 What part of the software stack does exoGENI take responsibility for maintaining updates? IS there anything they don't? (chaos, based on adam's comment)
    <AS> Sounds like VM/BM images and all the software that comes with
         the racks. I didn't see any gaps or buyer bewares.
    <IB> We will take care of software updates. The only buyer-beware concerns 
         the operation of FOAM - we don't want to be in the business of approving 
         user slices in FOAM and think this needs to be done by GPO or GPO delegate. 
    
  • S.2 Is there an automated updated system? If so, how is integrity insured?
    <AS> Sounds like no.
    <IB> Not at this time. The software is too diverse.
    <AS> Maybe for the system images some sort of integrity verification 
         using digital signatures is feasible.
    <IB> Currently the images for VMs go through such a verification -
         the user submits a URL and a SHA-1 hash of the image they want booted. 
         For bare-metal images if we add filesystem integrity verification, it
         can cover the images locally cached on the head node.
    <AS> 1. Auto update system: There are no plans for an autoupdate system for
         the GENI racks. With a large and complex software stack and many racks 
         at many institutions, this could become problematic to keep up-to-date. 
         The quickest way to a security incident is to have out of date software.
         BTW, isn't there a GENI project (by Justin Cappos I think) that is 
         supposed to help make getting secure and reliable updates easy.
    
  • S.3 Is there a service guarantee for updates? Say a flowvisor vulnerability is found and a patch made. How quickly can you push out updates?
    <IB> Since none of the GENI software I know runs as root, I think we can be 
         relatively lax about this. I would say 72 hours if it is a straight-forward 
         update that does not require significant reconfiguration and repackaging. 
    <AS> 2. Vulnerability management: Any major system going out needs a plan for 
         monitoring and investigating vulnerability impacts. The more complex the 
        software stack and the more things that depart from a vanilla OS distribution, 
        the harder this becomes. You need to (1) be aware of all potential vulnerabilities 
        (challenging for a complex software stack), (2) test for exploitability, (3) determine 
        impact, (4) test patch or mitigation, and (5) push out a solution all very rapidly. 
        The previous comment in #1 really addresses just the last bit, and I see no 
        vulnerability management plan into which you could insert it now.
    <JM> There's been talk of several strategies, and no single solution will get it
         all done.  We will all know what the state of OS patching looks like, since 
         I have a Nagios/Check_MK plugin that essentially runs a 'yum check-update'.  
         It does this with the security plugin enabled.  The result is, for each host, 
         we will know how many updates it needs, and how many of those updates and 
         security-related.  Of course, this only helps us with the base OS; it cannot 
         address potential vulnerabilities in the GENI-ORCA-OpenStack-Neuca world.  
         Ilia will have to comment on the latter.
         In terms of stopping SSH brute force attacks, I think denyhosts is a good way 
         to go.  But our sshd is tcpwrappered by default anyway (set up by kickstart).  
         This is kind of attack won't be an issue. 
    <AS> There's also the VM and bare metal images as well, right.
    <IB> Regarding the VM images - since users are allowed to boot their own, 
         the main weapon we have there is the ability to match resources to slices 
         and shut down misbehaving resources. 
         Bare-metal images will be restricted to a small selection (size 1 initially). 
         The problem with frequently changing/updating those is that it makes repeatable 
         experimentation more difficult, e.g. if an experimenter expects a certain image 
         with certain versions of kernel, drivers and software and we continuously move that mark. 
         The GPO will need to weigh in on what is more important - repeatability or the 
         potential impact on security, because this is an important tradeoff we're talking 
         about here.
    <AS> Good point.
    <BV> Also, I'd like to add, based on conversations yesterday, neither VM's 
         nor bare-metel servers will have direct internet access.  Our plan is 
         to proxy all public IP traffic through the headnode at each site, using 
         IP tables.  This gives us the opportunity to shutdown a site very quickly 
         if there is a report of a problem, but keep the problem system running 
         (VM or bare metal), so we can analyze what is going on and resolve the 
         issue with the experimenter.
    <AS> I'm not sure what you are saying exactly here. Are they private IPs that 
         are NATed, are they going through an application layer gateway? What do 
         you mean by not direct?
    <JS> Hmm, my impression is that if we wanted to create a new bare-metal image,
         we wouldn't necessarily delete old one(s), but rather that the list would
         grow over time.
         Ah, but that may not have been what you meant: Indeed, if we update an
         existing image to fix security problems, that would potentially have an
         impact on repeatability. I think we'd need to at least identify that the
         image had changed (e.g. by changing its name), so an exprimenter would be
         aware of that, and could re-validate that their experiment still produced
         the same results after the change.
         We could also devise some way for the experimenter to capture the
         vulnerable image, so they could run it somewhere else if they felt the
         need. (Or just boot it up on an isolated system of their own so that they
         could look at it, or whatever.)
    <AS> I was assuming you would add new images that you support over time, but 
         existing ones would get security patches as time goes by. Of course you'd
         want to enumerate them and specify how they differ, perhaps in /CHANGELOG.txt 
         or something.
    <IB> I don't know that we can guarantee that a particular 'security' patch will 
         not affect the performance of one or other of the kernel subsystems thus 
         affecting repeatability.
    <JS> Ja; I think "track, notify, and archive" is the right approach here.
    <SS> I'd turn this around -- we know that many changes will affect performance, 
         sometimes in only minor ways, but sometimes in major ways.
         If space is not a problem, I'd plan to keep every old version of standard 
         images around. The naming convention is just a detail, but
         OS-version-exogeni-current might be the name that gets you the latest 
         patched/supported image, but the logs would show you the precise version 
         you got (OS-version-exogeni-x.y or -yyyy-mm-dd).
         If an experimenter is running a slice that is on a closed (virtual) network, 
         e.g. configured so that only a fixed set of well-known machines can reach it, 
         then it is possible to bring up even old images with security vulnerabilities 
         and repeat earlier test runs or collect new data using those older images.
         If that same experimenter wants to run on a slice that provides "service" 
         to some larger, open set of users (on campuses or wherever), then they are 
         going to appreciate having automatic support for getting the latest OS patches 
         into the base images.
         I'm going to guess that we will see both sorts of use cases, but more 
         "closed networks" first.
    <AS> Sounds like a reasonable balance.
    
    <CG> > The GPO will need to weigh in on what is more important - repeatability
         > or the potential impact on security, because this is an important
         > tradeoff we're talking about here.
         So, my two cents: in our lab, we do try to apply OS updates to our
         experimental images, the same way we would to any other nodes we run.
         I think having an update schedule which applies to experimental OS
         images for which standard patches are available, as well as for servers,
         is a good idea.  If you can flag your images with metadata saying when
         they were last updated, so that experimenters know, so much the better.
         And if it's possible to keep old images around in case someone has a
         special-case need for one, again, that's a feature.
         I agree that it's a tradeoff, but i think doing periodic updates of
         images is the better bet.
    
  • S.4 Will there be someone actively monitoring for vulnerabilities on the entire software stack, or is it best effort (e.g., we update all the problems we are told about by someone else).
    <IB> At this point there is no dedicated person. However our ACIS group 
        (members of which are part of the operations staff) are usually aware 
        of latest vulnerabilities as part of their data center responsibilities.
    <AS> It may be worth doing google alerts on Bugtraq for all the software.
    <IB> I'll ask our ACIS folks what they do today. 
    

Log Collection & Management

  • S.5 What do you log and how?
    <IB> ORCA actor state transitions and handler execution outputs. We will log 
         entire manifests to make them available to GMOC. The manifest will be the 
         main vehicle for correlating substrate to slivers.
         There are syslogs on individual hosts as well. Other elements (FlowVisor, 
         FOAM) have their own logs.
    <AS> 4. Logging: I think remote logging is a must for integrity and availability. 
         This should be for syslogs and AM transactions that are needed to maintain 
         accountability of actions. Some additional integrity checking on the hosts
         is nice, but icing on the cake.
    <JM> The remote logging infrastructure is mostly complete.  There is a central 
         server, in a protected VLAN deep in the heart of RENCI, running rsyslog 
         on CentOS 6.2  It only accepts connections in a high numbered port, using 
         RELP, from control.exogeni.net.  The latter is a forwarder for all logs.  
         We have a simple LogAnalyzer web interface to the central rsyslog box (which 
         is syslog.exogeni.renci.org).  This is protected with SSL, Apache basic auth, 
         using LDAPS to authenticate to ldap.exogeni.net.  What remains to be done here 
         involves making all the nodes in each rack forward their messages appropriately. 
         And lastly, if there are any non-standard logs we need capturing (for instance, 
         OpenStack, Neuca, or ORCA logs), I'll need to create a template for handling them. 
    
  • S.6 Are remote copies logged?
    <IB> Not at this time
    
  • S.7 Do you do anything special on the racks to maintain the integrity of the logs?
    <IB> Not at this time
    
  • S.7.B What about other file integrity checking for config files and critical system files.
    <IB> Has not been considered so far, but I think can be added. 
    <AS> Also useful is minimizing setuid programs or watching for changes 
         to setuid bits.
    <IB> Noted
    <AS> 3. SetUIDs and configuration management: I think that it is good 
         that most things don't need to run as root on the racks, but the 
         number of setuid programs should be minimized too. Once you have the 
         list, I think xCat has decent configuration management utilities to 
         make sure security hardening policies like that persist across upgrades 
         and changes. If not, you should have a plan on how to make sure that 
         updates don't move you to a less secure state by modifying configuration 
         unintentionally.
    
  • S.8 Do you log enough to map timestamp/IP/port tuple to a particular slice?
    <AS> Sounds like it is the information is there, though it may take
         some manual investigation, especially if NAT was involved.
    <AH> 8) They haven't really worked out logging, but mostly hope to just send
         everything to GMOC and be done.
         This is probably just fine. This is essentially 'racks will log to a
         remote Logging API' which is consistent with recent architecture group
         discussions. We just need to (a) ensure we are asking for all the right
         bits of information, and (b) have them at least outline the algorithm
         for going through all those logs to get the information we really need
         (eg, what slice ID used IP X Port Y at time Z?)
    
         We should check more specifically on what is stored on the racks in
         terms of logs, if anything.
    <IB> Manifests have the information. 
    
  • S.8.B What if you bridge some other device into GENI through your AM but hide it behind your NAT? For example, could there be some campus device causing a problem, but show up as one of the IPs on your rack, but not actually be under your control? And in that case, could you determine from your logs the device and what slice it was a part of?
    <IB> In the current architecture this is not really possible. The IP 
         addresses given to the rack are used by rack resources only.
    
  • S.9 Can you easily tell what slices are running on a given rack? How about each node on a rack? (chaos, based on adam's comment)
    <AS> Sounds like that is not a problem
    <IB> Yes, although we need to do better with respect to making 
         this information available in an easier form.
    
  • S.10 How long do you keep local copies of the logs?
    <IB> Depends on the verbosity. Once manifests start getting published 
         onto XMPP bus, this will be no longer an issue, as a separate log 
         repository can slurp them up and keep them in one place.
         The syslog logs probably should be configured to go to a central 
         syslog server in addition to having a local copy.
    
  • S.11 Is there a mechanism that could be used to send allocation log information back to the clearinghouse for global policy verification for slices?
    <IB> XMPP bus - we want to use it as the means to make this data 
         available to multiple consumers.
    

Administrative Interfaces

  • S.12 What is the authentication mechanism for the VPN?
    <IB> LDAP + possibly RADIUS slaved to LDAP (for switches)
    <AS> LDAP would be for authorization, but what kind of credential 
         would be used for authentication. Maybe I am missing something.
    <IB> LDAP stores usernames and passwords (as well as groups, which
         would be used to partition rights). RADIUS can read LDAP.
    
  • S.13 Does being on the VPN on one rack get you to the admin interfaces of all the others, or is this one way from RENCI?
    <IB> One way from RENCI 
    
  • S.13.B How does one authenticate to the admin interface (separate from the VPN)? Is it root login?
    <IB> Depends on the device (e.g. a switch vs. a compute node). 
         We opt for sudo whenever possible.
    
  • S.14 Are the credentials used to authenticate to the admin interface different for each rack?
    <IB> This has not been discussed or codified.
    <AS> When architecting this, it would good to strive for containment. So 
         if one unscrupulous person with a GENI rack reverse engineers something, 
         it doesn't give them the credentials they would need to do bad things to 
         other racks. It can complicate initial setups but probably pays off in 
         the long run.
    <IB> Noted
    
  • S.14.B What about within a rack, is the root or admin password the same for each node/device?
    <IB> We tend to use the same password for all worker nodes currently. 
    <AS> I think within a rack, all nodes of the same type could be considered 
         at the same level of trust and treated this way.
    <IB> Noted
    
  • S.15 Is authentication for admins the same whether or not they login through the VPN or SSH into the head node?
    <IB> LDAP will be the back end, so yes.
    <AS> So again, I am confused. LDAP as I have seen it used is just for 
         authorization. There are still SSH keys or passwords or OTP tokens 
         for different accounts. 
    <IB> LDAP stores usernames and passwords. SSH uses PAM on the end hosts 
         to talk to LDAP over SSL channel. Switches use RADIUS that is slaved 
         to LDAP directly.
    <AS> OK, makes sense. Though I presume it is actually salt and hashes stored.
    <IB> Yes, the passwords stored in LDAP are not plain-text. Typically an 
         MD-5 hash is used.
    
  • S.15.B Are the SSH credentials to the head node different for each rack or shared?
    <IB> Same as S.14. I don't know that these two questions are different. 
    <AS> So here I am talking about two separate racks installed at different 
         institutions. Would a password or key that a local admin used to SSH 
         into the head node at University X also let them do the same at 
         University Y?
    <IB> It is likely we will use LDAP groups to partition users such that users 
         are limited to specific racks. Root logins will likely be disabled 
        (and we may disallow 'sudo su -' for most users). 
    
  • S.16 How is accountability of actions recorded if there are more than one admin or is it just a shared root login?
    <IB> we tend to use sudo, so some of the commands and privilege 
         escalations are logged.
    
  • S.17 Does the KVM for console access have an network interface that gives remote console access?
    <AS> Sounds like NO.
    <IB> No
    
  • S.18 What devices and interfaces can you see from the VPN interface?
    <IB> All of them. 
    
  • S.18.B Does this differ for those logging in through the head node?
    <IB> No. Head node access is a redundant means to do the same.
    
  • S.19 Would the hosting organization have a different admin interface?
    <IB> No, just a different set of logins with different credentials. 
         Hosting organizations probably will not have VPN access.
    
  • S.20 Is the only authentication mechanism password based, or two factor auth or ssh keys used?
    <IB> Right now based on LDAP passwords only. 
    <AS> Oh, so you are using LDAP to distribute something like the /etc/shadow 
         file? So here, we use LDAP just to essentially distribute /etc/password, 
         but authentication is done through PAM with Kerberos or OTP. Am I 
         understanding this right, that LDAP does both for you, sort of like NIS?
    <IB> Sort of. Except we don't distribute /etc/passwd - PAM talks to LDAP live
         and there usually is a caching daemon that caches the getpasswd entries 
         temporarily.
    <AS> 5. Remote root access: It was not clear whether remote root login was 
         allowed anywhere. I read that sudo was used when possible, but I would 
         hope no sshd_config files allow remote root login.
    <JM> root SSH is disabled by default in our kickstarts 
    
  • S.21 If ssh keys are used anywhere, are they stored unencrypted on any of these racks.
    <AS> I suspect yes with xCat.
    <IB> Yes.
    
  • S.22 If SSH keys are used, are they different for different racks?
    <IB> We will probably generate different keys.
    
  • S.23 If passwordless SSH keys are used, can they be used multi-directionally? For example, if an xCat process needs to use them to do something on a less trusted part of the system, that other piece should not be able to use the same key to ssh back into the xCat manager.
    <IB> xCAT uses only explicitly registered keys, so this can be avoided. 
         However we will disallow node-to-node logins as per:
         http://sourceforge.net/apps/mediawiki/xcat/index.php?title=Disable_node_to_node_root_passwordless_access
    
  • S.24 Do the admin interfaces need to connect back to anywhere initiating outbound connections?
    <IB> Not that I know of. 
    
  • S.25 What is meant by " Since ExoGENI slices have management network access via the commodity Internet, this is the default behavior." on pg 13? (Perhaps you will have explained this by now and can ignore)
    <IB> This simply says that if you don't care about isolated connectivity 
        between slivers, you always have the commodity Internet connecting them.
    

Isolation

  • S.26 Are you tired yet? I am. :-) (chaos, per adam's comment)
  • S.27 What is the vetting process for bare metal nodes?
    <AS> Sounds like no process yet, but there is recognition that we
         don't want bare metal hosts to be able to sniff in promiscuous
         mode and break the nice isolation properties
    <CG>  26. Dataplane reachability testing:
          We think it would be a good idea to have two types of tests to go
          with the two types of VLANs:
          * Where the ExoGENI AM is used to provision a VLAN, we'd like to see
            a test which stands up a VLAN, verifies that it can be used,
            and reports to monitoring on whether that entire system (which
            includes the AM, of course) is healthy.  I believe you discussed
            doing something like this already: does what i just said sound
            similar to what you have in mind?
          * Where an ExoGENI rack is going to be connected to a static
            (long-standing) VLAN outside of the rack, e.g. to the shared
            mesoscale VLANs or to a longstanding L2 connection to non-rack
            resources at a particular site, we'd like to see a static test
            interface on each VLAN which could be used to verify connectivity.
            It would be ideal if the test interface were non-OpenFlow-controlled
            on the rack, so that it could be used entirely to test "is this
            link up?".  Does this seem reasonable?
    <IB> No process yet. 
    <AS> 7. Image vetting: I think a process, or maybe a set of criteria, is 
         needed for vetting bare metal images. What are the requirements? Things
         such as an "inability to sniff traffic in promiscuous mode on the NICs" 
         would fit into such a list.
    <MB> Is the example you propose below an actual proposed requirement or just 
         a for instance? I ask because the capabilities that come immediately to 
         my mind as wanting bare metal seem likely to want to do exactly this.
    <AS> It was being proposed and an example. I think it is desirable to prevent 
         from a security perspective because it provides better isolation of slices. 
    <SS> Most of these are non-controversial (at least to security folks!) but I 
        didn't quite understand a couple points, maybe because I joined the review
        late and will admit to not reading all the messages.
         7. Image vetting: ... are GENI researchers going to be able to sudo root 
         on bare metal images? (I would have presumed yes, but maybe that isn't the model.)
    <AS> I did not presume so because there was talk about state being preserved 
         between jobs/users. If they aren't wiping images between experiments and 
         users have root access, then there is a whole other security issue. 
    <NB> > It was being proposed and an example. I think it is desirable to prevent
         > from a security perspective because it provides better isolation of slices.
         The ability to capture traffic from a promiscuous NIC on a bare-metal image 
         has no impact on slice isolation.  This is very much something that we should allow.
    <AS> It depends. If it allows me to watch traffic on other slices and there is any 
         expectation of privacy, then it does impact a form of isolation. If there is 
         neither an expectation or promise of privacy, or switching would prevent one 
         from seeing such traffic even if in promiscuous mode, then the it isn't an 
         issue. I don't know the answer to either of those questions, though.
    <NB> The privacy question is a good one, and should be discussed, but isn't
         a factor here.  If you have bare metal, you have exclusive access to
         the switch port and can't capture traffic that belongs to another slice.
    
    
  • S.28 Are the bare metal hosts diskless?
    <AS> No, they have 146GB FS for OS and 600GB FS for data. However,
         they are wiped clean and reinstalled from a fresh vetted image
         between allocations. State is gone.
    <IB> We're still debating whether we want stateful or stateless bare-metal
         nodes. Both options are open.
    <AS> The nice thing about stateless is it more like a white list. If there 
         is state left behind, you have to always wonder if you thought of 
         everything that you need to clean up in between users.
    <IB> This is still TBD and there are advantages to both. 
    
  • S.29 What are the main isolation mechanisms between slices?
    <AS> VM hypervisors or wiped bare-metal systems isolate experiments
         at system level. At the network level, this is done with VLANs.
         The same VLAN won't have slivers from multiple slices.
    <IB> Yes. VLANs have QoS associated with them wherever possible 
        (rate and buffer size limits).
    <AS> 6. Isolation between racks: Isolation between racks is important, 
         especially since these are distributed across the country. Reverse 
         engineering something at one rack should not result in some class-wide 
         vulnerability that affects all racks. Companies like IBM often like 
         to install things with default keys and passwords, and you really 
         need to make sure those are changed and individualized for different 
         racks. Any password hash on a rack off-site is accessible and potentially 
         crackable.
    <SS> Most of these are non-controversial (at least to security folks!) but 
         I didn't quite understand a couple points, maybe because I joined the
         review late and will admit to not reading all the messages.
         6. ... "Any password hash on a rack off-site is accessible..." 
         ... I thought all these racks were getting installed in "well-known" 
         facilities. So while remote, they aren't exactly in physically unprotected
         locations, right?
    <AS> I don't know how much we trust the administrators at the dozens 
         and eventually hundreds of sites. Might students be admins of some 
         of these racks? If it really is a small set of trusted admins with 
         racks on data center floors, then it is less of an issue. 
    

Miscellaneous

  • S.30 For each rack, could the aggregate operator give a concrete block of IP addresses unique to it?
    <AS> Sounds like this is a policy issue and could be made a part
         of the configuration guidelines for each rack. It is helpful
         for the LLR to be able to tell from IP if something is from a
         GENI rack and at which organization quickly.
    <IB> A block or a list of addresses is fine
    
  • S.31 Are any user credentials stored anywhere, even temporarily? If so how are they protected and how long do they live?
    <AS> You argue this is not applicable in the white paper I think?
    <IB> If ABAC is adopted in GENI, user certs may be cached on the 
         head node as part of authorization process. They, however, 
         constitute public information and do not require confidentiality 
         protection
    

Attachments (5)

Download all attachments as: .zip