[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [bdxr] RE: Update on IEEE P2302 Intercloud WG
Kenneth, I think we agree on much of this. Also, the terminology wiki seems a helpful tool for identifying how the different concepts and terms map onto one another. I don’t think we have those mappings quite right yet, and will do some edits when I get a chance. I may also try doing a table for easier reading of how terms map across the BDXR / Internet / Intercloud glossaries. As we’re both observing, their requirements for ‘Profiles’ of resources (CPU, storage, memory) are fairly different from ours; any convergence there is likely further away. On the Discovery/Metadata aspects however, I think the gap may be smaller than you suppose. I read the SIIF document differently from you as regards definitions of Roots/Resource Catalogs (i.e. SMLP equivalents). You read it as implying “the entire metadata ‘catalogues’ [being] replicated between clouds”. That’s not so (see pg 5, para 5). The replicated Resource Catalogs are NOT the aggregated Profile Metadata, as I read it – they are the Locator information. The distinction between Roots and Resource Catalogs is about creating global interoperability/ discoverability in a world of multiple (and multi-tiered) SML registries/communities. This relates to the different classes of actors (numbered 3, 4 and 5) in my earlier email about service profile registrar models. Another point to clarify: I’m not suggesting we consider their model for replication of Roots – rather, possibly, the reverse. I agree with you that if (as seems likely) our requirements can be met by a DNS-based system, then we should continue in that direction. As you observe, SIIF points towards a new, P2P rather than hierarchical model for replication of Roots. But it’s not clear to me that this follows from their requirements. Or even if it does, I suspect that the protocol for propagation could be separated from data/record model and trust issues. The robustness of the DNS system is not I think something to be discarded lightly. I suspect that the DNS/NAPTR model we’re working to define might well work for SIIF, even if there’s a need for a P2P/XMPP-based propagation model further out. Btw, some might ask: what’s the point? I think we’re already seeing how some of the BDXR requirements relating to Trust, Security and Governance go fairly deep in terms of the architecture of the Internet itself (e.g. IETF references in Dale’s emails!). If we find opportunities to align with initiatives at that level (under IETF/IEEE), then I think we will be better able to focus on solving problems at the business application level, and see BDXR standards more widely adopted. Best, Roger From: bdxr@lists.oasis-open.org [mailto:bdxr@lists.oasis-open.org] On Behalf Of Kenneth Bengtsson Hi Roger Thanks for sharing this. Having read through the IEEE document I agree with you that the term "Intercloud" cannot be used interchangeably here. The IEEE document speaks specifically about cloud computing, where I think we use the term "cloud" in a more broad sense referring to networks and infrastructures in general. I think it's a very interesting document, especially because the question (at a very high level) they are trying to solve is somewhat similar to ours: "How do I reach something on a different cloud or network from where I am". However, their more specific requirements of being able to share specific computing resources (CPU, storage, memory...) across individual cloud computing environments seem to me to have a very different complexity than our requirements. The overall concept of having "Intercloud Root Providers" (chapter 5.1) as shared registries between "clouds" seem to map fairly well with the SML concept, though they want the root providers to host "Resource Catalogues" (which I guess can be compared with SMP) and having these catalogues replicated between roots, which is fundamentally different from the multilayered SMLP design. I see the SMP (as a concept) more coupled with the gateway than with the SML, and I am not sure we would have an interest in having the entire metadata "catalogues" replicated between clouds. As I understand the document, they want to create a new specification for the "Intercloud Roots" and having the roots "governed in a similar way in which DNS and Top Level Domains by an organization such as ISOC or ICANN.". If our requirements can be covered by existing standards such as DNS, then I think we may be better off continuing that direction. It will in any case be very interesting to the IEEE project and to identify potential common denominators and reusable architectures. Best regards, Kenneth From: Roger Bass <robass1@earthlink.net> All, I just participated in the latest bi-monthly meeting of the IEEE Intercloud WG P2302, and wanted to send this update. (There is a separate WG P2301 effort on Cloud Portability and Interoperability Profiles – less active for now). Thinking back to some discussions we had around the new BDXR charter, I think there’s skepticism on both sides as to how close the relationship is between this TC’s efforts and theirs (or rather, whether “Intercloud” terminology makes sense for us at all). And it’s certainly true that the IEEE efforts are more focused at lower-level “cloud / network” layer activities, e.g. VM portability. That said, it does seem to me that the elements of their architecture may map fairly exactly onto ours. The specific requirements clearly differ for at least some of those layers or elements. But I wonder whether there might not be a basis for convergence at some point. For the Discovery layer in particular, and perhaps also the Trust and Dialog (aka Connect) layers, I wonder if there might not even be a basis for convergence sooner rather than later. On Profiles and Messaging, any convergence seems probably further away. The IEEE efforts are still at a fairly early stage, and are soliciting volunteers to take ownership of (or at least contribute to) different sections of their draft standard document. I will upload that document to the TC repository, but have copied below the relevant sections from the table of contents. Without making any commitments, I have mentioned to the IEEE WG the possible overlaps I see on section 5, and sections 6.6-6.10. (The ‘Connect’ protocol may further relate to 6.2-6.5, but perhaps only if the salient features can be separated from the underlying protocol, since P2302 seems fairly committed to XMPP). Consideration of any formal liaison would seem premature. But some TC members might like to review the P2302 draft document. And as our work in BDXR progresses, I look forward to helping make further connections between the two, as may be appropriate. Best, Roger IEEE P2302™/D0.2 Draft Standard for Intercloud Interoperability and Federation (SIIF) EXTRACT FROM TABLE OF CONTENTS 4. Cloud to Cloud Interoperability and Federation - Intercloud ..................................................................... 2 4.1 Introduction to Intercloud - Background and Concept ........................................................................ 2 4.2 Introduction to Intercloud - Topology and Protocols........................................................................... 3 5. Intercloud Topology Elements ................................................................................................................... 4 5.1 Intercloud Root .................................................................................................................................... 4 5.2 Intercloud Exchanges........................................................................................................................... 5 5.3 Intercloud Capable Individual Clouds – Intercloud Gateways ............................................................ 6 6. Intercloud Protocols and Interoperability ................................................................................................... 6 6.1 Base Intercloud Protocols - XMPP ...................................................................................................... 7 6.2 Intercloud Protocols Services Framework – XEP 0244 and XWS4J................................................... 8 6.3 Intercloud Protocols Encryption and Authentication – TLS and SASL and SAML ............................ 8 6.4 Intercloud Exchange Service Invocation – XMPP .............................................................................10 6.5 Intercloud Protocol - Presence & Dialog with XMPP ........................................................................11 6.6 Intercloud Trust Model .......................................................................................................................12 6.7 Intercloud Identity and Access Management – SAML, XACML ......................................................13 6.8 Intercloud PKI Certificates Deployment ............................................................................................15 6.9 Intercloud Exchange Service Discovery – XMPP Based RDF and SPARQL approach ....................16 6.10 Intercloud Resources Catalog Deployment ......................................................................................22 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]