[dcifp-bof] Group charter proposal

Tue Aug 17 07:49:20 CDT 2010

Alan,

thanks for your input.

Am 11.08.2010 um 15:47 schrieb Sill, Alan:

> This sounds very interesting, and I look forward to being able to talk with you and other members of the group about it in detail. At the moment, I am on a short vacation with my family.

I hope to see you in Brussels :-)

> Meanwhile, may I suggest that you discuss the security aspects of this proposal with our area director for Security, Jens Jensen?  We have experience with a wide variety of security protocols and methods, and I don't personally think that you should prejudice the direction of the group by too early a selection of technology or protocol at this point.

Good idea. I didn't want to do so anyway, and I am not really a security expert...

Jens: can you maybe comment?

Best,
Alexander

> On Aug 11, 2010, at 7:58 AM, Alexander Papaspyrou <alexander.papaspyrou at tu-dortmund.de> wrote:
> 
>> Craig,
>> 
>> thanks for your input -- I will comment inline.
>> Am 10.08.2010 um 21:28 schrieb craig.a.lee at aero.org:
>> 
>>> 1) The word "profile" only occurs once (in one of the Seven Questions).  If I understand correctly, the goal of DCIfed is to produce a profile of existing standards that supports DCI federation. I assume that the DCI Fed Spec will be this profile.
>> 
>> Well, yes and no. We will produce a specification, which probably is close to what profiles have been in the past, but with extensions and/or changes here and there. Since this is not entirely clear at the moment how "profilish" we are going to be, I left this aside a bit in order to not fixate the group to the profile path.
>> 
>>> 2) While we certainly want to evaluate existing OGF standards for this purpose, I think we'd also want to consider standards from other SDOs, e.g., OVF from DMTF, etc.
>> 
>> Agreed. I will add the appropriate acronyms. Is it ok for you to add OVF to the list in the Purpose and Scope section, and just name the others in Q4? I am not entirely sure how CDMI would relate (as another thing with a tighter relation to OGF through OCCI)...
>> 
>>> 3) The topic of the Informational Doc is not explicitly stated.  I assume this will present the group's analysis and justifications for what to put in the Spec and what to leave out.  This analysis should also include a "gap analysis" in case there are no appropriate candidate standards for necessary functionality XYZ.   Another possibility is that two specs exist for different functions, but they are incompatible in some way.
>> 
>> The informational Dokument is supposed to contain the use cases. Maybe I don't fully understand what you mean here. Regarding the second part of the question, I am fine with two specs, but I would like to base the pros and cons on the use case analysis.
>> 
>>> 4)  I think the two initial Usage Scenarios are fine.  I would leave the door open, however, for additional scenarios.  See (5).  We can't do every usage scenario, but there might be other important ones.
>> 
>> Sure. I will add a statement on this.
>> 
>>> 
>>> 5)  Security is only mentioned tangentially.  Federating DCIs will mean federating their security models.  Will DCI Fed simply say that everybody must use the same security infrastructure, or will it specify how different security mechanisms can nonetheless interoperate?  As I have said elsewhere, ID mgmt and role-based authorization in VOs to support business-to-business and "inter-cloud" apps will be a central issue.
>> 
>> Hm, that's a difficult question, especially since I am not a security expert. IIRC, there has been some discussion regarding security wrt. the possibility of different renderings (WS-*, REST, etc.), but I don't think that there has been more discussion on that. We could talk to the Security area people, though...
>> 
>> From a business perspective, it should be secure, but simple. We might want to take a look at HPC-BP, and maybe have a look at the hot stuff out there (tm), such as OAuth and friends. Personally, I prefer simple security solutions, and I don't consider certificates as a good example for such :-)
>> 
>>> 6)  Besides usage scenarios, we might also want to consider federation scenarios.  Pair-wise federation might be the easiest to manage.  A "hub and spoke" model with a centralized federation hub might be the next step up.  A complete p2p federation model might be the most general and most complete approach (and most difficult). I'm not saying that we have to consider these things, but in the past, OGF has been accused of trying to "boil the ocean" by defining "complete architectures" that have to be adopted in totality in order to do anything.  This makes adoption very difficult.  If there are some simple federation scenarios that require fewer and simpler standards to achieve, that nonetheless addresses a significant segment of users that need federation, then we might want to identify that as a specific profile.
>> 
>> So in the project I am managing here in Germany, we build on pair-wise federation. The good thing is that, given that pair-wise works, you automatically get p2p for free (it's just an algorithmic question then, not a protocol-based). We probably should stay away from "co-allocation"-style federation, which requires distributed transaction semantics, which comes close to boiling the ocean.
>> 
>> IMHO, it would be a great leap forward if we could get pair-wise federation working for a few scenarios. If then people want more, fine -- you can always add an additional layer on top of that for more complex scenarios.
>> 
>>> 7)  "Liaisons" are not mentioned anywhere.  In order to maximize the quality and impact of this group's work, there should be specific liaisons with other groups, e.g., CSA, DMTF, GICTF, etc.  This work will also be of interest to Cloud-Standards.org.  Besides helping to refine the usage scenarios and federation scenarios, this will also help get earlier and wider visibility for this group's work.  Perhaps we could even get some additional people to help with the real work. The OGF Board and GFSG should help in this liaison function.
>> 
>> Agreed. Should I mention them in Q4, or do you want a more clear statement elsewhere as well? When would be a good time to approach them?
>> 
>> I would really appreciate if the Board and/or GFSG could take care of that.
>> 
>> Best,
>> Alexander
>> 
>>> At 2:57 PM +0200 8/10/10, Alexander Papaspyrou wrote:
>>>> Folks,
>>>> 
>>>> after a rather long period of silence, covering holidays, the epic search for a co-chair and secretary, and document polishing, I am happy to send around the final draft for the group charter.
>>>> 
>>>> Major changes include the fixation to the "Management" area (thanks Andre), the name change (as discussed in Chicago), the contribution to the reference model (thanks Craig), and volunteers for chair and secretary positions (BIG thanks, Gary and Andrew).
>>>> 
>>>> Here you go:
>>>> --8<-- snip --8<--
>>>> Charter for DCIfed-WG
>>>> 
>>>> Group Abbreviation
>>>> DCIfed-WG
>>>> 
>>>> Area
>>>> Management
>>>> 
>>>> Group Leadership
>>>> Alexander Papaspyrou    alexander.papaspyrou at tu-dortmund.de     Chair
>>>> Gary Mazzaferro.        garymazzaferro at gmail.com                Chair
>>>> Andrew Edmonds          andrewx.edmonds at intel.com               Secretary
>>>> 
>>>> Group Summary:
>>>> The purpose of this group is the development and spread-out of a practical set
>>>> of protocols and formats to interface between different types of Distributed
>>>> Computing Infrastructures in a secure, SLA-managed manner. We will focus on the
>>>> federation of such DCIs for two usage scenarios: (1) delegation of workload from
>>>> one domain into the other, covering job description, submission, and monitoring;
>>>> and (2) leasing of resources, including resource definition, provisioning, and
>>>> monitoring. The work of this group will base on existing protocols and standards
>>>> in order to ensure fast delivery and highest possible synchronization with other
>>>> groups.
>>>> 
>>>> 
>>>> Charter Focus / Purpose and Scope:
>>>> Infrastructure federation is becoming an increasingly important issue for modern
>>>> Distributed Computing Infrastructures (DCIs): Dynamic elasticity of quasi-static
>>>> Grid environments, incorporation of special-purpose resources into commoditized
>>>> Cloud infrastructures, cross-community collaboration for increasingly diverging
>>>> areas of modern e-Science, and Cloud Bursting pose major challenges on the
>>>> technical level for many resource and middleware providers. Especially with
>>>> respect to increasing cost of operating data centers, the intelligent, yet
>>>> automated and secure sharing of resources is a key factor for success.
>>>> 
>>>> The DCI Federation Working Group (DCIfed-WG) will, after initial research,
>>>> deliver a specification for the automatically negotiated, SLA-secured,
>>>> dynamically provisioned federation of resources and for Grid- and Cloud-type
>>>> infrastructures. The scope of the specification will include (1) the delegation
>>>> of workload from one domain into the other, covering job description,
>>>> submission, and monitoring; and (2) leasing of resources, including resource
>>>> definition, provisioning, and monitoring.
>>>> 
>>>> This group will focus on the creation of a specification for compute-centric
>>>> federation. This is both necessary and sufficient to allow for interoperable
>>>> implementations.
>>>> 
>>>> DCIfed aims to address the needs of different stakeholders:
>>>> * Providers to incorporate dynamic elasticity into their DCI based on current
>>>> demand;
>>>> * Aggregators to provide a simplified view on infrastructure federations;
>>>> * Integrators to offer advanced management services beyond the boundaries of
>>>> current infrastructure types;
>>>> * Vendors to use DCI-abstracted data centers in an application-driven,
>>>> on-demand fashion;
>>>> * Users to benefit from otherwise separate infrastructures in a coherent,
>>>> unified, and transparent way.
>>>> 
>>>> The scope will be limited to the high-level federation of DCIs with respect
>>>> to delegation of workload and leasing of resources. This includes means for
>>>> describing, negotiating, and agreeing upon the service provided and consumed by
>>>> the federated systems; the description, submission, and monitoring of workload;
>>>> the definition, provisioning, and monitoring of resources. Data management
>>>> details beyond providing endpoints for transfer are excluded; the same holds for
>>>> network management details beyond the absolute necessities for leasing a
>>>> resource (i.e. providing a publicly accessible IP).
>>>> 
>>>> There are a number of existing standards within OGF which shall serve as basis
>>>> for the full protocol, interface, and data representation documents for DCIfed:
>>>> 
>>>> * WS-Agreement
>>>> * JSDL
>>>> * GLUE
>>>> * OGSA-BES
>>>> * OCCI
>>>> * UR
>>>> 
>>>> 
>>>> Exit Strategy:
>>>> The work of this group will be deemed complete with the finalization of the
>>>> documents.
>>>> 
>>>> 
>>>> Goals/Deliverables:
>>>> Title: DCI Federation Use Cases
>>>> Abstract:
>>>> Use cases for DCI federation, including stakeholders, entities, the
>>>> delegation/leasing lifecycle, and associated management tasks.
>>>> 
>>>> Type: Informal Document
>>>> Milestones:
>>>>   Draft           -- 2010-11 (post-OGF30)
>>>>   Public Comment  -- 2011-03 (pre-OGF31)
>>>>   Publication
>>>> 
>>>> Title: DCI Federation Specification
>>>> Abstract:
>>>> Technical specification of protocols, interfaces, and data representation
>>>> for the DCI Federation specification with one transport rendering.
>>>> 
>>>> Type: Recommendation Document
>>>> Milestones:
>>>>   First Draft     -- 2011-02
>>>>   Second Draft    -- 2011-05 (post-OGF31)
>>>>   Public Comment  -- 2011-07 (pre-OGF32)
>>>>   Publication
>>>> 
>>>> 
>>>> Seven Questions:
>>>> 
>>>> 1. Is the scope of the proposed group sufficiently focused?
>>>> Yes. The group will define a specification on top of existing interfaces and
>>>> over-the-wire formats for the federation of DCI environments. The main focus
>>>> will be to address two compute-centric use cases, namely the delegation of
>>>> workload and the leasing of resources. As far as possible, the group will reuse
>>>> existing standards, integrate them towards a higher-level product, and
>>>> contribute back experiences, implementations, necessary modifications to the SDO
>>>> bodies embracing the specifications in question.
>>>> 
>>>> 2. Are the topics that the group plans to address clear and relevant for the
>>>> Grid research, development, industrial, implementation and/or application
>>>> user community?
>>>> Yes. Current Grid deployments are usually limited to their own domain which---in
>>>> many Service Grid cases---limits the usability of resources within the own
>>>> community. Also, Cloud environments are usually constrained to a single
>>>> provider, not allowing for mix-and-match applications. Sophisticated use cases
>>>> such as elasticity, Grid-Cloud integration, cross-community collaboration, and
>>>> "Cloud Bursting" are highly relevant, yet not supported.
>>>> 
>>>> 3. Will the formation of the group foster (consensus-based) work that would not
>>>> be done otherwise?
>>>> Yes. Current efforts are focusing on atomic aspects, providing no integrated
>>>> profile for the aforementioned use cases. For example, GRAAP addresses the
>>>> description, establishment, and monitoring of SLAs, but provides no
>>>> domain-specific support for DCI federation; OGSA-BES/HPC-BP primarily focuses
>>>> on job submission, but supports no delegation; OCCI Infrastructure provides
>>>> means for IaaS description and provisioning, but not for cross-domain leasing.
>>>> As such, this initiative is unique within OGF and provides an opportunity to
>>>> deliver a strategic technology platform for the integration of the complementary
>>>> Grid and Cloud Computing areas.
>>>> 
>>>> 4. Do the group's activities overlap inappropriately with those of another OGF
>>>> group or to a group active in another organization such as IETF or W3C?
>>>> No. Although the work within the group will heavily base on existing standards,
>>>> especially from within OGF, the integration effort is unique and not interfering
>>>> with other groups' interest. On the contrary, the results from this group will
>>>> provide valuable feedback and additional input to the existing WGs in order to
>>>> drive forward the applicability and quality of their work in a relevant complex
>>>> field application. Interactions towards lower management levels will be closely
>>>> aligned with the efforts in PGI-WG.
>>>> 
>>>> 5. Are there sufficient interest and expertise in the group's topic, with at
>>>> least several people willing to expend the effort that is likely to produce
>>>> significant results over time?
>>>> Yes. The group has already gathered a sufficient number of active contributors
>>>> to deliver the specification within the aspired timeline. Participants comprise
>>>> both the academic and the industrial domain. Also, both the consumer and the
>>>> provider site are represented. A significant amount of existing work can be
>>>> derived from an established project and serve as basis from which consensus
>>>> can be reached. In the BoF session at OGF28, ten out of 24 participants stated
>>>> interest in helping out.
>>>> 
>>>> 6. Does a base of interested consumers (e.g., application developers, Grid
>>>> system implementers, industry partners, end-users) appear to exist for the
>>>> planned work?
>>>> Yes. Several NGIs have stated interest in connecting their national Grids
>>>> through means of DCIfed. Also, ongoing discussion with Cloud providers indicates
>>>> that federation mechanisms are of high interest. Two research projects have
>>>> shown interest in using DCIfed for adding elasticity to their existing Grid
>>>> ecosystem. In addition, the five major resource management systems within German
>>>> D-Grid have expressed their support for DCIfed and will actively contribute to
>>>> the group discussion and implement the outcome specification.
>>>> 
>>>> 7. Does the OGF have a reasonable role to play in the determination of the
>>>> technology?
>>>> Yes. OGF determines standards in the Grid Computing domain. In addition, ongoing
>>>> embracement of Cloud Computing efforts is shown through groups such as OCCI.
>>>> Especially with respect to increasing cost of operating data centers, there
>>>> is a strong interest in intelligent, yet automated and secure sharing of
>>>> resources beyond the boundaries of either paradigm. Moreover, most actors from
>>>> the domain of Grid space are also active in Cloud Computing. The high-level
>>>> interoperation approach of DCIfed will, in addition, significantly add to the
>>>> ongoing efforts on creating a reference model for Distributed Computing
>>>> Infrastructures.
>>>> -->8-- snap -->8--
>>>> 
>>>> Please go through it and flame at your discretion, but do so until
>>>> 
>>>> Friday, August 13, 2010, 12:00pm (noon)
>>>> 
>>>> Whatever comes in, I will massage into the document and send it to GFSG on Monday morning.
>>>> 
>>>> Looking forward to being a real WG!
>>>> 
>>>> Best,
>>>> Alexander
>>>> 
>>>> --
>>>> Alexander Papaspyrou
>>>> alexander.papaspyrou at tu-dortmund.de
>>>> 
>>>> 
>>>> Attachment converted: Macintosh HD:Alexander Papaspyrou 1.vcf (TEXT/ttxt) (020E48A5)
>>>> Attachment converted: Macintosh HD:smime 202.p7s (    /    ) (020E48A6)
>>> 
>> 
>> --
>> Alexander Papaspyrou
>> alexander.papaspyrou at tu-dortmund.de
>> 
>> <Alexander Papaspyrou.vcf>
>> <ATT00001>
> 

-- 
Alexander Papaspyrou
alexander.papaspyrou at tu-dortmund.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Alexander Papaspyrou.vcf
Type: text/directory
Size: 498 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/dcifp-bof/attachments/20100817/d394b76c/attachment.bin 
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4678 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/dcifp-bof/attachments/20100817/d394b76c/attachment-0001.bin 