Re: [dc] Announcing the i2aex BoF

David Harrington <ietfdbh@comcast.net> Thu, 22 March 2012 16:51 UTC

Return-Path: <ietfdbh@comcast.net>
X-Original-To: dc@ietfa.amsl.com
Delivered-To: dc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066CA21F86A0 for <dc@ietfa.amsl.com>; Thu, 22 Mar 2012 09:51:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.019
X-Spam-Level:
X-Spam-Status: No, score=-102.019 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bm8IRjg+JyfB for <dc@ietfa.amsl.com>; Thu, 22 Mar 2012 09:50:55 -0700 (PDT)
Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 414F621F866E for <dc@ietf.org>; Thu, 22 Mar 2012 09:50:55 -0700 (PDT)
Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta09.westchester.pa.mail.comcast.net with comcast id ogow1i0061HzFnQ59gqvqj; Thu, 22 Mar 2012 16:50:55 +0000
Received: from [192.168.1.33] ([71.233.85.150]) by omta14.westchester.pa.mail.comcast.net with comcast id ogqd1i0073Ecudz3agqlo1; Thu, 22 Mar 2012 16:50:55 +0000
User-Agent: Microsoft-MacOutlook/14.14.0.111121
Date: Thu, 22 Mar 2012 12:50:34 -0400
From: David Harrington <ietfdbh@comcast.net>
To: Bhumip Khasnabish <vumip1@gmail.com>, Spencer Dawkins <spencer@wonderhamster.org>
Message-ID: <CB90C8FC.1FE99%ietfdbh@comcast.net>
Thread-Topic: [dc] Announcing the i2aex BoF
In-Reply-To: <CANtnpwiCn5X=hcSfhXObaw7ruFiCFXp87Ryd==sA_+iy1S+kHw@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: apps-discuss@ietf.org, opsawg@ietf.org, cdni@ietf.org, Tsvwg <tsvwg@ietf.org>, dc@ietf.org
Subject: Re: [dc] Announcing the i2aex BoF
X-BeenThere: dc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Data Center Mailing List <dc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dc>, <mailto:dc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dc>
List-Post: <mailto:dc@ietf.org>
List-Help: <mailto:dc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dc>, <mailto:dc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Mar 2012 16:51:07 -0000

Hi Bhumip,

Your input would be more helpful if you did the research to answer the
question your self and prepared a detailed analysis for the community to
review (I.e., write a draft).

Is this similar to dmtf's CIMI? I suggest you read the documents on the
agenda and read the CIMI spec and compare them to see if they are or are
not similar.
My experience has been that DMTF works top-down - they tend to develop and
abstract architecture first and then encourage implementers to develop
detailed specs that fit within the architecture. That sometimes leads to
abstract systems that implementers choose not to implement, because the
architecture is too all-inclusive, or implementers cherry-pick the
features, with the result that different implementations choose different
feature sets and then do not interoperate.

The IETF uses a bottom-up model; we prefer detailed proposals based on
actual experience in the field, and developing highly focused
specifications with a small number of mandatory-to-implement features, to
ensure cross-vendor interoperation. The result can be messy as compared to
a nice top-down architecture, but the IETF has been very successful using
this approach, and the Internet community seems to want to keep using this
approach.

Is the REST interface similar to interfaces being proposed in i2aex? Have
you done a feature comparison between the i2aex proposals and the DMTF
proposals? I have a concern that the DMTF REST interface might be based on
a DMTF abstract architectural model that may or may not actually be used
by operators in real-world deployments. A major part of this BOF is to get
feedback from real-world operators about what bottom=up technologies they
actually use in real-world deployments to mitigate the problems of CDN and
DC optimization, and whether operators would benefit from IETF
standardization of these bottom-up optimization approaches.

Ultimately, the i2aex BOF is about understanding whether IETF should
develop extensions to Internet protocols to meet CDN and DC optimization
needs when running over the Internet. It is not about developing an
abstract all-encompassing architecture for managing clouds. So I have
doubts about how much actual overlap exists between the DMTF proposals and
the i2aex proposals.

I do encourage people involved in this effort to consider whether there is
overlap, but they should avoid being sidetracked into some mission that is
not an IETF or i2aex BOF mission.

My $.04 as Responsible AD for this BOF.

--
David Harrington
Director, Transport Area
Internet Engineering Task Force (IETF)
Ietfdbh@comcast.net
+1-603-828-1401





On 3/21/12 1:50 PM, "Bhumip Khasnabish" <vumip1@gmail.com> wrote:

>Hi Spencer,
> 
>Is this similar to Cloud Infrastructure Management Interface (CIMI) Model
>and REST Interface over HTTP An Interface for Managing Cloud
>Infrastructure (http://dmtf.org/standards/cloud)?
> 
>What is the trigger for this?!
> 
>Thanks for clarifying.
> 
>Best.
> 
>Bhumip
> 
> 
>
>
>On Wed, Mar 21, 2012 at 1:05 PM, Spencer Dawkins
><spencer@wonderhamster.org> wrote:
>
>Hi all,
>
>David Harrington asked me to act as BoF Shepherd for the
>Infrastructure-to-application Information Exposure (i2aex) BoF, and I
>wanted to make sure that a broad community of interest was aware of this
>BoF, especially since the BoF is scheduled for Monday, Afternoon Session
>1, at 1300 PM.
>
>Preliminary discussion has been going on for some time now on the
>altoext@ietf.org mailing list, mainly among people in some way involved
>in the standardization the ALTO protocol. In order to have a conversation
>that's as productive as possible in Paris, we would really like to invite
>people who are involved on different sides of the same problem to bring
>their perspective as well.
>
>Here's a short description, with the usual pointers. Follow-ups to
>altoext@ietf.org, please.
>
>The goal of the (non-WG-forming) BoF is to investigate infrastructure-
>to-application information exposure and communications requirements in
>fully controlled (e.g., data centers) or partially controlled
>environments (e.g. CDN). Existing mechanisms such as SNMP, IGP, BGP and
>other protocols that monitor and manage infrastructure may reveal much
>if not all of the possibly required information, but are typically only
>accessible to the operators of the network infrastructure. CDNs and data
>center applications have some requirements to operate over the Internet,
>possibly between administrative domains. On the other hand, the ALTO
>protocol was initially designed to address peer-to-peer application
>requirements, but was designed to be extensible and could be quite
>easily adapted to export the pieces of information that CDN and data
>center applications would benefit from.
>
>The BoF will thus primarily seek an answer to the following questions:
>
> + do CDN and data center applications require (or benefit in a
>   significant way from) accessing to information that cannot be made
>   available through existing mechanisms in a practical way?
>
> + is an extension to the ALTO protocol (or to any other protocol) a
>   viable way to address such requirements?
>
>Additional information about the topic is available on the BoF wiki
>entry: http://trac.tools.ietf.org/bof/trac/#Transport
>
>The provisional agenda for the meeting is online at:
>http://www.ietf.org/proceedings/83/agenda/agenda-83-i2aex.txt
>_______________________________________________
>dc mailing list
>dc@ietf.org
>https://www.ietf.org/mailman/listinfo/dc
>
>
>
>
>
>