Changes between Version 7 and Version 8 of GEC14Agenda/CodingSprintAndExperimenterTutoring

07/13/12 10:44:08 (11 years ago)
Aaron Helsinger



  • GEC14Agenda/CodingSprintAndExperimenterTutoring

    v7 v8  
    4343 - Questions or concerns with the GENI Portal and Clearinghouse
     45== Session Summary ==
     47The Coding Sprint session attracted around a dozen experimenters, several operators, and around 20 developers. Experimenters got help getting started or working with GENI, operators discussed primarily monitoring, and developers worked through several issues.
     49The developers had a productive discussion, working through AM API status and proposed changes, stitching, shared VLANs, and questions and concerns about the new GENI Clearinghouse and portal. Thank you to everyone who participated.
     50 - AM API v3 implementations are in process,
     51 - We agreed to move forward with Update() as proposed on the dev mailing list, and
     52 - We're hoping for an inter-rack stitching demo this Fall.
     53 - We worked out a plan for naming and working with shared VLANs (like the mesoscale), and
     54 - People provided several good critiques of the GENI Clearinghouse and Portal as implemented.
     56=== AM API ===
     58Aaron solicited updates from the group on the status of [wiki:GAPI_AM_API_V3 AM API v3] implementations:
     59Planetlab is well underway, ProtoGENI will be doing their implementation soon, and Orca will likely implement v3 soon after GEC15.
     60Meanwhile, Omni and the GCF AM will likely be updated in the next few months.
     62==== Action ====
     63 - All developers should work to complete their AM API v3 implementations, and keep the community updated.
     65=== Update() ===
     67We then discussed Jon Duerig's proposal for an Update() method in the AM
     68API ( After a
     69brief discussion, we agreed in principle to Jon's overall proposal. We
     70still need to work through the details, but Update() may be added to the
     71AM API in version 4.
     72In detail: Ilia pointed out that in many instances slivers cannot be
     73modified without losing state. This is why Jon's proposal calls for a
     74state guarantee in the
     75manifest RSpec. We may also want some kind of default guarantee by
     76sliver type in the Ad RSpec.
     77Ilia removed his objection to Update() taking a full RSpec, as long as
     78translating the RSpec into NDL does not require a stateful translator.
     80==== Actions ====
     81 - Jon Duerig will flesh out his Update() proposal for posting on the GENI wiki
     82 - All developers should read and comment on the Update() proposal
     84=== Stitching ===
     86We then moved on to [wiki:GeniNetworkStitching stitching]. First, we
     87talked about the possibility of a GENI stitching demo between rack
     88varieties. We agreed that this seems possible: probably starting with a
     89rack-to-rack demo within the GPO lab, but then perhaps a demo going
     90among RENCI, Starlight, MAX, and ProtoGENI Utah. The timing of this demo
     91depends very much on other tasks for the rack teams, and will likely be
     92after GEC15.
     93ExoGENI expects to be able to first consume but then also produce a VLAN
     94tag for stitching. Currently InstaGENI only produces tags (it cannot
     95consume). So a demo where InstaGENI produces a tag and ExoGENI consumes
     96it might be a first step. Rob believes it won't be hard for InstaGENI to
     97also be a consumer of VLAN tags. Ilia warned that there are several
     98layers of work at ExoGENI to make this work, pushing the timing for such
     99a demo into December.
     101==== Actions ====
     102 - InstaGENI will implement accepting a specified VLAN tag on a link using the stitching extension
     103 - ExoGENI will implement both accepting and producing a VLAN tag for a link terminating on a particular port on some non-AM local switch
     104 - We will plan a rack to rack demo within the GPO lab for November/December.
     106Rob then expressed concern that the stitching workflow logic is too
     107complex to implement in every tool. We agreed there should be a library
     108or service to encapsulate this logic. This service should not actually
     109submit requests to aggregates, but only determine the order of requests,
     110and help pass tags from earlier manifests into later requests in the
     111workflow. We also noted that negotiation makes this component complex.
     112We decided that the stitching extension in the Ad RSpec should be
     113explicit about whether the aggregate can be a producer of labels, a
     114consumer, or both. Rob commented that he has a path computation service
     115he could share. Rob also suggested that such a service should have a
     116function allowing tools to pre-cache information about the sets of nodes
     117that can be connected with different kinds of connections, to simplify
     118graphical tools.
     120==== Actions ====
     121 - Rob will supply his path computation service to Tom Lehman and Aaron
     122 - Tom Lehman and Xi will propose a modification to the stitching extension to advertise at each aggregate whether a given Link can produce or consume labels, or both
     123 - ISI/MAX and the GPO will continue plans for a workflow library and service
     125=== Shared VLANs ===
     127There is an RSpec extension now for specifying that requested nodes
     128should be connected to a pre-existing shared VLAN
     129( We noted that
     130the AMs do not yet support the schema location, nor the Ad
     131RSpec extension version. We then discussed common naming of shared
     132VLANs. We agreed these should be URNs, of the form
     133`urn:publicid:IDN+<authority>+vlan+<label not specific tag>`. This global
     134name may resolve into different tags at different aggregates. For
     135example, the mesoscale is not always 1750. Note that not all such shared
     136VLANs go across aggregates - some might be used to connect an aggregate
     137to the local campus. We also noted that some shared VLANs are Openflow
     138controlled in parts, but not at every switch or aggregate (like the
     139mesoscale), and others are not Openflow controlled at all.
     141We discussed the utility of a shared registration and lookup service,
     142for finding these shared vlan labels, and for translating from the label
     143to the AM-local VLAN tag. The tag has a description, plus perhaps other
     144metadata. Then it has some per-aggregate data (local tag, FOAM URL if
     145applicable, etc. We agreed that for now, a global wiki to track shared
     146VLANs would be sufficient.
     148We also agreed that aggregates should advertise within the shared VLAN
     149extension some extra information for each VLAN: the local FOAM URL, if
     150FOAM is required, and maybe other items. We need to add to the extension
     151attributes for that information.
     153Rob then asked about what special authorization might be needed for
     154access to shared VLANs. Jeff argued that this is not necessary - this is
     155an aggregate policy question. Aggregates may have special local policies
     156for requesting such resources, but we will not try to describe that
     157policy in RSpecs. An aggregate might choose to mark up the advertisement
     158RSpec to indicate that certain resources have special access policies,
     159with perhaps a URL for more information.
     161We then asked about how we allocate labels within these shared VLANs (IP
     162addresses, ether types, etc). Currently, this is coordinated via a wiki
     163page. Do we need something more formal? Rob commented that this is
     164similar to Planetlab's port number reservation problem. Sarah suggested
     165that a simple aggregate manager for allocating strings like this would be sufficient.
     166Jeff noted that this becomes particularly important when a slice wants
     167to offer a service to other slices. We also noted that if we go down the
     168SDN path (as discussed at the SDN session), then this is not a problem.
     169And currently, we don't have a problem. But if we grow a lot without the
     170proposed SDN approach, then we will need something more formal For now,
     171we agreed to table this.
     173==== Actions ====
     174 - ExoGENI and InstaGENI will modify their AMs to support the new schema location for the shared VLANs extension
     175 - ExoGENI and InstaGENI will support the shared VLANs Ad extension
     176 - Jon Duerig will add to the shared VLAN Ad extension information on the FOAM URL, and perhaps other attributes
     177 - GPO will stand up a Shared VLANs wiki page (or similar)
     178 - GPO will publish a URN for the mesoscale shared VLAN on that page
     179 - ExoGENI and InstaGENI will add to that wiki other shared VLANs, and AM-local information on the mesoscale VLAN
     181=== Portal/Clearinghouse ===
     183Several people then asked questions about how authorization works in the
     184[wiki:GEC14Agenda/ClearinghouseAndPortal new portal and clearinghouse],
     185particularly with respect to proxy aggregates. No specific actions came
     186out of this discussion, but the GPO agreed to work on the concerns from
     187the community.
     189The clearinghouse generates experimenter keys, and stores the
     190experimenter's private keys. The portal is a privileged client of the clearinghouse, and is authorized to
     191get your private key and act on your behalf when talking to aggregates.
     192(Experimenters may also download their certificate and key, and never
     193use the portal). In addition, the proxy aggregates that the GPO is
     194building are also privileged clients of the clearinghouse, and are
     195authorized to retrieve your keys from the clearinghouse, and act as the
     196experimenter when talking to aggregates. Jeff, Rob, and Prateek
     197expressed concerns with this approach.
     198 - In the name of protecting naive users, all users are required to give up control of their private keys. There should be a way for more advanced users to retain control of their private keys - both for normal use of the Clearinghouse and AM APIs, and for use with proxy aggregates.
     199 - Only tools that run local to the experimenter and are explicitly authorized by the experimenter should be able to identify themselves as the experimenter in the AM API. The portal and proxy are not local. A proxy should identify itself as a proxy.
     200 - Tools that are not local to the experimenter should have their own keys.
     201 - Only privileged proxies are currently supported. There should be a way for an experimenter to authorize a proxy aggregate, and for that proxy to identify the 'real' experimenter when talking to the aggregate (see This requires something like a 'Speaks For' assertion, signed by the experimenter.
     202 - Currently, the portal tool only works with experimenters with accounts at the GENI Clearinghouse identity provider. Rob would like it to be available to ProtoGENI users directly.
     204Several solutions to these critiques were discussed, but nothing was
     205resolved. Jeff and Prateek suggested an ABAC style 'Speaks For'
     206assertion, that an experimenter could sign and grant to a tool,
     207particularly to a proxy aggregate. Rob suggested developing some
     208Javascript that could run in a browser, and could retrieve an
     209experimenters password protected private key (either from a server or a
     210local file), and sign statements on behalf of the experimenter. In
     211particular, this would allow an experimenter to sign a 'Speaks For'
     212assertion with some short expiration, without having to locally manage
     213their private key, if the experimenter doesn't want to do so. Jeff
     214suggested a button in the portal where the experimenter explicitly
     215grants permission for the proxy and/or portal to 'Speaks For' them
     216(again, with some short expiration time.
     218==== Action ====
     219 - The GPO will consider ways to address these critiques.
    45221== Background Reading ==
    46222=== Coding Sprint ===