From wwwrun@ietfa.amsl.com Tue Feb 14 11:24:53 2012 Return-Path: X-Original-To: sop@ietf.org Delivered-To: sop@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 6FFE421E801B; Tue, 14 Feb 2012 11:24:53 -0800 (PST) From: IETF Secretariat To: IETF Announcement list Cc: sop@ietf.org, "Ashish Dalela" , "Monique Morrow" Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20120214192453.6FFE421E801B@ietfa.amsl.com> Date: Tue, 14 Feb 2012 11:24:53 -0800 (PST) Subject: [sop] New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 19:24:53 -0000 A new IETF non-working group email list has been created. List address: sop@ietf.org Archive: http://www.ietf.org/mail-archive/web/sop/ To subscribe: https://www.ietf.org/mailman/listinfo/sop Purpose: Cloud services need to interoperate across cloud providers, service vendors and private/public domains. To enable this interoperability, there is need for a standard wire-format for exchanging service information. This mailing lists is for discussing protocols, data formats and server descriptions formats that allow cloud services to be discovered and used across private and public domains. Using these, it would be possible to interoperate diverse APIs and cloud services across service providers, service vendors and service users. For additional information, please contact the list administrators. From mmorrow@cisco.com Thu Feb 16 06:09:49 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB7621F8787 for ; Thu, 16 Feb 2012 06:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.746 X-Spam-Level: X-Spam-Status: No, score=-9.746 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] 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 DmWR5GSuct0j for ; Thu, 16 Feb 2012 06:09:44 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1C07121F877D for ; Thu, 16 Feb 2012 06:09:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mmorrow@cisco.com; l=13262; q=dns/txt; s=iport; t=1329401383; x=1330610983; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=/s0A+N2fvRarP8i0zvtAre2/eBa1ec6XP//hR60HAvc=; b=YL99fp18MytN1zn/aVIbpI9h2rHeLQHmkbj2mnarXe7XRPWQhmmgc1az RJvP8PNlr5nxyBzIYJ5KBm/rVz6M27FDPNqtHZ3EWT7Minb8vBo2mr2Rk t33hVo21Ve8DDsM/Zp4ctZeg98KCNaQDoo7BNPOHfbcR0hhUwd1gI9dEj E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUIAJUNPU+Q/khN/2dsb2JhbABEgk2FLpgMiBSHYGaBB4FyAQEBAwEBAQEPASoxBAcFBwYBCBEEAQEBDBcELh8IAQgBAQQBDQUJGYddCZojAZ5Ci3EBBAMYCAICMgUBCAKDTgxAAQIEAwQFAgUDA4MqBJU3kTqBLw X-IronPort-AV: E=Sophos;i="4.73,429,1325462400"; d="scan'208,217";a="66300527" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 16 Feb 2012 14:09:41 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1GE9fpk004544; Thu, 16 Feb 2012 14:09:41 GMT Received: from xmb-ams-110.cisco.com ([144.254.74.85]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Feb 2012 15:09:41 +0100 Received: from 10.55.91.149 ([10.55.91.149]) by XMB-AMS-110.cisco.com ([144.254.74.85]) via Exchange Front-End Server email.cisco.com ([144.254.231.96]) with Microsoft Exchange Server HTTP-DAV ; Thu, 16 Feb 2012 14:09:41 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 16 Feb 2012 15:09:40 +0100 From: Monique Morrow To: Ping Pan , Message-ID: Thread-Topic: [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services Thread-Index: AczstJ9umqcu0xfm9kmNRGejcKEBRg== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3412249781_552603" X-OriginalArrivalTime: 16 Feb 2012 14:09:41.0709 (UTC) FILETIME=[A0736FD0:01CCECB4] X-Mailman-Approved-At: Thu, 16 Feb 2012 06:25:31 -0800 Cc: sdnp , sop@ietf.org Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 14:09:49 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3412249781_552603 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Guys Please join the SOP mailer List address: sop@ietf.org Archive: http://www.ietf.org/mail-archive/web/sop/ To subscribe: https://www.ietf.org/mailman/listinfo/sop TIA Monique On 2/14/12 10:45 PM, "Ping Pan" wrote: > Where does OpenStack Quantum fit? > > OpenStack Quantum is to have agents in controllers and networking devices for > the purpose of better transport. This is well within the goal of SDN. > > Ping > > On Tue, Feb 14, 2012 at 1:37 PM, Robert Raszuk wrote: >> >> Actually I think those are quite separate problem spaces. >> >> SOP aim to address the requirement of cloud to cloud communication (hybrid or >> multi-domain). The way I think about this is how to standardize and >> synchronize OpenStack to OpenStack instrumentation signaling. The next step >> would be to actually also provide cloud to cloud communication layer. Simple >> example: How to launch N VMs in various data centers to be part of common >> resources for customer X. >> >> On the contrary SDNx seems to me of totally different caliber. One way to >> look at this is what and how we could use APIs exposed by existing network >> control planes to define and accomplish new network services. I quite do not >> see current network element control planes nor their APIs as much relevant to >> cloud services. >> >> My own personal view ;) >> >> Regards, >> R. >> >> >>> I'd like to get some clarification (from anyone who might know or >>> have an opinion) on how this would interact with/be distinct from any >>> of the SDNP (or whatever name we decide upon) proposed work. Is this >>> duplication/people striking out on their own from the nascent SDNP >>> effort, a companion effort that became clear as we have begun >>> segmenting the problem space, or something else entirely? Since this >>> is the first I've heard of the list, I'm thinking it's a separate >>> effort, but I figured I would raise the topic for discussion. >>> >>> Thanks, >>> >>> Wes George >>> >>> -----Original Message----- From: ietf-announce-bounces@ietf.org >>> [mailto:ietf-announce-bounces@ietf.org >>> ] On Behalf Of IETF >>> Secretariat Sent: Tuesday, February 14, 2012 2:25 PM To: IETF >>> Announcement list Cc: sop@ietf.org; Monique Morrow Subject: New >>> Non-WG Mailing List: sop -- Service Orchestration and Desciption for >>> Cloud Services >>> >>> >>> >>> A new IETF non-working group email list has been created. >>> >>> List address: sop@ietf.org Archive: >>> http://www.ietf.org/mail-archive/web/sop/ >>> To subscribe: >>> https://www.ietf.org/mailman/listinfo/sop >>> >>> >>> Purpose: Cloud services need to interoperate across cloud providers, >>> service vendors and private/public domains. To enable this >>> interoperability, there is need for a standard wire-format for >>> exchanging service information. This mailing lists is for discussing >>> protocols, data formats and server descriptions formats that allow >>> cloud services to be discovered and used across private and public >>> domains. Using these, it would be possible to interoperate diverse >>> APIs and cloud services across service providers, service vendors and >>> service users. >>> >>> For additional information, please contact the list administrators. >>> _______________________________________________ IETF-Announce mailing >>> list IETF-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-announce >>> >>> >>> This E-mail and any of its attachments may contain Time Warner Cable >>> proprietary information, which is privileged, confidential, or >>> subject to copyright belonging to Time Warner Cable. This E-mail is >>> intended solely for the use of the individual or entity to which it >>> is addressed. If you are not the intended recipient of this E-mail, >>> you are hereby notified that any dissemination, distribution, >>> copying, or action taken in relation to the contents of and >>> attachments to this E-mail is strictly prohibited and may be >>> unlawful. If you have received this E-mail in error, please notify >>> the sender immediately and permanently delete the original and any >>> copy of this E-mail and any printout. >>> _______________________________________________ SDNP mailing list >>> SDNP@lucidvision.com http://lucidvision.com/mailman/listinfo/sdnp >>> >>> >>> >> >> _______________________________________________ >> SDNP mailing list >> SDNP@lucidvision.com >> http://lucidvision.com/mailman/listinfo/sdnp >> > > > > _______________________________________________ > SDNP mailing list > SDNP@lucidvision.com > http://lucidvision.com/mailman/listinfo/sdnp --B_3412249781_552603 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration= and Desciption for Cloud Services Guys

Please join the SOP mailer


List address: sop@ietf.org<= /a>
Archive: http://www.ietf.org/mail-archive/web/sop/
To subscribe: https://www.ietf.org/mailman/listinfo/sop


TIA

Monique


On 2/14/12 10:45 PM, "Ping Pan" <pi= ng@pingpan.org> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Where does OpenStack Quantum fit?

OpenStack Quantum is to have agents in controllers and networking devices f= or the purpose of better transport. This is well within the goal of SDN.

Ping

On Tue, Feb 14, 2012 at 1:37 PM, Robert Raszuk <robert@raszuk.net> wrote:
<= SPAN STYLE=3D'font-size:11pt'>
Actually I think those are quite separate problem spaces.

SOP aim to address the requirement of cloud to cloud communication (hybrid = or multi-domain). The way I think about this is how to standardize and synch= ronize OpenStack to OpenStack instrumentation signaling. The next step would= be to actually also provide cloud to cloud communication layer. Simple exam= ple: How to launch N VMs in various data centers to be part of common resour= ces for customer X.

On the contrary SDNx seems to me of totally different caliber. One way to l= ook at this is what and how we could use APIs exposed by existing network co= ntrol planes to define and accomplish new network services. I quite do not s= ee current network element control planes nor their APIs as much relevant to= cloud services.

My own personal view ;)

Regards,
R.


<= SPAN STYLE=3D'font-size:11pt'>I'd like to get some clarification (from anyone = who might know or
have an opinion) on how this would interact with/be distinct from any
of the SDNP (or whatever name we decide upon) proposed work. Is this
duplication/people striking out on their own from the nascent SDNP
effort, a companion effort that became clear as we have begun
segmenting the problem space, or something else entirely? Since this
is the first I've heard of the list, I'm thinking it's a separate
effort, but I figured I would raise the topic for discussion.

Thanks,

Wes George

-----Original Message----- From: i= etf-announce-bounces@ietf.org
[mailto:ietf-announce-bounc= es@ietf.org <mailto:i= etf-announce-bounces@ietf.org> ] On Behalf Of IETF
Secretariat Sent: Tuesday, February 14, 2012 2:25 PM To: IETF
Announcement list Cc: sop@ietf.org; Monique Morr= ow Subject: New
Non-WG Mailing List: sop -- Service Orchestration and Desciption for
Cloud Services



A new IETF non-working group email list has been created.

List address: sop@ietf.org Archive:
http://www.ietf.org/mai= l-archive/web/sop/ <http://www.ietf.org/mail-archive/web/sop/>  To subscribe:
https://www.ietf.org/ma= ilman/listinfo/sop <https://www.ietf.org/mailman/listinfo/sop>

Purpose: Cloud services need to interoperate across cloud providers,
service vendors and private/public domains. To enable this
interoperability, there is need for a standard wire-format for
exchanging service information. This mailing lists is for discussing
protocols, data formats and server descriptions formats that allow
cloud services to be discovered and used across private and public
domains. Using these, it would be possible to interoperate diverse
APIs and cloud services across service providers, service vendors and
service users.

For additional information, please contact the list administrators.
_______________________________________________ IETF-Announce mailing
list IETF-Announce@ietf.org
https://www.i= etf.org/mailman/listinfo/ietf-announce <https://www.ietf.org/mailman/listinfo/ietf-= announce>

This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or
subject to copyright belonging to Time Warner Cable. This E-mail is
intended solely for the use of the individual or entity to which it
is addressed. If you are not the intended recipient of this E-mail,
you are hereby notified that any dissemination, distribution,
copying, or action taken in relation to the contents of and
attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify
the sender immediately and permanently delete the original and any
copy of this E-mail and any printout.
_______________________________________________ SDNP mailing list
SDNP@lucidvision.com http://lucidvision.com/mailman/listinfo/= sdnp <http://l= ucidvision.com/mailman/listinfo/sdnp>


=
_______________________________________________
SDNP mailing list
SDNP@lucidvision.com
http://lucidvision.c= om/mailman/listinfo/sdnp <http://lucidvision.com/mailman/listinfo/sdnp>
=

___________= ____________________________________
SDNP mailing list
SDNP@lucidvision.com
http://lucidvision.c= om/mailman/listinfo/sdnp
--B_3412249781_552603-- From tnadeau@lucidvision.com Thu Feb 16 06:29:02 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB7721F874A for ; Thu, 16 Feb 2012 06:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 9-4THCotv3Jw for ; Thu, 16 Feb 2012 06:28:58 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id D11AC21F871D for ; Thu, 16 Feb 2012 06:28:54 -0800 (PST) Received: from [192.168.1.94] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 16F0E208D589; Thu, 16 Feb 2012 09:28:54 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_4D9C3091-E60F-472D-8BAD-EF699B3BAD1A" From: Thomas Nadeau In-Reply-To: Date: Thu, 16 Feb 2012 09:28:52 -0500 Message-Id: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> References: To: Monique Morrow X-Mailer: Apple Mail (2.1257) X-Mailman-Approved-At: Thu, 16 Feb 2012 06:30:24 -0800 Cc: sdnp , sop@ietf.org, Ping Pan , robert@raszuk.net Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 14:29:02 -0000 --Apple-Mail=_4D9C3091-E60F-472D-8BAD-EF699B3BAD1A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Can you please explain what the purpose of SOP is and what its = goals are? People on this list have been also asking how it differs from SDN(p), so = it might be helpful to include that as well. 8) =09 --Tom On Feb 16, 2012, at 9:09 AM, Monique Morrow wrote: > Guys=20 >=20 > Please join the SOP mailer=20 >=20 >=20 > List address: sop@ietf.org > Archive: http://www.ietf.org/mail-archive/web/sop/ > To subscribe: https://www.ietf.org/mailman/listinfo/sop >=20 >=20 > TIA >=20 > Monique >=20 >=20 > On 2/14/12 10:45 PM, "Ping Pan" wrote: >=20 >> Where does OpenStack Quantum fit? >>=20 >> OpenStack Quantum is to have agents in controllers and networking = devices for the purpose of better transport. This is well within the = goal of SDN. >>=20 >> Ping >>=20 >> On Tue, Feb 14, 2012 at 1:37 PM, Robert Raszuk = wrote: >>>=20 >>> Actually I think those are quite separate problem spaces. >>>=20 >>> SOP aim to address the requirement of cloud to cloud communication = (hybrid or multi-domain). The way I think about this is how to = standardize and synchronize OpenStack to OpenStack instrumentation = signaling. The next step would be to actually also provide cloud to = cloud communication layer. Simple example: How to launch N VMs in = various data centers to be part of common resources for customer X. >>>=20 >>> On the contrary SDNx seems to me of totally different caliber. One = way to look at this is what and how we could use APIs exposed by = existing network control planes to define and accomplish new network = services. I quite do not see current network element control planes nor = their APIs as much relevant to cloud services. >>>=20 >>> My own personal view ;) >>>=20 >>> Regards, >>> R. >>>=20 >>>=20 >>>> I'd like to get some clarification (from anyone who might know or >>>> have an opinion) on how this would interact with/be distinct from = any >>>> of the SDNP (or whatever name we decide upon) proposed work. Is = this >>>> duplication/people striking out on their own from the nascent SDNP >>>> effort, a companion effort that became clear as we have begun >>>> segmenting the problem space, or something else entirely? Since = this >>>> is the first I've heard of the list, I'm thinking it's a separate >>>> effort, but I figured I would raise the topic for discussion. >>>>=20 >>>> Thanks, >>>>=20 >>>> Wes George >>>>=20 >>>> -----Original Message----- From: ietf-announce-bounces@ietf.org >>>> [mailto:ietf-announce-bounces@ietf.org = ] On Behalf Of IETF >>>> Secretariat Sent: Tuesday, February 14, 2012 2:25 PM To: IETF >>>> Announcement list Cc: sop@ietf.org; Monique Morrow Subject: New >>>> Non-WG Mailing List: sop -- Service Orchestration and Desciption = for >>>> Cloud Services >>>>=20 >>>>=20 >>>>=20 >>>> A new IETF non-working group email list has been created. >>>>=20 >>>> List address: sop@ietf.org Archive: >>>> http://www.ietf.org/mail-archive/web/sop/ = To subscribe: >>>> https://www.ietf.org/mailman/listinfo/sop = =20 >>>>=20 >>>> Purpose: Cloud services need to interoperate across cloud = providers, >>>> service vendors and private/public domains. To enable this >>>> interoperability, there is need for a standard wire-format for >>>> exchanging service information. This mailing lists is for = discussing >>>> protocols, data formats and server descriptions formats that allow >>>> cloud services to be discovered and used across private and public >>>> domains. Using these, it would be possible to interoperate diverse >>>> APIs and cloud services across service providers, service vendors = and >>>> service users. >>>>=20 >>>> For additional information, please contact the list administrators. >>>> _______________________________________________ IETF-Announce = mailing >>>> list IETF-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf-announce = =20 >>>>=20 >>>> This E-mail and any of its attachments may contain Time Warner = Cable >>>> proprietary information, which is privileged, confidential, or >>>> subject to copyright belonging to Time Warner Cable. This E-mail is >>>> intended solely for the use of the individual or entity to which it >>>> is addressed. If you are not the intended recipient of this E-mail, >>>> you are hereby notified that any dissemination, distribution, >>>> copying, or action taken in relation to the contents of and >>>> attachments to this E-mail is strictly prohibited and may be >>>> unlawful. If you have received this E-mail in error, please notify >>>> the sender immediately and permanently delete the original and any >>>> copy of this E-mail and any printout. >>>> _______________________________________________ SDNP mailing list >>>> SDNP@lucidvision.com http://lucidvision.com/mailman/listinfo/sdnp = =20 >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> SDNP mailing list >>> SDNP@lucidvision.com >>> http://lucidvision.com/mailman/listinfo/sdnp = =20 >>=20 >>=20 >> _______________________________________________ >> SDNP mailing list >> SDNP@lucidvision.com >> http://lucidvision.com/mailman/listinfo/sdnp > _______________________________________________ > SDNP mailing list > SDNP@lucidvision.com > http://lucidvision.com/mailman/listinfo/sdnp --Apple-Mail=_4D9C3091-E60F-472D-8BAD-EF699B3BAD1A Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

Can you please explain what the purpose of SOP is and what its goals are?
People on this list have been also asking how it differs from SDN(p), so it
might be helpful to include that as well. 8)
--Tom



On Feb 16, 2012, at 9:09 AM, Monique Morrow wrote:

Re: [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services
Guys

Please join the SOP mailer


List address: sop@ietf.org
Archive: http://www.ietf.org/mail-archive/web/sop/
To subscribe: https://www.ietf.org/mailman/listinfo/sop


TIA

Monique


On 2/14/12 10:45 PM, "Ping Pan" <ping@pingpan.org> wrote:

Where does OpenStack Quantum fit?

OpenStack Quantum is to have agents in controllers and networking devices for the purpose of better transport. This is well within the goal of SDN.

Ping

On Tue, Feb 14, 2012 at 1:37 PM, Robert Raszuk <robert@raszuk.net> wrote:

Actually I think those are quite separate problem spaces.

SOP aim to address the requirement of cloud to cloud communication (hybrid or multi-domain). The way I think about this is how to standardize and synchronize OpenStack to OpenStack instrumentation signaling. The next step would be to actually also provide cloud to cloud communication layer. Simple example: How to launch N VMs in various data centers to be part of common resources for customer X.

On the contrary SDNx seems to me of totally different caliber. One way to look at this is what and how we could use APIs exposed by existing network control planes to define and accomplish new network services. I quite do not see current network element control planes nor their APIs as much relevant to cloud services.

My own personal view ;)

Regards,
R.


I'd like to get some clarification (from anyone who might know or
have an opinion) on how this would interact with/be distinct from any
of the SDNP (or whatever name we decide upon) proposed work. Is this
duplication/people striking out on their own from the nascent SDNP
effort, a companion effort that became clear as we have begun
segmenting the problem space, or something else entirely? Since this
is the first I've heard of the list, I'm thinking it's a separate
effort, but I figured I would raise the topic for discussion.

Thanks,

Wes George

-----Original Message----- From: ietf-announce-bounces@ietf.org
[mailto:ietf-announce-bounces@ietf.org <mailto:ietf-announce-bounces@ietf.org> ] On Behalf Of IETF
Secretariat Sent: Tuesday, February 14, 2012 2:25 PM To: IETF
Announcement list Cc: sop@ietf.org; Monique Morrow Subject: New
Non-WG Mailing List: sop -- Service Orchestration and Desciption for
Cloud Services



A new IETF non-working group email list has been created.

List address: sop@ietf.org Archive:
http://www.ietf.org/mail-archive/web/sop/ <http://www.ietf.org/mail-archive/web/sop/>  To subscribe:
https://www.ietf.org/mailman/listinfo/sop <https://www.ietf.org/mailman/listinfo/sop>

Purpose: Cloud services need to interoperate across cloud providers,
service vendors and private/public domains. To enable this
interoperability, there is need for a standard wire-format for
exchanging service information. This mailing lists is for discussing
protocols, data formats and server descriptions formats that allow
cloud services to be discovered and used across private and public
domains. Using these, it would be possible to interoperate diverse
APIs and cloud services across service providers, service vendors and
service users.

For additional information, please contact the list administrators.
_______________________________________________ IETF-Announce mailing
list IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce <https://www.ietf.org/mailman/listinfo/ietf-announce>

This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or
subject to copyright belonging to Time Warner Cable. This E-mail is
intended solely for the use of the individual or entity to which it
is addressed. If you are not the intended recipient of this E-mail,
you are hereby notified that any dissemination, distribution,
copying, or action taken in relation to the contents of and
attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify
the sender immediately and permanently delete the original and any
copy of this E-mail and any printout.
_______________________________________________ SDNP mailing list
SDNP@lucidvision.com http://lucidvision.com/mailman/listinfo/sdnp <http://lucidvision.com/mailman/listinfo/sdnp>



_______________________________________________
SDNP mailing list
SDNP@lucidvision.com
http://lucidvision.com/mailman/listinfo/sdnp <http://lucidvision.com/mailman/listinfo/sdnp>


_______________________________________________
SDNP mailing list
SDNP@lucidvision.com
http://lucidvision.com/mailman/listinfo/sdnp
_______________________________________________
SDNP mailing list
SDNP@lucidvision.com
http://lucidvision.com/mailman/listinfo/sdnp

--Apple-Mail=_4D9C3091-E60F-472D-8BAD-EF699B3BAD1A-- From tnadeau@lucidvision.com Thu Feb 16 06:39:07 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D48521F8678 for ; Thu, 16 Feb 2012 06:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 FW6Q39vkmZ1s for ; Thu, 16 Feb 2012 06:39:02 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 03B0E21F86AA for ; Thu, 16 Feb 2012 06:39:01 -0800 (PST) Received: from [192.168.1.94] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 5C5E9208D698; Thu, 16 Feb 2012 09:39:01 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_CB323D56-4BF0-4833-BC59-121BC2B714DC" From: Thomas Nadeau In-Reply-To: Date: Thu, 16 Feb 2012 09:38:57 -0500 Message-Id: References: To: Monique Morrow X-Mailer: Apple Mail (2.1257) Cc: sdnp , sop@ietf.org, Ping Pan , robert@raszuk.net Subject: Re: [sop] FW: [Sdnp] New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 14:39:07 -0000 --Apple-Mail=_CB323D56-4BF0-4833-BC59-121BC2B714DC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Can you please explain what the purpose of SOP is and what its = goals are? People on this list have been also asking how it differs from SDN(p), so = it might be helpful to include that as well. 8) =09 --Tom On Feb 16, 2012, at 9:09 AM, Monique Morrow wrote: > Guys=20 >=20 > Please join the SOP mailer=20 >=20 >=20 > List address: sop@ietf.org > Archive: http://www.ietf.org/mail-archive/web/sop/ > To subscribe: https://www.ietf.org/mailman/listinfo/sop >=20 >=20 > TIA >=20 > Monique >=20 >=20 > On 2/14/12 10:45 PM, "Ping Pan" wrote: >=20 >> Where does OpenStack Quantum fit? >>=20 >> OpenStack Quantum is to have agents in controllers and networking = devices for the purpose of better transport. This is well within the = goal of SDN. >>=20 >> Ping >>=20 >> On Tue, Feb 14, 2012 at 1:37 PM, Robert Raszuk = wrote: >>>=20 >>> Actually I think those are quite separate problem spaces. >>>=20 >>> SOP aim to address the requirement of cloud to cloud communication = (hybrid or multi-domain). The way I think about this is how to = standardize and synchronize OpenStack to OpenStack instrumentation = signaling. The next step would be to actually also provide cloud to = cloud communication layer. Simple example: How to launch N VMs in = various data centers to be part of common resources for customer X. >>>=20 >>> On the contrary SDNx seems to me of totally different caliber. One = way to look at this is what and how we could use APIs exposed by = existing network control planes to define and accomplish new network = services. I quite do not see current network element control planes nor = their APIs as much relevant to cloud services. >>>=20 >>> My own personal view ;) >>>=20 >>> Regards, >>> R. >>>=20 >>>=20 >>>> I'd like to get some clarification (from anyone who might know or >>>> have an opinion) on how this would interact with/be distinct from = any >>>> of the SDNP (or whatever name we decide upon) proposed work. Is = this >>>> duplication/people striking out on their own from the nascent SDNP >>>> effort, a companion effort that became clear as we have begun >>>> segmenting the problem space, or something else entirely? Since = this >>>> is the first I've heard of the list, I'm thinking it's a separate >>>> effort, but I figured I would raise the topic for discussion. >>>>=20 >>>> Thanks, >>>>=20 >>>> Wes George >>>>=20 >>>> -----Original Message----- From: ietf-announce-bounces@ietf.org >>>> [mailto:ietf-announce-bounces@ietf.org = ] On Behalf Of IETF >>>> Secretariat Sent: Tuesday, February 14, 2012 2:25 PM To: IETF >>>> Announcement list Cc: sop@ietf.org; Monique Morrow Subject: New >>>> Non-WG Mailing List: sop -- Service Orchestration and Desciption = for >>>> Cloud Services >>>>=20 >>>>=20 >>>>=20 >>>> A new IETF non-working group email list has been created. >>>>=20 >>>> List address: sop@ietf.org Archive: >>>> http://www.ietf.org/mail-archive/web/sop/ = To subscribe: >>>> https://www.ietf.org/mailman/listinfo/sop = =20 >>>>=20 >>>> Purpose: Cloud services need to interoperate across cloud = providers, >>>> service vendors and private/public domains. To enable this >>>> interoperability, there is need for a standard wire-format for >>>> exchanging service information. This mailing lists is for = discussing >>>> protocols, data formats and server descriptions formats that allow >>>> cloud services to be discovered and used across private and public >>>> domains. Using these, it would be possible to interoperate diverse >>>> APIs and cloud services across service providers, service vendors = and >>>> service users. >>>>=20 >>>> For additional information, please contact the list administrators. >>>> _______________________________________________ IETF-Announce = mailing >>>> list IETF-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf-announce = =20 >>>>=20 >>>> This E-mail and any of its attachments may contain Time Warner = Cable >>>> proprietary information, which is privileged, confidential, or >>>> subject to copyright belonging to Time Warner Cable. This E-mail is >>>> intended solely for the use of the individual or entity to which it >>>> is addressed. If you are not the intended recipient of this E-mail, >>>> you are hereby notified that any dissemination, distribution, >>>> copying, or action taken in relation to the contents of and >>>> attachments to this E-mail is strictly prohibited and may be >>>> unlawful. If you have received this E-mail in error, please notify >>>> the sender immediately and permanently delete the original and any >>>> copy of this E-mail and any printout. >>>> _______________________________________________ SDNP mailing list >>>> SDNP@lucidvision.com http://lucidvision.com/mailman/listinfo/sdnp = =20 >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> SDNP mailing list >>> SDNP@lucidvision.com >>> http://lucidvision.com/mailman/listinfo/sdnp = =20 >>=20 >>=20 >> _______________________________________________ >> SDNP mailing list >> SDNP@lucidvision.com >> http://lucidvision.com/mailman/listinfo/sdnp > _______________________________________________ > SDNP mailing list > SDNP@lucidvision.com > http://lucidvision.com/mailman/listinfo/sdnp --Apple-Mail=_CB323D56-4BF0-4833-BC59-121BC2B714DC Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

Can you please explain what the purpose of SOP is and what its goals are?
People on this list have been also asking how it differs from SDN(p), so it
might be helpful to include that as well. 8)
--Tom



On Feb 16, 2012, at 9:09 AM, Monique Morrow wrote:

Re: [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services
Guys

Please join the SOP mailer


List address: sop@ietf.org
Archive: http://www.ietf.org/mail-archive/web/sop/
To subscribe: https://www.ietf.org/mailman/listinfo/sop


TIA

Monique


On 2/14/12 10:45 PM, "Ping Pan" <ping@pingpan.org> wrote:

Where does OpenStack Quantum fit?

OpenStack Quantum is to have agents in controllers and networking devices for the purpose of better transport. This is well within the goal of SDN.

Ping

On Tue, Feb 14, 2012 at 1:37 PM, Robert Raszuk <robert@raszuk.net> wrote:

Actually I think those are quite separate problem spaces.

SOP aim to address the requirement of cloud to cloud communication (hybrid or multi-domain). The way I think about this is how to standardize and synchronize OpenStack to OpenStack instrumentation signaling. The next step would be to actually also provide cloud to cloud communication layer. Simple example: How to launch N VMs in various data centers to be part of common resources for customer X.

On the contrary SDNx seems to me of totally different caliber. One way to look at this is what and how we could use APIs exposed by existing network control planes to define and accomplish new network services. I quite do not see current network element control planes nor their APIs as much relevant to cloud services.

My own personal view ;)

Regards,
R.


I'd like to get some clarification (from anyone who might know or
have an opinion) on how this would interact with/be distinct from any
of the SDNP (or whatever name we decide upon) proposed work. Is this
duplication/people striking out on their own from the nascent SDNP
effort, a companion effort that became clear as we have begun
segmenting the problem space, or something else entirely? Since this
is the first I've heard of the list, I'm thinking it's a separate
effort, but I figured I would raise the topic for discussion.

Thanks,

Wes George

-----Original Message----- From: ietf-announce-bounces@ietf.org
[mailto:ietf-announce-bounces@ietf.org <mailto:ietf-announce-bounces@ietf.org> ] On Behalf Of IETF
Secretariat Sent: Tuesday, February 14, 2012 2:25 PM To: IETF
Announcement list Cc: sop@ietf.org; Monique Morrow Subject: New
Non-WG Mailing List: sop -- Service Orchestration and Desciption for
Cloud Services



A new IETF non-working group email list has been created.

List address: sop@ietf.org Archive:
http://www.ietf.org/mail-archive/web/sop/ <http://www.ietf.org/mail-archive/web/sop/>  To subscribe:
https://www.ietf.org/mailman/listinfo/sop <https://www.ietf.org/mailman/listinfo/sop>

Purpose: Cloud services need to interoperate across cloud providers,
service vendors and private/public domains. To enable this
interoperability, there is need for a standard wire-format for
exchanging service information. This mailing lists is for discussing
protocols, data formats and server descriptions formats that allow
cloud services to be discovered and used across private and public
domains. Using these, it would be possible to interoperate diverse
APIs and cloud services across service providers, service vendors and
service users.

For additional information, please contact the list administrators.
_______________________________________________ IETF-Announce mailing
list IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce <https://www.ietf.org/mailman/listinfo/ietf-announce>

This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or
subject to copyright belonging to Time Warner Cable. This E-mail is
intended solely for the use of the individual or entity to which it
is addressed. If you are not the intended recipient of this E-mail,
you are hereby notified that any dissemination, distribution,
copying, or action taken in relation to the contents of and
attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify
the sender immediately and permanently delete the original and any
copy of this E-mail and any printout.
_______________________________________________ SDNP mailing list
SDNP@lucidvision.com http://lucidvision.com/mailman/listinfo/sdnp <http://lucidvision.com/mailman/listinfo/sdnp>



_______________________________________________
SDNP mailing list
SDNP@lucidvision.com
http://lucidvision.com/mailman/listinfo/sdnp <http://lucidvision.com/mailman/listinfo/sdnp>


_______________________________________________
SDNP mailing list
SDNP@lucidvision.com
http://lucidvision.com/mailman/listinfo/sdnp
_______________________________________________
SDNP mailing list
SDNP@lucidvision.com
http://lucidvision.com/mailman/listinfo/sdnp

--Apple-Mail=_CB323D56-4BF0-4833-BC59-121BC2B714DC-- From adalela@cisco.com Thu Feb 16 07:02:53 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0C621F865A for ; Thu, 16 Feb 2012 07:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.455 X-Spam-Level: X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[AWL=4.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 4ZI9Xy8KLcuf for ; Thu, 16 Feb 2012 07:02:46 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id E4BD521F864D for ; Thu, 16 Feb 2012 07:02:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=26563; q=dns/txt; s=iport; t=1329404564; x=1330614164; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=PTOKjugHbkwJ++Q4w8hZzeOw/06+gKzR5W9kSx285XA=; b=c62qNBOVdzyZo4B4FDVt1D3Tsrw+bsGZyutc5CxDFVOx6pcoAXbiiFTA xbv0yJn7AkB8I2oFuQxOV9K7d1/viS115Zk2kv+NqipRmuTwzBGpHGJgb m4jSxJ9S2TyOjpTfhZOIvidXFPAC/GIZX5RY2/KQ49M1v3/qwm8aHVGmv Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucHAMoZPU9Io8UY/2dsb2JhbABEgk2FLpgMiBMBiU2BcgEBAQQBAQEPAQkRAz4EBwwEAgEIDgMBAwEBCwIEEAMEAQYBJh8DBQEIAQEEAQoICAEZh2aaHQGeQ4tkCQEDAQQDGAgCAjGDWyQBCQYRAgMCBAECBAMEBQIFAwOCR2MEiEyeJYE2 X-IronPort-AV: E=Sophos;i="4.73,430,1325462400"; d="scan'208,217";a="5724146" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 16 Feb 2012 15:02:41 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1GF2fdY014676; Thu, 16 Feb 2012 15:02:41 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Feb 2012 20:32:41 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCECBC.0764D7F1" Date: Thu, 16 Feb 2012 20:32:39 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> In-Reply-To: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services Thread-Index: AczsvAafYHhYIbkMQ2SZTphXY1FR6w== References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> From: "Ashish Dalela (adalela)" To: "Thomas Nadeau" , "Monique Morrow (mmorrow)" X-OriginalArrivalTime: 16 Feb 2012 15:02:41.0271 (UTC) FILETIME=[079E1870:01CCECBC] Cc: sdnp , sop@ietf.org, Ping Pan , robert@raszuk.net Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 15:02:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCECBC.0764D7F1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 SOP has the following main goals -=20 =20 1. Fix interoperability issues with cloud services today. Main examples are inter-cloud, hybrid-cloud, and multi-vendor cloud. All cloud services are being enabled through proprietary APIs today, which don't interoperate. To interoperate across vendors, providers and customers, we need an open standard. Ability to go across administrative domains is a basic requirement. =20 2. A clear separation between service-independent and service-dependent pieces in cloud services. SOP is about service-independent pieces. Using SOP, a variety of services could be accessed or advertized. Separation between service-independent and service-dependent pieces makes the scheme extensible to any type of service - current or future. =20 3. Create a common scheme for service orchestration that can be used across compute, network, storage, security, applications, etc. A common set of constructs that can be applied to any service type whether it is infrastructure or application. =20 http://tools.ietf.org/html/draft-dalela-orchestration-00 =20 The above draft describes the problems SOP is aimed to address. This is the "requirements" draft. =20 The other drafts are: =20 http://tools.ietf.org/html/draft-dalela-sop-architecture-00 - describes the use-cases and network deployments with the protocol http://tools.ietf.org/html/draft-dalela-sop-00 - describes the protocol's messages=20 http://tools.ietf.org/html/draft-dalela-sdf-00 - describes service naming, workflow construction, etc. http://tools.ietf.org/html/draft-dalela-sop-flows-00 - describes some message flows =20 Thanks, Ashish =20 =20 From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]=20 Sent: Thursday, February 16, 2012 7:59 PM To: Monique Morrow (mmorrow) Cc: Ping Pan; robert@raszuk.net; sdnp; sop@ietf.org Subject: Re: [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services =20 =20 Can you please explain what the purpose of SOP is and what its goals are? People on this list have been also asking how it differs from SDN(p), so it might be helpful to include that as well. 8) =20 --Tom =20 =20 =20 On Feb 16, 2012, at 9:09 AM, Monique Morrow wrote: Guys=20 Please join the SOP mailer=20 List address: sop@ietf.org =20 Archive: http://www.ietf.org/mail-archive/web/sop/ To subscribe: https://www.ietf.org/mailman/listinfo/sop TIA Monique On 2/14/12 10:45 PM, "Ping Pan" > wrote: Where does OpenStack Quantum fit? OpenStack Quantum is to have agents in controllers and networking devices for the purpose of better transport. This is well within the goal of SDN. Ping On Tue, Feb 14, 2012 at 1:37 PM, Robert Raszuk > wrote: Actually I think those are quite separate problem spaces. SOP aim to address the requirement of cloud to cloud communication (hybrid or multi-domain). The way I think about this is how to standardize and synchronize OpenStack to OpenStack instrumentation signaling. The next step would be to actually also provide cloud to cloud communication layer. Simple example: How to launch N VMs in various data centers to be part of common resources for customer X. On the contrary SDNx seems to me of totally different caliber. One way to look at this is what and how we could use APIs exposed by existing network control planes to define and accomplish new network services. I quite do not see current network element control planes nor their APIs as much relevant to cloud services. My own personal view ;) Regards, R. I'd like to get some clarification (from anyone who might know or have an opinion) on how this would interact with/be distinct from any of the SDNP (or whatever name we decide upon) proposed work. Is this duplication/people striking out on their own from the nascent SDNP effort, a companion effort that became clear as we have begun segmenting the problem space, or something else entirely? Since this is the first I've heard of the list, I'm thinking it's a separate effort, but I figured I would raise the topic for discussion. Thanks, Wes George -----Original Message----- From: ietf-announce-bounces@ietf.org =20 [mailto:ietf-announce-bounces@ietf.org ] On Behalf Of IETF Secretariat Sent: Tuesday, February 14, 2012 2:25 PM To: IETF Announcement list Cc: sop@ietf.org ; Monique Morrow Subject: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services A new IETF non-working group email list has been created. List address: sop@ietf.org Archive: http://www.ietf.org/mail-archive/web/sop/ To subscribe: https://www.ietf.org/mailman/listinfo/sop =20 Purpose: Cloud services need to interoperate across cloud providers, service vendors and private/public domains. To enable this interoperability, there is need for a standard wire-format for exchanging service information. This mailing lists is for discussing protocols, data formats and server descriptions formats that allow cloud services to be discovered and used across private and public domains. Using these, it would be possible to interoperate diverse APIs and cloud services across service providers, service vendors and service users. For additional information, please contact the list administrators. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org =20 https://www.ietf.org/mailman/listinfo/ietf-announce =20 This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ SDNP mailing list SDNP@lucidvision.com http://lucidvision.com/mailman/listinfo/sdnp =20 _______________________________________________ SDNP mailing list SDNP@lucidvision.com =20 http://lucidvision.com/mailman/listinfo/sdnp =20 =20 ________________________________ _______________________________________________ SDNP mailing list SDNP@lucidvision.com =20 http://lucidvision.com/mailman/listinfo/sdnp _______________________________________________ SDNP mailing list SDNP@lucidvision.com http://lucidvision.com/mailman/listinfo/sdnp =20 ------_=_NextPart_001_01CCECBC.0764D7F1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Sdnp] FW: New Non-WG Mailing List: sop = -- Service Orchestration and Desciption for Cloud = Services

 =

SOP has = the following main goals –

 =

1.  Fix = interoperability issues with cloud services today. Main examples are = inter-cloud, hybrid-cloud, and multi-vendor cloud. All cloud services = are being enabled through proprietary APIs today, which don’t = interoperate. To interoperate across vendors, providers and customers, = we need an open standard. Ability to go across administrative domains is = a basic requirement.

 =

2.  A clear = separation between service-independent and service-dependent pieces in = cloud services. SOP is about service-independent pieces. Using SOP, a = variety of services could be accessed or advertized. Separation between = service-independent and service-dependent pieces makes the scheme = extensible to any type of service – current or = future.

 =

3.  Create a = common scheme for service orchestration that can be used across compute, = network, storage, security, applications, etc. A common set of = constructs that can be applied to any service type whether it is = infrastructure or application.

 =

http://= tools.ietf.org/html/draft-dalela-orchestration-00

 <= /p>

The above draft = describes the problems SOP is aimed to address. This is the = “requirements” draft.

 <= /p>

The other drafts = are:

 <= /p>

http= ://tools.ietf.org/html/draft-dalela-sop-architecture-00 - describes = the use-cases and network deployments with the = protocol

http://tools.ietf= .org/html/draft-dalela-sop-00 - describes the protocol’s = messages

http://tools.ietf= .org/html/draft-dalela-sdf-00 - describes service naming, workflow = construction, etc.

http://tool= s.ietf.org/html/draft-dalela-sop-flows-00 - describes some message = flows

 <= /p>

Thanks, = Ashish

 

 

From:= = Thomas Nadeau [mailto:tnadeau@lucidvision.com]
Sent: = Thursday, February 16, 2012 7:59 PM
To: Monique Morrow = (mmorrow)
Cc: Ping Pan; robert@raszuk.net; sdnp; = sop@ietf.org
Subject: Re: [Sdnp] FW: New Non-WG Mailing List: = sop -- Service Orchestration and Desciption for Cloud = Services

 

 

        &n= bsp;   Can you please explain what the purpose of SOP = is and what its goals are?

People on this list have been also asking how it = differs from SDN(p), so it

might be helpful to include that as well. = 8)

        &n= bsp;  

        &n= bsp;   --Tom

 

 

 

On = Feb 16, 2012, at 9:09 AM, Monique Morrow wrote:



Guys =

Please join the SOP mailer


List address: = sop@ietf.org
Archive:= http://www.ietf.org/ma= il-archive/web/sop/
To subscribe: https://www.ietf.org/m= ailman/listinfo/sop


TIA=

Monique


On 2/14/12 10:45 PM, "Ping Pan" = <ping@pingpan.org> = wrote:


Where does = OpenStack Quantum fit?

OpenStack Quantum is to have agents in = controllers and networking devices for the purpose of better transport. = This is well within the goal of SDN.

Ping

On Tue, Feb 14, = 2012 at 1:37 PM, Robert Raszuk <robert@raszuk.net> = wrote:


Actuall= y I think those are quite separate problem spaces.

SOP aim to = address the requirement of cloud to cloud communication (hybrid or = multi-domain). The way I think about this is how to standardize and = synchronize OpenStack to OpenStack instrumentation signaling. The next = step would be to actually also provide cloud to cloud communication = layer. Simple example: How to launch N VMs in various data centers to be = part of common resources for customer X.

On the contrary SDNx = seems to me of totally different caliber. One way to look at this is = what and how we could use APIs exposed by existing network control = planes to define and accomplish new network services. I quite do not see = current network element control planes nor their APIs as much relevant = to cloud services.

My own personal view = ;)

Regards,
R.



I'd like = to get some clarification (from anyone who might know or
have an = opinion) on how this would interact with/be distinct from any
of the = SDNP (or whatever name we decide upon) proposed work. Is = this
duplication/people striking out on their own from the nascent = SDNP
effort, a companion effort that became clear as we have = begun
segmenting the problem space, or something else entirely? Since = this
is the first I've heard of the list, I'm thinking it's a = separate
effort, but I figured I would raise the topic for = discussion.

Thanks,

Wes George

-----Original = Message----- From: ietf-announce-bounces= @ietf.org
[mailto:ietf-announce-bounc= es@ietf.org <mailto:ietf-announce-bounc= es@ietf.org> ] On Behalf Of IETF
Secretariat Sent: Tuesday, = February 14, 2012 2:25 PM To: IETF
Announcement list Cc: sop@ietf.org; Monique Morrow = Subject: New
Non-WG Mailing List: sop -- Service Orchestration and = Desciption for
Cloud Services



A new IETF non-working = group email list has been created.

List address: sop@ietf.org Archive:
http://www.ietf.org/ma= il-archive/web/sop/ <http://www.ietf.org/ma= il-archive/web/sop/>  To subscribe:
https://www.ietf.org/m= ailman/listinfo/sop <https://www.ietf.org/m= ailman/listinfo/sop>

Purpose: Cloud services need to = interoperate across cloud providers,
service vendors and = private/public domains. To enable this
interoperability, there is = need for a standard wire-format for
exchanging service information. = This mailing lists is for discussing
protocols, data formats and = server descriptions formats that allow
cloud services to be = discovered and used across private and public
domains. Using these, = it would be possible to interoperate diverse
APIs and cloud services = across service providers, service vendors and
service = users.

For additional information, please contact the list = administrators.
_______________________________________________ = IETF-Announce mailing
list IETF-Announce@ietf.orghttps://www.= ietf.org/mailman/listinfo/ietf-announce <https://www.= ietf.org/mailman/listinfo/ietf-announce>

This E-mail and = any of its attachments may contain Time Warner Cable
proprietary = information, which is privileged, confidential, or
subject to = copyright belonging to Time Warner Cable. This E-mail is
intended = solely for the use of the individual or entity to which it
is = addressed. If you are not the intended recipient of this E-mail,
you = are hereby notified that any dissemination, distribution,
copying, or = action taken in relation to the contents of and
attachments to this = E-mail is strictly prohibited and may be
unlawful. If you have = received this E-mail in error, please notify
the sender immediately = and permanently delete the original and any
copy of this E-mail and = any printout.
_______________________________________________ SDNP = mailing list
SDNP@lucidvision.com http://lucidvision.= com/mailman/listinfo/sdnp <http://lucidvision.= com/mailman/listinfo/sdnp>


_______= ________________________________________
SDNP mailing list
SDNP@lucidvision.com
http://lucidvision.= com/mailman/listinfo/sdnp <http://lucidvision.= com/mailman/listinfo/sdnp>

 =

_________________________= ______________________
SDNP mailing list
SDNP@lucidvision.com
http://lucidvision.= com/mailman/listinfo/sdnp

_______________________________________________
SDNP= mailing list
SDNP@lucidvision.com
http://l= ucidvision.com/mailman/listinfo/sdnp

 

------_=_NextPart_001_01CCECBC.0764D7F1-- From scott.brim@gmail.com Thu Feb 16 06:47:50 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53DA221F8636 for ; Thu, 16 Feb 2012 06:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 7LkFd8zSu72F for ; Thu, 16 Feb 2012 06:47:49 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id C090221F8564 for ; Thu, 16 Feb 2012 06:47:49 -0800 (PST) Received: by dakl33 with SMTP id l33so2238482dak.31 for ; Thu, 16 Feb 2012 06:47:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lE4BbzAbuN4hEI9TM5BLkLgwSBEuKHmRsnsDK9/QjGk=; b=MjD/hdf6Nb5u5wIWdLJhwstG314boje616AEswD4JaRQObO5Ukbd+cb7s8krMUTR9n hoaVVVZidvfmi9AIrUjdn6EN/o1k9NoqQOThWFBPkUekHndNAix8c2S2kaB+nKsvPFN0 sp1KX6fHPRfy4oGDQOlP4ANeim2cT8N8tye2M= Received: by 10.68.74.138 with SMTP id t10mr14265892pbv.126.1329403669226; Thu, 16 Feb 2012 06:47:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.67.202 with HTTP; Thu, 16 Feb 2012 06:47:29 -0800 (PST) In-Reply-To: References: From: Scott Brim Date: Thu, 16 Feb 2012 09:47:29 -0500 Message-ID: To: Thomas Nadeau Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Thu, 16 Feb 2012 07:12:00 -0800 Cc: sdnp , Monique Morrow , sop@ietf.org Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 14:47:50 -0000 On Thu, Feb 16, 2012 at 09:38, Thomas Nadeau wrote: > Can you please explain what the purpose of SOP is and what its goals are? > People on this list have been also asking how it differs from SDN(p), so it > might be helpful to include that as well. 8) > --Tom Robert's statement is exactly what I thought. From adalela@cisco.com Thu Feb 16 07:15:50 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4D621F867D for ; Thu, 16 Feb 2012 07:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[AWL=3.032, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_HI=-8, SUBJ_ALL_CAPS=2.077] 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 rR9L6Okyfu4G for ; Thu, 16 Feb 2012 07:15:46 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6892521F86AB for ; Thu, 16 Feb 2012 07:15:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=2022; q=dns/txt; s=iport; t=1329405345; x=1330614945; h=mime-version:subject:date:message-id:from:to; bh=6xB/ydEGDSjppnq/KoHiFLEzPE8TbcEbNL7cjOX1H90=; b=bn9/Flt4tiOIUgf4ofOgk8CcusaYeNKJcq0Qp8OlyEG8mnweyzmDzkIB rpcgZ3x/9F/EdSQeKc5IfIYwnjXoDenlGQ6v8xKnb+8nhw9f6lw2sqAeu R6RrA2yN0hr6y+dOMasGQNntPw65EobXTI1gEpfWhniMWFKhZnB4DTHhl o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUEAFAdPU9Io8UY/2dsb2JhbABEgk2lYYkqEIFuBgEEEgEGAxEDWwEMHgYYB0AXAQQLEBqFJoIsmQ+BJwGeRYxOEQEBAQEBAQEBAQEBg2MBWII6YwSITJ9b X-IronPort-AV: E=Sophos;i="4.73,430,1325462400"; d="scan'208,217";a="5724808" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 16 Feb 2012 15:15:44 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1GFFhMj012685 for ; Thu, 16 Feb 2012 15:15:43 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Feb 2012 20:45:43 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCECBD.D9EB01C1" Date: Thu, 16 Feb 2012 20:45:42 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C5103001E7F@XMB-BGL-416.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TEST EMAIL Thread-Index: AczsvdmA9tQKMg3hQ1WW9MpyC1CTTQ== From: "Ashish Dalela (adalela)" To: X-OriginalArrivalTime: 16 Feb 2012 15:15:43.0735 (UTC) FILETIME=[DA00A070:01CCECBD] Subject: [sop] TEST EMAIL X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 15:15:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCECBD.D9EB01C1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 ------_=_NextPart_001_01CCECBD.D9EB01C1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

------_=_NextPart_001_01CCECBD.D9EB01C1-- From adalela@cisco.com Thu Feb 16 07:23:22 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D39821F87DC for ; Thu, 16 Feb 2012 07:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=4.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 K8s9VmAdGASK for ; Thu, 16 Feb 2012 07:23:13 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2151F21F865D for ; Thu, 16 Feb 2012 07:23:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=6463; q=dns/txt; s=iport; t=1329405792; x=1330615392; h=mime-version:subject:date:message-id:from:to; bh=xggllx9JQiG4fP6VoQ7ZP3lLA5MGk0qBVD6kuLlIOJY=; b=Iroctb9yho62jEPXdAgg6dqOl+W+f6OsmxxKaf/AnumzKUeVf3DajT7A tp5fRdaIUrO27KGC1hY0qgua0RhlJmaPH5OwBB5O+VZHU81ROMMwpRRf6 4mrqtPDHP698x05rWFl4txUISQdM6loRai0tptnJ7atUZg4eXFp/HswAn 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIGAIEePU9Io8UY/2dsb2JhbABEgk2FLqAfAYlNgXQBBBIBCREDWwEaEAYYB0gPAQQLEBqHZphzgScBnkaLZApgEQYDAoNjATUEH4I6YwSITJ4lgTY X-IronPort-AV: E=Sophos;i="4.73,430,1325462400"; d="scan'208,217";a="5725215" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 16 Feb 2012 15:23:10 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1GFNAWN013957 for ; Thu, 16 Feb 2012 15:23:10 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Feb 2012 20:53:10 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCECBE.E404D5D1" Date: Thu, 16 Feb 2012 20:53:09 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C5103001E83@XMB-BGL-416.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Service Orchestration Protocol Thread-Index: AczsvuOo08mxHh23SCWs2uTC6K/9IA== From: "Ashish Dalela (adalela)" To: X-OriginalArrivalTime: 16 Feb 2012 15:23:10.0178 (UTC) FILETIME=[E41A6C20:01CCECBE] Subject: [sop] Service Orchestration Protocol X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 15:23:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCECBE.E404D5D1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, =20 This is a new discussion alias created to talk about a "Service Orchestration Protocol" for interoperable cloud services. =20 The drafts posted so far are below: =20 http://tools.ietf.org/html/draft-dalela-orchestration-00 - talks about why we need a protocol, a.k.a. requirements =20 http://tools.ietf.org/html/draft-dalela-sop-architecture-00 - describes the use-cases and network deployments with the protocol =20 http://tools.ietf.org/html/draft-dalela-sop-00 - describes the protocol's messages =20 http://tools.ietf.org/html/draft-dalela-sdf-00 - describes scheme for service naming, workflows, etc. =20 http://tools.ietf.org/html/draft-dalela-sop-flows-00 - describes some message flows =20 Love to hear your feedback and discussion on this. =20 Thanks, Ashish =20 =20 ------_=_NextPart_001_01CCECBE.E404D5D1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,<= /p>

 <= /p>

This is a new discussion = alias created to talk about a “Service Orchestration = Protocol” for interoperable cloud = services.

 <= /p>

The drafts posted so far = are below:

 <= /p>

http://= tools.ietf.org/html/draft-dalela-orchestration-00 - talks about why = we need a protocol, a.k.a. requirements

 <= /p>

http= ://tools.ietf.org/html/draft-dalela-sop-architecture-00 - describes = the use-cases and network deployments with the = protocol

 <= /p>

http://tools.ietf= .org/html/draft-dalela-sop-00 - describes the protocol’s = messages

 <= /p>

http://tools.ietf= .org/html/draft-dalela-sdf-00 - describes scheme for service naming, = workflows, etc.

 <= /p>

http://tool= s.ietf.org/html/draft-dalela-sop-flows-00 - describes some message = flows

 <= /p>

Love to hear your = feedback and discussion on this.

    &= nbsp;           &n= bsp;            =

Thanks, = Ashish

 <= /p>

 <= /p>

------_=_NextPart_001_01CCECBE.E404D5D1-- From ping@pingpan.org Thu Feb 16 07:24:33 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32CF21F855F for ; Thu, 16 Feb 2012 07:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 LuM5bqWX707a for ; Thu, 16 Feb 2012 07:24:25 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with SMTP id 3897521F87EC for ; Thu, 16 Feb 2012 07:24:25 -0800 (PST) Received: from mail-gx0-f182.google.com ([209.85.161.182]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTz0fqDd0TCqQT0LT1TdhqpEw1u3zW2HP@postini.com; Thu, 16 Feb 2012 07:24:25 PST Received: by mail-gx0-f182.google.com with SMTP id k5so1503954ggn.13 for ; Thu, 16 Feb 2012 07:24:24 -0800 (PST) Received: by 10.229.137.144 with SMTP id w16mr2180836qct.8.1329405864312; Thu, 16 Feb 2012 07:24:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.80.200 with HTTP; Thu, 16 Feb 2012 07:23:43 -0800 (PST) In-Reply-To: <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> From: Ping Pan Date: Thu, 16 Feb 2012 07:23:43 -0800 Message-ID: To: "Ashish Dalela (adalela)" Content-Type: multipart/alternative; boundary=00235452f2d04e004104b9166cc6 X-Gm-Message-State: ALoCoQmAXIbO7bXO33fON7ZfZE83d8HJYemSNNJqLP9F97HCL6q7TRu722dN3PxyEHcqJb756PLN Cc: Thomas Nadeau , "Monique Morrow \(mmorrow\)" , sop@ietf.org, robert@raszuk.net, sdnp Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 15:24:33 -0000 --00235452f2d04e004104b9166cc6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yeah, I have read all the drafts during the DC BoF discussion. In general, this makes sense... My thinking is that we may not want to standardize the interior DC management, as each vendor has own solution. But at the same time, we need to enable applications and services to ride on top of DC resources. In other words, SDN is in the position to enable Virtual DC's, and create the interface to communicate with networking resources at abstraction level. SDN should not be viewed as the NMS for DC's. There are a lot of work to be done here, and many parts are moving. Let's work together. Ping On Thu, Feb 16, 2012 at 7:02 AM, Ashish Dalela (adalela) wrote: > ** ** > > SOP has the following main goals =E2=80=93 **** > > ** ** > > **1. **Fix interoperability issues with cloud services today. Main > examples are inter-cloud, hybrid-cloud, and multi-vendor cloud. All cloud > services are being enabled through proprietary APIs today, which don=E2= =80=99t > interoperate. To interoperate across vendors, providers and customers, we > need an open standard. Ability to go across administrative domains is a > basic requirement.**** > > ** ** > > **2. **A clear separation between service-independent and > service-dependent pieces in cloud services. SOP is about > service-independent pieces. Using SOP, a variety of services could be > accessed or advertized. Separation between service-independent and > service-dependent pieces makes the scheme extensible to any type of servi= ce > =E2=80=93 current or future.**** > > ** ** > > **3. **Create a common scheme for service orchestration that can be used > across compute, network, storage, security, applications, etc. A common s= et > of constructs that can be applied to any service type whether it is > infrastructure or application.**** > > ** ** > > http://tools.ietf.org/html/draft-dalela-orchestration-00**** > > ** ** > > The above draft describes the problems SOP is aimed to address. This is > the =E2=80=9Crequirements=E2=80=9D draft.**** > > ** ** > > The other drafts are:**** > > ** ** > > http://tools.ietf.org/html/draft-dalela-sop-architecture-00 - describes > the use-cases and network deployments with the protocol**** > > http://tools.ietf.org/html/draft-dalela-sop-00 - describes the protocol= =E2=80=99s > messages **** > > http://tools.ietf.org/html/draft-dalela-sdf-00 - describes service > naming, workflow construction, etc.**** > > http://tools.ietf.org/html/draft-dalela-sop-flows-00 - describes some > message flows**** > > ** ** > > Thanks, Ashish**** > > ** ** > > ** ** > > *From:* Thomas Nadeau [mailto:tnadeau@lucidvision.com] > *Sent:* Thursday, February 16, 2012 7:59 PM > *To:* Monique Morrow (mmorrow) > *Cc:* Ping Pan; robert@raszuk.net; sdnp; sop@ietf.org > *Subject:* Re: [Sdnp] FW: New Non-WG Mailing List: sop -- Service > Orchestration and Desciption for Cloud Services**** > > ** ** > > ** ** > > Can you please explain what the purpose of SOP is and what > its goals are?**** > > People on this list have been also asking how it differs from SDN(p), so = it > **** > > might be helpful to include that as well. 8)**** > > **** > > --Tom**** > > ** ** > > ** ** > > ** ** > > On Feb 16, 2012, at 9:09 AM, Monique Morrow wrote:**** > > > > **** > > Guys > > Please join the SOP mailer > > > List address: *sop@ietf.org > *Archive: *http://www.ietf.org/mail-archive/web/sop/ > *To subscribe: *https://www.ietf.org/mailman/listinfo/sop > * > > TIA > > Monique > > > On 2/14/12 10:45 PM, "Ping Pan" wrote: > > > **** > > Where does OpenStack Quantum fit? > > OpenStack Quantum is to have agents in controllers and networking devices > for the purpose of better transport. This is well within the goal of SDN. > > Ping > > On Tue, Feb 14, 2012 at 1:37 PM, Robert Raszuk wrote: > > **** > > > Actually I think those are quite separate problem spaces. > > SOP aim to address the requirement of cloud to cloud communication (hybri= d > or multi-domain). The way I think about this is how to standardize and > synchronize OpenStack to OpenStack instrumentation signaling. The next st= ep > would be to actually also provide cloud to cloud communication layer. > Simple example: How to launch N VMs in various data centers to be part of > common resources for customer X. > > On the contrary SDNx seems to me of totally different caliber. One way to > look at this is what and how we could use APIs exposed by existing networ= k > control planes to define and accomplish new network services. I quite do > not see current network element control planes nor their APIs as much > relevant to cloud services. > > My own personal view ;) > > Regards, > R. > > > > **** > > I'd like to get some clarification (from anyone who might know or > have an opinion) on how this would interact with/be distinct from any > of the SDNP (or whatever name we decide upon) proposed work. Is this > duplication/people striking out on their own from the nascent SDNP > effort, a companion effort that became clear as we have begun > segmenting the problem space, or something else entirely? Since this > is the first I've heard of the list, I'm thinking it's a separate > effort, but I figured I would raise the topic for discussion. > > Thanks, > > Wes George > > -----Original Message----- From: ietf-announce-bounces@ietf.org > [mailto:ietf-announce-bounces@ietf.org < > mailto:ietf-announce-bounces@ietf.org > ] > On Behalf Of IETF > Secretariat Sent: Tuesday, February 14, 2012 2:25 PM To: IETF > Announcement list Cc: sop@ietf.org; Monique Morrow Subject: New > Non-WG Mailing List: sop -- Service Orchestration and Desciption for > Cloud Services > > > > A new IETF non-working group email list has been created. > > List address: sop@ietf.org Archive: > http://www.ietf.org/mail-archive/web/sop/ < > http://www.ietf.org/mail-archive/web/sop/> To subscribe: > https://www.ietf.org/mailman/listinfo/sop < > https://www.ietf.org/mailman/listinfo/sop> > > Purpose: Cloud services need to interoperate across cloud providers, > service vendors and private/public domains. To enable this > interoperability, there is need for a standard wire-format for > exchanging service information. This mailing lists is for discussing > protocols, data formats and server descriptions formats that allow > cloud services to be discovered and used across private and public > domains. Using these, it would be possible to interoperate diverse > APIs and cloud services across service providers, service vendors and > service users. > > For additional information, please contact the list administrators. > _______________________________________________ IETF-Announce mailing > list IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce < > https://www.ietf.org/mailman/listinfo/ietf-announce> > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or > subject to copyright belonging to Time Warner Cable. This E-mail is > intended solely for the use of the individual or entity to which it > is addressed. If you are not the intended recipient of this E-mail, > you are hereby notified that any dissemination, distribution, > copying, or action taken in relation to the contents of and > attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any > copy of this E-mail and any printout. > _______________________________________________ SDNP mailing list > SDNP@lucidvision.com http://lucidvision.com/mailman/listinfo/sdnp < > http://lucidvision.com/mailman/listinfo/sdnp> > > **** > > > _______________________________________________ > SDNP mailing list > SDNP@lucidvision.com > http://lucidvision.com/mailman/listinfo/sdnp < > http://lucidvision.com/mailman/listinfo/sdnp> **** > > ** ** > ------------------------------ > > _______________________________________________ > SDNP mailing list > SDNP@lucidvision.com > http://lucidvision.com/mailman/listinfo/sdnp**** > > _______________________________________________ > SDNP mailing list > SDNP@lucidvision.com > http://lucidvision.com/mailman/listinfo/sdnp**** > > ** ** > > _______________________________________________ > sop mailing list > sop@ietf.org > https://www.ietf.org/mailman/listinfo/sop > > --00235452f2d04e004104b9166cc6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yeah, I have read all the drafts during the DC BoF discussion. In general, = this makes sense...

My thinking is that we may not want = to standardize the interior DC management, as each vendor has own solution.= =C2=A0But at the same time, we need to enable applications and services to = ride on top of DC resources. In other words, SDN is in the position to enab= le Virtual=C2=A0DC's, and create the interface to communicate with netw= orking resources at=C2=A0abstraction=C2=A0level. SDN should not be viewed a= s the NMS for DC's.

There are a lot of work to be done here, and many parts= are moving. Let's work together.

Ping


On Thu, Feb 16, 2012 at= 7:02 AM, Ashish Dalela (adalela) <adalela@cisco.com> wrote:

=C2=A0=

SOP has the following main goals =E2=80=93

=C2=A0

1.=C2=A0 Fix interoperability issues = with cloud services today. Main examples are inter-cloud, hybrid-cloud, and= multi-vendor cloud. All cloud services are being enabled through proprieta= ry APIs today, which don=E2=80=99t interoperate. To interoperate across ven= dors, providers and customers, we need an open standard. Ability to go acro= ss administrative domains is a basic requirement.

=C2=A0

2.= =C2=A0 A clear separation between service-independent = and service-dependent pieces in cloud services. SOP is about service-indepe= ndent pieces. Using SOP, a variety of services could be accessed or adverti= zed. Separation between service-independent and service-dependent pieces ma= kes the scheme extensible to any type of service =E2=80=93 current or futur= e.

=C2=A0

3.= =C2=A0 Create a common scheme for service orchestratio= n that can be used across compute, network, storage, security, applications= , etc. A common set of constructs that can be applied to any service type w= hether it is infrastructure or application.

<= /u>=C2=A0

http://tools.ietf.org/html/draft-d= alela-orchestration-00

=C2=A0

The above draft describes the problems S= OP is aimed to address. This is the =E2=80=9Crequirements=E2=80=9D draft.

=C2=A0

The other drafts are:

=C2=A0<= /span>

http://tools.ietf.org/html/draft-dalela-sop-arch= itecture-00 - describes the use-cases and network deployments with the = protocol

http://tools.ietf.org/html/draft-dalela-sop-00 - describes the prot= ocol=E2=80=99s messages

http://tools.ietf.org/html/draft-dalela-sdf-00 - describes service = naming, workflow construction, etc.

http://tools.ietf.org/html/draft-dalela-sop-flows-00 - desc= ribes some message flows

=C2=A0

Thanks, Ashish

<= p class=3D"MsoNormal"> =C2=A0

=C2=A0

From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]
Sent: Thursday, February 16, 2012 7:59 PM
To: Monique Morr= ow (mmorrow)
Cc: Ping Pan; robert@raszuk.net; sdnp; sop@ietf.org
Subject: Re: [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orch= estration and Desciption for Cloud Services

<= /div>

=C2=A0

=

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <= /span>Can you please explain what the purpose of SOP is and what its goals = are?

People on this list have = been also asking how it differs from SDN(p), so it

might be helpful to include that as well.= 8)

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --Tom

=C2=A0

=C2=A0

= =C2=A0

On Feb 16, 2012, a= t 9:09 AM, Monique Morrow wrote:



Guys

Please join the SOP mailer


List address: sop@ietf.org
<= /u>Archive: http://www.ietf.org/mail-archive/web= /sop/
To subscribe: https://www.ietf.org/ma= ilman/listinfo/sop


TIA

Monique


On 2/14/12 10:45 PM, "Ping Pan"= <ping@pingpan.org> wrote:


Where does OpenStack Quantum fit?

OpenStack Quantum is to have agents in controllers and networking devic= es for the purpose of better transport. This is well within the goal of SDN= .

Ping

On Tue, Feb 14, 2012 at 1:37 PM, Robert Raszuk <= robert@raszuk.net> wrote:


Actual= ly I think those are quite separate problem spaces.

SOP aim to addre= ss the requirement of cloud to cloud communication (hybrid or multi-domain)= . The way I think about this is how to standardize and synchronize OpenStac= k to OpenStack instrumentation signaling. The next step would be to actuall= y also provide cloud to cloud communication layer. Simple example: How to l= aunch N VMs in various data centers to be part of common resources for cust= omer X.

On the contrary SDNx seems to me of totally different caliber. One way = to look at this is what and how we could use APIs exposed by existing netwo= rk control planes to define and accomplish new network services. I quite do= not see current network element control planes nor their APIs as much rele= vant to cloud services.

My own personal view ;)

Regards,
R.



=

I'd like to get some clarification (from anyone who might know o= r
have an opinion) on how this would interact with/be distinct from any
of= the SDNP (or whatever name we decide upon) proposed work. Is this
dupli= cation/people striking out on their own from the nascent SDNP
effort, a = companion effort that became clear as we have begun
segmenting the problem space, or something else entirely? Since this
is = the first I've heard of the list, I'm thinking it's a separate<= br>effort, but I figured I would raise the topic for discussion.

Thanks,

Wes George

-----Original Message----- From: ietf-a= nnounce-bounces@ietf.org
[mailto:ietf-announce-bounces@ietf.org <mailto:iet= f-announce-bounces@ietf.org> ] On Behalf Of IETF
Secretariat Sent: Tuesday, February 14, 2012 2:25 PM To: IETF
Announceme= nt list Cc: sop@ietf.org; Monique Morrow Subject: New
Non-WG Mail= ing List: sop -- Service Orchestration and Desciption for
Cloud Services=



A new IETF non-working group email list has been created.
List address: sop@ietf.org Archive:
http://www.ietf.org/mail-archi= ve/web/sop/ <http://www.ietf.org/mail-archive/web/sop/> =C2=A0To= subscribe:
htt= ps://www.ietf.org/mailman/listinfo/sop <https://www.ietf.org/mailman/li= stinfo/sop>

Purpose: Cloud services need to interoperate across cloud providers,service vendors and private/public domains. To enable this
interoperabi= lity, there is need for a standard wire-format for
exchanging service in= formation. This mailing lists is for discussing
protocols, data formats and server descriptions formats that allow
cloud= services to be discovered and used across private and public
domains. U= sing these, it would be possible to interoperate diverse
APIs and cloud = services across service providers, service vendors and
service users.

For additional information, please contact the list a= dministrators.
_______________________________________________ IETF-Anno= unce mailing
list IETF-Announce@ietf.org
https://www.ie= tf.org/mailman/listinfo/ietf-announce <https://www.ietf.org/m= ailman/listinfo/ietf-announce>

This E-mail and any of its attachments may contain Time Warner Cableproprietary information, which is privileged, confidential, or
subject = to copyright belonging to Time Warner Cable. This E-mail is
intended sol= ely for the use of the individual or entity to which it
is addressed. If you are not the intended recipient of this E-mail,
you = are hereby notified that any dissemination, distribution,
copying, or ac= tion taken in relation to the contents of and
attachments to this E-mail= is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify
the s= ender immediately and permanently delete the original and any
copy of th= is E-mail and any printout.
____________________________________________= ___ SDNP mailing list
SDNP@lucidvision.com http://lucidvision.com/mailman/listinfo/sdnp <http://lucidvision.com/mailman/listinfo/sdnp>


______= _________________________________________
SDNP mailing list
SDNP@l= ucidvision.com
= http://lucidvision.com/mailman/listinfo/sdnp <http://lucidvision.com= /mailman/listinfo/sdnp>

= =C2=A0

_= ______________________________________________
SDNP mailing list
SDNP@lucidvision.com
http://lucidvision.com/= mailman/listinfo/sdnp

_______________________________________________
SDNP mailing list
SDNP@lucidvision.com=
http://lucidvision.com/mailman/listinfo/sdnp

=C2=A0


_______________________________________________
sop mailing list
sop@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sop


--00235452f2d04e004104b9166cc6-- From adalela@cisco.com Thu Feb 16 07:38:45 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D04321F87FC for ; Thu, 16 Feb 2012 07:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.645 X-Spam-Level: X-Spam-Status: No, score=-6.645 tagged_above=-999 required=5 tests=[AWL=3.953, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 Nhz-hlfzELhh for ; Thu, 16 Feb 2012 07:38:40 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDF621F87A4 for ; Thu, 16 Feb 2012 07:38:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=43188; q=dns/txt; s=iport; t=1329406717; x=1330616317; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=P0KcrCYCTmWKtJVAtdqpTqFbuqYTMjUr6oKijjmnCi8=; b=LwpfUb0dLS8ZltNunqhcurHlwVRGGuetXhhvxTSk2vEyMPC6iRx35SFt LpSByP3TxJ2dumCjc7IIyeEWCm3nTjZdNQHlJChADabacMh0jHWmWhHYp Si/AGsrjVt6mdy8ILFGTfMsE0WWd5lZ9FnhSHxbQTfx2bu8IcApOHLugX s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgFAEEiPU9Io8UY/2dsb2JhbABEgk2CRJp2iBMBh1eBdoFyAQEBBAEBAQ8BCQcKAz4EBwwEAgEIEQEDAQELAgQQAQIEAQICAgEBJR8DBQEIAQEECwgIARIHh2aaHgGMZZFii2QJAQMBAgIDBwkICAICMYNbExEBCQYRAgMCBAECBAMEBQIFAwOCFDNjBIhMn1s X-IronPort-AV: E=Sophos;i="4.73,430,1325462400"; d="scan'208,217";a="5720833" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 16 Feb 2012 15:38:35 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1GFcZHN024987; Thu, 16 Feb 2012 15:38:35 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Feb 2012 21:08:34 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCECC1.0B16EA09" Date: Thu, 16 Feb 2012 21:08:33 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C5103001E8E@XMB-BGL-416.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services Thread-Index: AczsvxkFRJ4LjwGIS9y0cxNiRUG4xAAAI+uw References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> From: "Ashish Dalela (adalela)" To: "Ping Pan" X-OriginalArrivalTime: 16 Feb 2012 15:38:34.0972 (UTC) FILETIME=[0B52C9C0:01CCECC1] Cc: Thomas Nadeau , "Monique Morrow \(mmorrow\)" , sop@ietf.org, robert@raszuk.net, sdnp Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 15:38:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCECC1.0B16EA09 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IA0KDQpXZWxsLCB5ZXMsIG9uZSBvZiB0aGUgdXNlLWNhc2UgaXMgdG8gc29sdmUgaW50ZXJvcGVy YWJpbGl0eSBpc3N1ZXMgYmV0d2VlbiBhbmQgYWNyb3NzIGNsb3Vkcy4NCg0KIA0KDQpJIGFsc28g aGF2ZSBoZWFyZCBmcm9tIGZvbGtzIHRoZSBuZWVkIGZvciDigJxkZWVwIGNvbnRyb2zigJ0gaW4g d2hpY2ggYSBjdXN0b21lciBvdXRzaWRlIHRoZSBjbG91ZCB3YW50cyB0byB0d2VhayBvciBjb250 cm9sIHRoZSBpbmZyYXN0cnVjdHVyZSBvciBhcHBsaWNhdGlvbiBhdCBhIGxvdyBncmFudWxhcml0 eS4gSSB0aGluayB0aGF0IHdvdWxkIGJlIGhhcmQsIGFsdGhvdWdoIG5vdCBpbXBvc3NpYmxlLCBp ZiB0aGUgbWVjaGFuaXNtcyBvdXRzaWRlIGFuZCBpbnNpZGUgd2VyZSBkaWZmZXJlbnQg4oCTIGFz IHlvdSB3aWxsIGhhdmUgdG8gY3JlYXRlIG1hcHBpbmdzLg0KDQogDQoNClRoYXQgaXMgYSB0b3Bp YyBxdWl0ZSBvcGVuIGZvciBkaXNjdXNzaW9uLg0KDQogDQoNClRoYW5rcywgQXNoaXNoDQoNCiAN Cg0KIA0KDQpGcm9tOiBQaW5nIFBhbiBbbWFpbHRvOnBpbmdAcGluZ3Bhbi5vcmddIA0KU2VudDog VGh1cnNkYXksIEZlYnJ1YXJ5IDE2LCAyMDEyIDg6NTQgUE0NClRvOiBBc2hpc2ggRGFsZWxhIChh ZGFsZWxhKQ0KQ2M6IFRob21hcyBOYWRlYXU7IE1vbmlxdWUgTW9ycm93IChtbW9ycm93KTsgc2Ru cDsgc29wQGlldGYub3JnOyByb2JlcnRAcmFzenVrLm5ldA0KU3ViamVjdDogUmU6IFtzb3BdIFtT ZG5wXSBGVzogTmV3IE5vbi1XRyBNYWlsaW5nIExpc3Q6IHNvcCAtLSBTZXJ2aWNlIE9yY2hlc3Ry YXRpb24gYW5kIERlc2NpcHRpb24gZm9yIENsb3VkIFNlcnZpY2VzDQoNCiANCg0KWWVhaCwgSSBo YXZlIHJlYWQgYWxsIHRoZSBkcmFmdHMgZHVyaW5nIHRoZSBEQyBCb0YgZGlzY3Vzc2lvbi4gSW4g Z2VuZXJhbCwgdGhpcyBtYWtlcyBzZW5zZS4uLg0KDQogDQoNCk15IHRoaW5raW5nIGlzIHRoYXQg d2UgbWF5IG5vdCB3YW50IHRvIHN0YW5kYXJkaXplIHRoZSBpbnRlcmlvciBEQyBtYW5hZ2VtZW50 LCBhcyBlYWNoIHZlbmRvciBoYXMgb3duIHNvbHV0aW9uLiBCdXQgYXQgdGhlIHNhbWUgdGltZSwg d2UgbmVlZCB0byBlbmFibGUgYXBwbGljYXRpb25zIGFuZCBzZXJ2aWNlcyB0byByaWRlIG9uIHRv cCBvZiBEQyByZXNvdXJjZXMuIEluIG90aGVyIHdvcmRzLCBTRE4gaXMgaW4gdGhlIHBvc2l0aW9u IHRvIGVuYWJsZSBWaXJ0dWFsIERDJ3MsIGFuZCBjcmVhdGUgdGhlIGludGVyZmFjZSB0byBjb21t dW5pY2F0ZSB3aXRoIG5ldHdvcmtpbmcgcmVzb3VyY2VzIGF0IGFic3RyYWN0aW9uIGxldmVsLiBT RE4gc2hvdWxkIG5vdCBiZSB2aWV3ZWQgYXMgdGhlIE5NUyBmb3IgREMncy4NCg0KIA0KDQpUaGVy ZSBhcmUgYSBsb3Qgb2Ygd29yayB0byBiZSBkb25lIGhlcmUsIGFuZCBtYW55IHBhcnRzIGFyZSBt b3ZpbmcuIExldCdzIHdvcmsgdG9nZXRoZXIuDQoNCiANCg0KUGluZw0KDQogDQoNCiANCg0KT24g VGh1LCBGZWIgMTYsIDIwMTIgYXQgNzowMiBBTSwgQXNoaXNoIERhbGVsYSAoYWRhbGVsYSkgPGFk YWxlbGFAY2lzY28uY29tPiB3cm90ZToNCg0KIA0KDQpTT1AgaGFzIHRoZSBmb2xsb3dpbmcgbWFp biBnb2FscyDigJMgDQoNCiANCg0KMS4gIEZpeCBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlcyB3aXRo IGNsb3VkIHNlcnZpY2VzIHRvZGF5LiBNYWluIGV4YW1wbGVzIGFyZSBpbnRlci1jbG91ZCwgaHli cmlkLWNsb3VkLCBhbmQgbXVsdGktdmVuZG9yIGNsb3VkLiBBbGwgY2xvdWQgc2VydmljZXMgYXJl IGJlaW5nIGVuYWJsZWQgdGhyb3VnaCBwcm9wcmlldGFyeSBBUElzIHRvZGF5LCB3aGljaCBkb27i gJl0IGludGVyb3BlcmF0ZS4gVG8gaW50ZXJvcGVyYXRlIGFjcm9zcyB2ZW5kb3JzLCBwcm92aWRl cnMgYW5kIGN1c3RvbWVycywgd2UgbmVlZCBhbiBvcGVuIHN0YW5kYXJkLiBBYmlsaXR5IHRvIGdv IGFjcm9zcyBhZG1pbmlzdHJhdGl2ZSBkb21haW5zIGlzIGEgYmFzaWMgcmVxdWlyZW1lbnQuDQoN CiANCg0KMi4gIEEgY2xlYXIgc2VwYXJhdGlvbiBiZXR3ZWVuIHNlcnZpY2UtaW5kZXBlbmRlbnQg YW5kIHNlcnZpY2UtZGVwZW5kZW50IHBpZWNlcyBpbiBjbG91ZCBzZXJ2aWNlcy4gU09QIGlzIGFi b3V0IHNlcnZpY2UtaW5kZXBlbmRlbnQgcGllY2VzLiBVc2luZyBTT1AsIGEgdmFyaWV0eSBvZiBz ZXJ2aWNlcyBjb3VsZCBiZSBhY2Nlc3NlZCBvciBhZHZlcnRpemVkLiBTZXBhcmF0aW9uIGJldHdl ZW4gc2VydmljZS1pbmRlcGVuZGVudCBhbmQgc2VydmljZS1kZXBlbmRlbnQgcGllY2VzIG1ha2Vz IHRoZSBzY2hlbWUgZXh0ZW5zaWJsZSB0byBhbnkgdHlwZSBvZiBzZXJ2aWNlIOKAkyBjdXJyZW50 IG9yIGZ1dHVyZS4NCg0KIA0KDQozLiAgQ3JlYXRlIGEgY29tbW9uIHNjaGVtZSBmb3Igc2Vydmlj ZSBvcmNoZXN0cmF0aW9uIHRoYXQgY2FuIGJlIHVzZWQgYWNyb3NzIGNvbXB1dGUsIG5ldHdvcmss IHN0b3JhZ2UsIHNlY3VyaXR5LCBhcHBsaWNhdGlvbnMsIGV0Yy4gQSBjb21tb24gc2V0IG9mIGNv bnN0cnVjdHMgdGhhdCBjYW4gYmUgYXBwbGllZCB0byBhbnkgc2VydmljZSB0eXBlIHdoZXRoZXIg aXQgaXMgaW5mcmFzdHJ1Y3R1cmUgb3IgYXBwbGljYXRpb24uDQoNCiANCg0KaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtZGFsZWxhLW9yY2hlc3RyYXRpb24tMDANCg0KIA0KDQpUaGUg YWJvdmUgZHJhZnQgZGVzY3JpYmVzIHRoZSBwcm9ibGVtcyBTT1AgaXMgYWltZWQgdG8gYWRkcmVz cy4gVGhpcyBpcyB0aGUg4oCccmVxdWlyZW1lbnRz4oCdIGRyYWZ0Lg0KDQogDQoNClRoZSBvdGhl ciBkcmFmdHMgYXJlOg0KDQogDQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRh bGVsYS1zb3AtYXJjaGl0ZWN0dXJlLTAwIC0gZGVzY3JpYmVzIHRoZSB1c2UtY2FzZXMgYW5kIG5l dHdvcmsgZGVwbG95bWVudHMgd2l0aCB0aGUgcHJvdG9jb2wNCg0KaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtZGFsZWxhLXNvcC0wMCAtIGRlc2NyaWJlcyB0aGUgcHJvdG9jb2zigJlz IG1lc3NhZ2VzIA0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kYWxlbGEtc2Rm LTAwIC0gZGVzY3JpYmVzIHNlcnZpY2UgbmFtaW5nLCB3b3JrZmxvdyBjb25zdHJ1Y3Rpb24sIGV0 Yy4NCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZGFsZWxhLXNvcC1mbG93cy0w MCAtIGRlc2NyaWJlcyBzb21lIG1lc3NhZ2UgZmxvd3MNCg0KIA0KDQpUaGFua3MsIEFzaGlzaA0K DQogDQoNCiANCg0KRnJvbTogVGhvbWFzIE5hZGVhdSBbbWFpbHRvOnRuYWRlYXVAbHVjaWR2aXNp b24uY29tXSANClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxNiwgMjAxMiA3OjU5IFBNDQpUbzog TW9uaXF1ZSBNb3Jyb3cgKG1tb3Jyb3cpDQpDYzogUGluZyBQYW47IHJvYmVydEByYXN6dWsubmV0 OyBzZG5wOyBzb3BAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbU2RucF0gRlc6IE5ldyBOb24tV0cg TWFpbGluZyBMaXN0OiBzb3AgLS0gU2VydmljZSBPcmNoZXN0cmF0aW9uIGFuZCBEZXNjaXB0aW9u IGZvciBDbG91ZCBTZXJ2aWNlcw0KDQogDQoNCiANCg0KICAgICAgICAgICAgQ2FuIHlvdSBwbGVh c2UgZXhwbGFpbiB3aGF0IHRoZSBwdXJwb3NlIG9mIFNPUCBpcyBhbmQgd2hhdCBpdHMgZ29hbHMg YXJlPw0KDQpQZW9wbGUgb24gdGhpcyBsaXN0IGhhdmUgYmVlbiBhbHNvIGFza2luZyBob3cgaXQg ZGlmZmVycyBmcm9tIFNETihwKSwgc28gaXQNCg0KbWlnaHQgYmUgaGVscGZ1bCB0byBpbmNsdWRl IHRoYXQgYXMgd2VsbC4gOCkNCg0KICAgICAgICAgICAgDQoNCiAgICAgICAgICAgIC0tVG9tDQoN CiANCg0KIA0KDQogDQoNCk9uIEZlYiAxNiwgMjAxMiwgYXQgOTowOSBBTSwgTW9uaXF1ZSBNb3Jy b3cgd3JvdGU6DQoNCiANCg0KR3V5cyANCg0KUGxlYXNlIGpvaW4gdGhlIFNPUCBtYWlsZXIgDQoN Cg0KTGlzdCBhZGRyZXNzOiBzb3BAaWV0Zi5vcmcNCkFyY2hpdmU6IGh0dHA6Ly93d3cuaWV0Zi5v cmcvbWFpbC1hcmNoaXZlL3dlYi9zb3AvDQpUbyBzdWJzY3JpYmU6IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc29wDQoNCg0KVElBDQoNCk1vbmlxdWUNCg0KDQpPbiAyLzE0 LzEyIDEwOjQ1IFBNLCAiUGluZyBQYW4iIDxwaW5nQHBpbmdwYW4ub3JnPiB3cm90ZToNCg0KDQoN CldoZXJlIGRvZXMgT3BlblN0YWNrIFF1YW50dW0gZml0Pw0KDQpPcGVuU3RhY2sgUXVhbnR1bSBp cyB0byBoYXZlIGFnZW50cyBpbiBjb250cm9sbGVycyBhbmQgbmV0d29ya2luZyBkZXZpY2VzIGZv ciB0aGUgcHVycG9zZSBvZiBiZXR0ZXIgdHJhbnNwb3J0LiBUaGlzIGlzIHdlbGwgd2l0aGluIHRo ZSBnb2FsIG9mIFNETi4NCg0KUGluZw0KDQpPbiBUdWUsIEZlYiAxNCwgMjAxMiBhdCAxOjM3IFBN LCBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldD4gd3JvdGU6DQoNCg0KQWN0dWFsbHkg SSB0aGluayB0aG9zZSBhcmUgcXVpdGUgc2VwYXJhdGUgcHJvYmxlbSBzcGFjZXMuDQoNClNPUCBh aW0gdG8gYWRkcmVzcyB0aGUgcmVxdWlyZW1lbnQgb2YgY2xvdWQgdG8gY2xvdWQgY29tbXVuaWNh dGlvbiAoaHlicmlkIG9yIG11bHRpLWRvbWFpbikuIFRoZSB3YXkgSSB0aGluayBhYm91dCB0aGlz IGlzIGhvdyB0byBzdGFuZGFyZGl6ZSBhbmQgc3luY2hyb25pemUgT3BlblN0YWNrIHRvIE9wZW5T dGFjayBpbnN0cnVtZW50YXRpb24gc2lnbmFsaW5nLiBUaGUgbmV4dCBzdGVwIHdvdWxkIGJlIHRv IGFjdHVhbGx5IGFsc28gcHJvdmlkZSBjbG91ZCB0byBjbG91ZCBjb21tdW5pY2F0aW9uIGxheWVy LiBTaW1wbGUgZXhhbXBsZTogSG93IHRvIGxhdW5jaCBOIFZNcyBpbiB2YXJpb3VzIGRhdGEgY2Vu dGVycyB0byBiZSBwYXJ0IG9mIGNvbW1vbiByZXNvdXJjZXMgZm9yIGN1c3RvbWVyIFguDQoNCk9u IHRoZSBjb250cmFyeSBTRE54IHNlZW1zIHRvIG1lIG9mIHRvdGFsbHkgZGlmZmVyZW50IGNhbGli ZXIuIE9uZSB3YXkgdG8gbG9vayBhdCB0aGlzIGlzIHdoYXQgYW5kIGhvdyB3ZSBjb3VsZCB1c2Ug QVBJcyBleHBvc2VkIGJ5IGV4aXN0aW5nIG5ldHdvcmsgY29udHJvbCBwbGFuZXMgdG8gZGVmaW5l IGFuZCBhY2NvbXBsaXNoIG5ldyBuZXR3b3JrIHNlcnZpY2VzLiBJIHF1aXRlIGRvIG5vdCBzZWUg Y3VycmVudCBuZXR3b3JrIGVsZW1lbnQgY29udHJvbCBwbGFuZXMgbm9yIHRoZWlyIEFQSXMgYXMg bXVjaCByZWxldmFudCB0byBjbG91ZCBzZXJ2aWNlcy4NCg0KTXkgb3duIHBlcnNvbmFsIHZpZXcg OykNCg0KUmVnYXJkcywNClIuDQoNCg0KDQoNCkknZCBsaWtlIHRvIGdldCBzb21lIGNsYXJpZmlj YXRpb24gKGZyb20gYW55b25lIHdobyBtaWdodCBrbm93IG9yDQpoYXZlIGFuIG9waW5pb24pIG9u IGhvdyB0aGlzIHdvdWxkIGludGVyYWN0IHdpdGgvYmUgZGlzdGluY3QgZnJvbSBhbnkNCm9mIHRo ZSBTRE5QIChvciB3aGF0ZXZlciBuYW1lIHdlIGRlY2lkZSB1cG9uKSBwcm9wb3NlZCB3b3JrLiBJ cyB0aGlzDQpkdXBsaWNhdGlvbi9wZW9wbGUgc3RyaWtpbmcgb3V0IG9uIHRoZWlyIG93biBmcm9t IHRoZSBuYXNjZW50IFNETlANCmVmZm9ydCwgYSBjb21wYW5pb24gZWZmb3J0IHRoYXQgYmVjYW1l IGNsZWFyIGFzIHdlIGhhdmUgYmVndW4NCnNlZ21lbnRpbmcgdGhlIHByb2JsZW0gc3BhY2UsIG9y IHNvbWV0aGluZyBlbHNlIGVudGlyZWx5PyBTaW5jZSB0aGlzDQppcyB0aGUgZmlyc3QgSSd2ZSBo ZWFyZCBvZiB0aGUgbGlzdCwgSSdtIHRoaW5raW5nIGl0J3MgYSBzZXBhcmF0ZQ0KZWZmb3J0LCBi dXQgSSBmaWd1cmVkIEkgd291bGQgcmFpc2UgdGhlIHRvcGljIGZvciBkaXNjdXNzaW9uLg0KDQpU aGFua3MsDQoNCldlcyBHZW9yZ2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTog aWV0Zi1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnDQpbbWFpbHRvOmlldGYtYW5ub3VuY2UtYm91 bmNlc0BpZXRmLm9yZyA8bWFpbHRvOmlldGYtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZz4gXSBP biBCZWhhbGYgT2YgSUVURg0KU2VjcmV0YXJpYXQgU2VudDogVHVlc2RheSwgRmVicnVhcnkgMTQs IDIwMTIgMjoyNSBQTSBUbzogSUVURg0KQW5ub3VuY2VtZW50IGxpc3QgQ2M6IHNvcEBpZXRmLm9y ZzsgTW9uaXF1ZSBNb3Jyb3cgU3ViamVjdDogTmV3DQpOb24tV0cgTWFpbGluZyBMaXN0OiBzb3Ag LS0gU2VydmljZSBPcmNoZXN0cmF0aW9uIGFuZCBEZXNjaXB0aW9uIGZvcg0KQ2xvdWQgU2Vydmlj ZXMNCg0KDQoNCkEgbmV3IElFVEYgbm9uLXdvcmtpbmcgZ3JvdXAgZW1haWwgbGlzdCBoYXMgYmVl biBjcmVhdGVkLg0KDQpMaXN0IGFkZHJlc3M6IHNvcEBpZXRmLm9yZyBBcmNoaXZlOg0KaHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NvcC8gPGh0dHA6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9zb3AvPiAgVG8gc3Vic2NyaWJlOg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zb3AgPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc29wPiANCg0KUHVycG9zZTogQ2xvdWQgc2VydmljZXMgbmVlZCB0byBpbnRlcm9wZXJh dGUgYWNyb3NzIGNsb3VkIHByb3ZpZGVycywNCnNlcnZpY2UgdmVuZG9ycyBhbmQgcHJpdmF0ZS9w dWJsaWMgZG9tYWlucy4gVG8gZW5hYmxlIHRoaXMNCmludGVyb3BlcmFiaWxpdHksIHRoZXJlIGlz IG5lZWQgZm9yIGEgc3RhbmRhcmQgd2lyZS1mb3JtYXQgZm9yDQpleGNoYW5naW5nIHNlcnZpY2Ug aW5mb3JtYXRpb24uIFRoaXMgbWFpbGluZyBsaXN0cyBpcyBmb3IgZGlzY3Vzc2luZw0KcHJvdG9j b2xzLCBkYXRhIGZvcm1hdHMgYW5kIHNlcnZlciBkZXNjcmlwdGlvbnMgZm9ybWF0cyB0aGF0IGFs bG93DQpjbG91ZCBzZXJ2aWNlcyB0byBiZSBkaXNjb3ZlcmVkIGFuZCB1c2VkIGFjcm9zcyBwcml2 YXRlIGFuZCBwdWJsaWMNCmRvbWFpbnMuIFVzaW5nIHRoZXNlLCBpdCB3b3VsZCBiZSBwb3NzaWJs ZSB0byBpbnRlcm9wZXJhdGUgZGl2ZXJzZQ0KQVBJcyBhbmQgY2xvdWQgc2VydmljZXMgYWNyb3Nz IHNlcnZpY2UgcHJvdmlkZXJzLCBzZXJ2aWNlIHZlbmRvcnMgYW5kDQpzZXJ2aWNlIHVzZXJzLg0K DQpGb3IgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiwgcGxlYXNlIGNvbnRhY3QgdGhlIGxpc3QgYWRt aW5pc3RyYXRvcnMuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXyBJRVRGLUFubm91bmNlIG1haWxpbmcNCmxpc3QgSUVURi1Bbm5vdW5jZUBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZXRmLWFubm91bmNlIDxodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lldGYtYW5ub3VuY2U+IA0KDQpUaGlz IEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5l ciBDYWJsZQ0KcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNv bmZpZGVudGlhbCwgb3INCnN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdh cm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMNCmludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBv ZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQNCmlzIGFkZHJlc3NlZC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwNCnlvdSBh cmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwN CmNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2Yg YW5kDQphdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFu ZCBtYXkgYmUNCnVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeQ0KdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50 bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55DQpjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBh bnkgcHJpbnRvdXQuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXyBTRE5QIG1haWxpbmcgbGlzdA0KU0ROUEBsdWNpZHZpc2lvbi5jb20gaHR0cDovL2x1Y2lk dmlzaW9uLmNvbS9tYWlsbWFuL2xpc3RpbmZvL3NkbnAgPGh0dHA6Ly9sdWNpZHZpc2lvbi5jb20v bWFpbG1hbi9saXN0aW5mby9zZG5wPiANCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KU0ROUCBtYWlsaW5nIGxpc3QNClNETlBAbHVjaWR2aXNpb24u Y29tDQpodHRwOi8vbHVjaWR2aXNpb24uY29tL21haWxtYW4vbGlzdGluZm8vc2RucCA8aHR0cDov L2x1Y2lkdmlzaW9uLmNvbS9tYWlsbWFuL2xpc3RpbmZvL3NkbnA+IA0KDQogDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpTRE5QIG1haWxpbmcgbGlzdA0KU0ROUEBsdWNpZHZpc2lvbi5j b20NCmh0dHA6Ly9sdWNpZHZpc2lvbi5jb20vbWFpbG1hbi9saXN0aW5mby9zZG5wDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTRE5QIG1haWxpbmcg bGlzdA0KU0ROUEBsdWNpZHZpc2lvbi5jb20NCmh0dHA6Ly9sdWNpZHZpc2lvbi5jb20vbWFpbG1h bi9saXN0aW5mby9zZG5wDQoNCiANCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0Kc29wIG1haWxpbmcgbGlzdA0Kc29wQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvcA0KDQogDQoNCg== ------_=_NextPart_001_01CCECC1.0B16EA09 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9w LWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxp bms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5XZWxsLCB5ZXMsIG9uZSBvZiB0aGUgdXNl LWNhc2UgaXMgdG8gc29sdmUgaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZXMgYmV0d2VlbiBhbmQgYWNy b3NzIGNsb3Vkcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgYWxzbyBoYXZlIGhlYXJkIGZyb20gZm9s a3MgdGhlIG5lZWQgZm9yIOKAnGRlZXAgY29udHJvbOKAnSBpbiB3aGljaCBhIGN1c3RvbWVyIG91 dHNpZGUgdGhlIGNsb3VkIHdhbnRzIHRvIHR3ZWFrIG9yIGNvbnRyb2wgdGhlIGluZnJhc3RydWN0 dXJlIG9yIGFwcGxpY2F0aW9uIGF0IGEgbG93IGdyYW51bGFyaXR5LiBJIHRoaW5rIHRoYXQgd291 bGQgYmUgaGFyZCwgYWx0aG91Z2ggbm90IGltcG9zc2libGUsIGlmIHRoZSBtZWNoYW5pc21zIG91 dHNpZGUgYW5kIGluc2lkZSB3ZXJlIGRpZmZlcmVudCDigJMgYXMgeW91IHdpbGwgaGF2ZSB0byBj cmVhdGUgbWFwcGluZ3MuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGF0IGlzIGEgdG9waWMgcXVpdGUg b3BlbiBmb3IgZGlzY3Vzc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoYW5rcywgQXNoaXNoPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0n Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiInPiBQaW5nIFBhbiBbbWFpbHRvOnBpbmdAcGluZ3Bhbi5vcmddIDxicj48Yj5TZW50 OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDE2LCAyMDEyIDg6NTQgUE08YnI+PGI+VG86PC9iPiBB c2hpc2ggRGFsZWxhIChhZGFsZWxhKTxicj48Yj5DYzo8L2I+IFRob21hcyBOYWRlYXU7IE1vbmlx dWUgTW9ycm93IChtbW9ycm93KTsgc2RucDsgc29wQGlldGYub3JnOyByb2JlcnRAcmFzenVrLm5l dDxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtzb3BdIFtTZG5wXSBGVzogTmV3IE5vbi1XRyBNYWls aW5nIExpc3Q6IHNvcCAtLSBTZXJ2aWNlIE9yY2hlc3RyYXRpb24gYW5kIERlc2NpcHRpb24gZm9y IENsb3VkIFNlcnZpY2VzPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+WWVhaCwgSSBoYXZl IHJlYWQgYWxsIHRoZSBkcmFmdHMgZHVyaW5nIHRoZSBEQyBCb0YgZGlzY3Vzc2lvbi4gSW4gZ2Vu ZXJhbCwgdGhpcyBtYWtlcyBzZW5zZS4uLjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs Pk15IHRoaW5raW5nIGlzIHRoYXQgd2UgbWF5IG5vdCB3YW50IHRvIHN0YW5kYXJkaXplIHRoZSBp bnRlcmlvciBEQyBtYW5hZ2VtZW50LCBhcyBlYWNoIHZlbmRvciBoYXMgb3duIHNvbHV0aW9uLiZu YnNwO0J1dCBhdCB0aGUgc2FtZSB0aW1lLCB3ZSBuZWVkIHRvIGVuYWJsZSBhcHBsaWNhdGlvbnMg YW5kIHNlcnZpY2VzIHRvIHJpZGUgb24gdG9wIG9mIERDIHJlc291cmNlcy4gSW4gb3RoZXIgd29y ZHMsIFNETiBpcyBpbiB0aGUgcG9zaXRpb24gdG8gZW5hYmxlIFZpcnR1YWwmbmJzcDtEQydzLCBh bmQgY3JlYXRlIHRoZSBpbnRlcmZhY2UgdG8gY29tbXVuaWNhdGUgd2l0aCBuZXR3b3JraW5nIHJl c291cmNlcyBhdCZuYnNwO2Fic3RyYWN0aW9uJm5ic3A7bGV2ZWwuIFNETiBzaG91bGQgbm90IGJl IHZpZXdlZCBhcyB0aGUgTk1TIGZvciBEQydzLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPlRoZXJlIGFyZSBhIGxvdCBvZiB3b3JrIHRvIGJlIGRvbmUgaGVyZSwgYW5kIG1h bnkgcGFydHMgYXJlIG1vdmluZy4gTGV0J3Mgd29yayB0b2dldGhlci48bzpwPjwvbzpwPjwvcD48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD5QaW5nPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5PbiBU aHUsIEZlYiAxNiwgMjAxMiBhdCA3OjAyIEFNLCBBc2hpc2ggRGFsZWxhIChhZGFsZWxhKSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmFkYWxlbGFAY2lzY28uY29tIj5hZGFsZWxhQGNpc2NvLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjoj MUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6 IzFGNDk3RCc+U09QIGhhcyB0aGUgZm9sbG93aW5nIG1haW4gZ29hbHMg4oCTIDwvc3Bhbj48bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+PHAgc3R5bGU9J21hcmdpbi1sZWZ0Oi4yNWluJz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz4xLjwvc3Bh bj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QnPiZuYnNwOyA8L3Nw YW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29s b3I6IzFGNDk3RCc+Rml4IGludGVyb3BlcmFiaWxpdHkgaXNzdWVzIHdpdGggY2xvdWQgc2Vydmlj ZXMgdG9kYXkuIE1haW4gZXhhbXBsZXMgYXJlIGludGVyLWNsb3VkLCBoeWJyaWQtY2xvdWQsIGFu ZCBtdWx0aS12ZW5kb3IgY2xvdWQuIEFsbCBjbG91ZCBzZXJ2aWNlcyBhcmUgYmVpbmcgZW5hYmxl ZCB0aHJvdWdoIHByb3ByaWV0YXJ5IEFQSXMgdG9kYXksIHdoaWNoIGRvbuKAmXQgaW50ZXJvcGVy YXRlLiBUbyBpbnRlcm9wZXJhdGUgYWNyb3NzIHZlbmRvcnMsIHByb3ZpZGVycyBhbmQgY3VzdG9t ZXJzLCB3ZSBuZWVkIGFuIG9wZW4gc3RhbmRhcmQuIEFiaWxpdHkgdG8gZ28gYWNyb3NzIGFkbWlu aXN0cmF0aXZlIGRvbWFpbnMgaXMgYSBiYXNpYyByZXF1aXJlbWVudC48L3NwYW4+PG86cD48L286 cD48L3A+PHAgc3R5bGU9J21hcmdpbi1sZWZ0Oi4yNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+PHAgc3R5bGU9J21hcmdpbi1sZWZ0Oi4yNWluJz48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz4yLjwv c3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QnPiZuYnNwOyA8 L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7 Y29sb3I6IzFGNDk3RCc+QSBjbGVhciBzZXBhcmF0aW9uIGJldHdlZW4gc2VydmljZS1pbmRlcGVu ZGVudCBhbmQgc2VydmljZS1kZXBlbmRlbnQgcGllY2VzIGluIGNsb3VkIHNlcnZpY2VzLiBTT1Ag aXMgYWJvdXQgc2VydmljZS1pbmRlcGVuZGVudCBwaWVjZXMuIFVzaW5nIFNPUCwgYSB2YXJpZXR5 IG9mIHNlcnZpY2VzIGNvdWxkIGJlIGFjY2Vzc2VkIG9yIGFkdmVydGl6ZWQuIFNlcGFyYXRpb24g YmV0d2VlbiBzZXJ2aWNlLWluZGVwZW5kZW50IGFuZCBzZXJ2aWNlLWRlcGVuZGVudCBwaWVjZXMg bWFrZXMgdGhlIHNjaGVtZSBleHRlbnNpYmxlIHRvIGFueSB0eXBlIG9mIHNlcnZpY2Ug4oCTIGN1 cnJlbnQgb3IgZnV0dXJlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBzdHlsZT0nbWFyZ2luLWxl ZnQ6LjI1aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNv bGFzO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBzdHlsZT0n bWFyZ2luLWxlZnQ6LjI1aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPjMuPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNp emU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7IDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz5DcmVhdGUgYSBj b21tb24gc2NoZW1lIGZvciBzZXJ2aWNlIG9yY2hlc3RyYXRpb24gdGhhdCBjYW4gYmUgdXNlZCBh Y3Jvc3MgY29tcHV0ZSwgbmV0d29yaywgc3RvcmFnZSwgc2VjdXJpdHksIGFwcGxpY2F0aW9ucywg ZXRjLiBBIGNvbW1vbiBzZXQgb2YgY29uc3RydWN0cyB0aGF0IGNhbiBiZSBhcHBsaWVkIHRvIGFu eSBzZXJ2aWNlIHR5cGUgd2hldGhlciBpdCBpcyBpbmZyYXN0cnVjdHVyZSBvciBhcHBsaWNhdGlv bi48L3NwYW4+PG86cD48L286cD48L3A+PHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzJz48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1kYWxlbGEtb3JjaGVzdHJhdGlvbi0wMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRhbGVsYS1vcmNoZXN0cmF0aW9uLTAwPC9hPjwvc3Bh bj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcyc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OkNvbnNvbGFzJz5UaGUgYWJvdmUgZHJhZnQgZGVzY3JpYmVzIHRoZSBwcm9ibGVt cyBTT1AgaXMgYWltZWQgdG8gYWRkcmVzcy4gVGhpcyBpcyB0aGUg4oCccmVxdWlyZW1lbnRz4oCd IGRyYWZ0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcyc+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzJz5UaGUgb3RoZXIgZHJhZnRzIGFyZTo8L3Nw YW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTpDb25zb2xhcyc+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtZGFsZWxhLXNvcC1hcmNoaXRlY3R1cmUtMDAiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kYWxlbGEtc29wLWFyY2hpdGVjdHVyZS0wMDwvYT4g LSBkZXNjcmliZXMgdGhlIHVzZS1jYXNlcyBhbmQgbmV0d29yayBkZXBsb3ltZW50cyB3aXRoIHRo ZSBwcm90b2NvbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcyc+PGEgaHJlZj0i aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZGFsZWxhLXNvcC0wMCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRhbGVsYS1zb3AtMDA8L2E+ IC0gZGVzY3JpYmVzIHRoZSBwcm90b2NvbOKAmXMgbWVzc2FnZXMgPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OkNvbnNvbGFzJz48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1kYWxlbGEtc2RmLTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtZGFsZWxhLXNkZi0wMDwvYT4gLSBkZXNjcmliZXMgc2VydmljZSBuYW1pbmcs IHdvcmtmbG93IGNvbnN0cnVjdGlvbiwgZXRjLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpD b25zb2xhcyc+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZGFsZWxh LXNvcC1mbG93cy0wMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWRhbGVsYS1zb3AtZmxvd3MtMDA8L2E+IC0gZGVzY3JpYmVzIHNvbWUgbWVzc2FnZSBm bG93czwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcyc+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzJz5UaGFua3MsIEFzaGlzaDwvc3Bhbj48bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXYgc3R5bGU9J2Jv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiInPiBUaG9tYXMgTmFkZWF1IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnRuYWRlYXVA bHVjaWR2aXNpb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+dG5hZGVhdUBsdWNpZHZpc2lvbi5jb208 L2E+XSA8YnI+PGI+U2VudDo8L2I+IFRodXJzZGF5LCBGZWJydWFyeSAxNiwgMjAxMiA3OjU5IFBN PGJyPjxiPlRvOjwvYj4gTW9uaXF1ZSBNb3Jyb3cgKG1tb3Jyb3cpPGJyPjxiPkNjOjwvYj4gUGlu ZyBQYW47IDxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCIgdGFyZ2V0PSJfYmxhbmsi PnJvYmVydEByYXN6dWsubmV0PC9hPjsgc2RucDsgPGEgaHJlZj0ibWFpbHRvOnNvcEBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPnNvcEBpZXRmLm9yZzwvYT48YnI+PGI+U3ViamVjdDo8L2I+IFJl OiBbU2RucF0gRlc6IE5ldyBOb24tV0cgTWFpbGluZyBMaXN0OiBzb3AgLS0gU2VydmljZSBPcmNo ZXN0cmF0aW9uIGFuZCBEZXNjaXB0aW9uIGZvciBDbG91ZCBTZXJ2aWNlczwvc3Bhbj48bzpwPjwv bzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7 PG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpw PjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2FuIHlvdSBwbGVhc2Ug ZXhwbGFpbiB3aGF0IHRoZSBwdXJwb3NlIG9mIFNPUCBpcyBhbmQgd2hhdCBpdHMgZ29hbHMgYXJl PzxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+UGVvcGxlIG9uIHRoaXMg bGlzdCBoYXZlIGJlZW4gYWxzbyBhc2tpbmcgaG93IGl0IGRpZmZlcnMgZnJvbSBTRE4ocCksIHNv IGl0PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz5taWdodCBi ZSBoZWxwZnVsIHRvIGluY2x1ZGUgdGhhdCBhcyB3ZWxsLiA4KTxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tVG9tPG86cD48L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286cD48L3A+PGRpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPk9uIEZlYiAxNiwgMjAxMiwgYXQgOTowOSBBTSwgTW9uaXF1ZSBN b3Jyb3cgd3JvdGU6PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCc+PG86cD4mbmJz cDs8L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5HdXlzIDxicj48YnI+UGxl YXNlIGpvaW4gdGhlIFNPUCBtYWlsZXIgPGJyPjxicj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMnPjxicj5MaXN0IGFkZHJlc3M6IDx1Pjxz cGFuIHN0eWxlPSdjb2xvcjpibHVlJz5zb3BAaWV0Zi5vcmc8YnI+PC9zcGFuPjwvdT5BcmNoaXZl OiA8dT48c3BhbiBzdHlsZT0nY29sb3I6Ymx1ZSc+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL3NvcC8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvc29wLzwvYT48YnI+PC9zcGFuPjwvdT5UbyBzdWJzY3JpYmU6 IDx1PjxzcGFuIHN0eWxlPSdjb2xvcjpibHVlJz48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NvcCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc29wPC9hPjxicj48L3NwYW4+PC91Pjwvc3Bhbj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Jz48YnI+PGJyPlRJQTxicj48YnI+TW9uaXF1ZTxicj48YnI+PGJyPk9uIDIvMTQvMTIgMTA6NDUg UE0sICZxdW90O1BpbmcgUGFuJnF1b3Q7ICZsdDtwaW5nQHBpbmdwYW4ub3JnJmd0OyB3cm90ZTo8 YnI+PGJyPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5XaGVy ZSBkb2VzIE9wZW5TdGFjayBRdWFudHVtIGZpdD88YnI+PGJyPk9wZW5TdGFjayBRdWFudHVtIGlz IHRvIGhhdmUgYWdlbnRzIGluIGNvbnRyb2xsZXJzIGFuZCBuZXR3b3JraW5nIGRldmljZXMgZm9y IHRoZSBwdXJwb3NlIG9mIGJldHRlciB0cmFuc3BvcnQuIFRoaXMgaXMgd2VsbCB3aXRoaW4gdGhl IGdvYWwgb2YgU0ROLjxicj48YnI+UGluZzxicj48YnI+T24gVHVlLCBGZWIgMTQsIDIwMTIgYXQg MTozNyBQTSwgUm9iZXJ0IFJhc3p1ayAmbHQ7cm9iZXJ0QHJhc3p1ay5uZXQmZ3Q7IHdyb3RlOjwv c3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48YnI+QWN0dWFsbHkg SSB0aGluayB0aG9zZSBhcmUgcXVpdGUgc2VwYXJhdGUgcHJvYmxlbSBzcGFjZXMuPGJyPjxicj5T T1AgYWltIHRvIGFkZHJlc3MgdGhlIHJlcXVpcmVtZW50IG9mIGNsb3VkIHRvIGNsb3VkIGNvbW11 bmljYXRpb24gKGh5YnJpZCBvciBtdWx0aS1kb21haW4pLiBUaGUgd2F5IEkgdGhpbmsgYWJvdXQg dGhpcyBpcyBob3cgdG8gc3RhbmRhcmRpemUgYW5kIHN5bmNocm9uaXplIE9wZW5TdGFjayB0byBP cGVuU3RhY2sgaW5zdHJ1bWVudGF0aW9uIHNpZ25hbGluZy4gVGhlIG5leHQgc3RlcCB3b3VsZCBi ZSB0byBhY3R1YWxseSBhbHNvIHByb3ZpZGUgY2xvdWQgdG8gY2xvdWQgY29tbXVuaWNhdGlvbiBs YXllci4gU2ltcGxlIGV4YW1wbGU6IEhvdyB0byBsYXVuY2ggTiBWTXMgaW4gdmFyaW91cyBkYXRh IGNlbnRlcnMgdG8gYmUgcGFydCBvZiBjb21tb24gcmVzb3VyY2VzIGZvciBjdXN0b21lciBYLjxi cj48YnI+T24gdGhlIGNvbnRyYXJ5IFNETnggc2VlbXMgdG8gbWUgb2YgdG90YWxseSBkaWZmZXJl bnQgY2FsaWJlci4gT25lIHdheSB0byBsb29rIGF0IHRoaXMgaXMgd2hhdCBhbmQgaG93IHdlIGNv dWxkIHVzZSBBUElzIGV4cG9zZWQgYnkgZXhpc3RpbmcgbmV0d29yayBjb250cm9sIHBsYW5lcyB0 byBkZWZpbmUgYW5kIGFjY29tcGxpc2ggbmV3IG5ldHdvcmsgc2VydmljZXMuIEkgcXVpdGUgZG8g bm90IHNlZSBjdXJyZW50IG5ldHdvcmsgZWxlbWVudCBjb250cm9sIHBsYW5lcyBub3IgdGhlaXIg QVBJcyBhcyBtdWNoIHJlbGV2YW50IHRvIGNsb3VkIHNlcnZpY2VzLjxicj48YnI+TXkgb3duIHBl cnNvbmFsIHZpZXcgOyk8YnI+PGJyPlJlZ2FyZHMsPGJyPlIuPGJyPjxicj48YnI+PC9zcGFuPjxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPkknZCBsaWtlIHRvIGdldCBzb21l IGNsYXJpZmljYXRpb24gKGZyb20gYW55b25lIHdobyBtaWdodCBrbm93IG9yPGJyPmhhdmUgYW4g b3Bpbmlvbikgb24gaG93IHRoaXMgd291bGQgaW50ZXJhY3Qgd2l0aC9iZSBkaXN0aW5jdCBmcm9t IGFueTxicj5vZiB0aGUgU0ROUCAob3Igd2hhdGV2ZXIgbmFtZSB3ZSBkZWNpZGUgdXBvbikgcHJv cG9zZWQgd29yay4gSXMgdGhpczxicj5kdXBsaWNhdGlvbi9wZW9wbGUgc3RyaWtpbmcgb3V0IG9u IHRoZWlyIG93biBmcm9tIHRoZSBuYXNjZW50IFNETlA8YnI+ZWZmb3J0LCBhIGNvbXBhbmlvbiBl ZmZvcnQgdGhhdCBiZWNhbWUgY2xlYXIgYXMgd2UgaGF2ZSBiZWd1bjxicj5zZWdtZW50aW5nIHRo ZSBwcm9ibGVtIHNwYWNlLCBvciBzb21ldGhpbmcgZWxzZSBlbnRpcmVseT8gU2luY2UgdGhpczxi cj5pcyB0aGUgZmlyc3QgSSd2ZSBoZWFyZCBvZiB0aGUgbGlzdCwgSSdtIHRoaW5raW5nIGl0J3Mg YSBzZXBhcmF0ZTxicj5lZmZvcnQsIGJ1dCBJIGZpZ3VyZWQgSSB3b3VsZCByYWlzZSB0aGUgdG9w aWMgZm9yIGRpc2N1c3Npb24uPGJyPjxicj5UaGFua3MsPGJyPjxicj5XZXMgR2VvcmdlPGJyPjxi cj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBpZXRmLWFubm91bmNlLWJvdW5jZXNA aWV0Zi5vcmc8YnI+WzxhIGhyZWY9Im1haWx0bzppZXRmLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86aWV0Zi1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3Jn PC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGYtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPm1haWx0bzppZXRmLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ Jmd0OyBdIE9uIEJlaGFsZiBPZiBJRVRGPGJyPlNlY3JldGFyaWF0IFNlbnQ6IFR1ZXNkYXksIEZl YnJ1YXJ5IDE0LCAyMDEyIDI6MjUgUE0gVG86IElFVEY8YnI+QW5ub3VuY2VtZW50IGxpc3QgQ2M6 IHNvcEBpZXRmLm9yZzsgTW9uaXF1ZSBNb3Jyb3cgU3ViamVjdDogTmV3PGJyPk5vbi1XRyBNYWls aW5nIExpc3Q6IHNvcCAtLSBTZXJ2aWNlIE9yY2hlc3RyYXRpb24gYW5kIERlc2NpcHRpb24gZm9y PGJyPkNsb3VkIFNlcnZpY2VzPGJyPjxicj48YnI+PGJyPkEgbmV3IElFVEYgbm9uLXdvcmtpbmcg Z3JvdXAgZW1haWwgbGlzdCBoYXMgYmVlbiBjcmVhdGVkLjxicj48YnI+TGlzdCBhZGRyZXNzOiBz b3BAaWV0Zi5vcmcgQXJjaGl2ZTo8YnI+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL3NvcC8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvc29wLzwvYT4gJmx0OzxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9zb3AvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL3NvcC88L2E+Jmd0OyAmbmJzcDtUbyBzdWJzY3JpYmU6PGJyPjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29wIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb3A8L2E+ICZs dDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvcCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29wPC9h PiZndDsgPGJyPjxicj5QdXJwb3NlOiBDbG91ZCBzZXJ2aWNlcyBuZWVkIHRvIGludGVyb3BlcmF0 ZSBhY3Jvc3MgY2xvdWQgcHJvdmlkZXJzLDxicj5zZXJ2aWNlIHZlbmRvcnMgYW5kIHByaXZhdGUv cHVibGljIGRvbWFpbnMuIFRvIGVuYWJsZSB0aGlzPGJyPmludGVyb3BlcmFiaWxpdHksIHRoZXJl IGlzIG5lZWQgZm9yIGEgc3RhbmRhcmQgd2lyZS1mb3JtYXQgZm9yPGJyPmV4Y2hhbmdpbmcgc2Vy dmljZSBpbmZvcm1hdGlvbi4gVGhpcyBtYWlsaW5nIGxpc3RzIGlzIGZvciBkaXNjdXNzaW5nPGJy PnByb3RvY29scywgZGF0YSBmb3JtYXRzIGFuZCBzZXJ2ZXIgZGVzY3JpcHRpb25zIGZvcm1hdHMg dGhhdCBhbGxvdzxicj5jbG91ZCBzZXJ2aWNlcyB0byBiZSBkaXNjb3ZlcmVkIGFuZCB1c2VkIGFj cm9zcyBwcml2YXRlIGFuZCBwdWJsaWM8YnI+ZG9tYWlucy4gVXNpbmcgdGhlc2UsIGl0IHdvdWxk IGJlIHBvc3NpYmxlIHRvIGludGVyb3BlcmF0ZSBkaXZlcnNlPGJyPkFQSXMgYW5kIGNsb3VkIHNl cnZpY2VzIGFjcm9zcyBzZXJ2aWNlIHByb3ZpZGVycywgc2VydmljZSB2ZW5kb3JzIGFuZDxicj5z ZXJ2aWNlIHVzZXJzLjxicj48YnI+Rm9yIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24sIHBsZWFzZSBj b250YWN0IHRoZSBsaXN0IGFkbWluaXN0cmF0b3JzLjxicj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXyBJRVRGLUFubm91bmNlIG1haWxpbmc8YnI+bGlzdCBJ RVRGLUFubm91bmNlQGlldGYub3JnPGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaWV0Zi1hbm5vdW5jZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWV0Zi1hbm5vdW5jZTwvYT4gJmx0OzxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWV0Zi1hbm5vdW5jZSIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWV0Zi1h bm5vdW5jZTwvYT4mZ3Q7IDxicj48YnI+VGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGU8YnI+cHJvcHJpZXRhcnkgaW5mb3Jt YXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3I8YnI+c3ViamVjdCB0 byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBp czxicj5pbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50 aXR5IHRvIHdoaWNoIGl0PGJyPmlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCw8YnI+eW91IGFyZSBoZXJlYnkgbm90aWZpZWQg dGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLDxicj5jb3B5aW5nLCBvciBhY3Rp b24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZDxicj5hdHRhY2htZW50 cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmU8YnI+dW5s YXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5PGJyPnRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0 aGUgb3JpZ2luYWwgYW5kIGFueTxicj5jb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRv dXQuPGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIFNE TlAgbWFpbGluZyBsaXN0PGJyPlNETlBAbHVjaWR2aXNpb24uY29tIDxhIGhyZWY9Imh0dHA6Ly9s dWNpZHZpc2lvbi5jb20vbWFpbG1hbi9saXN0aW5mby9zZG5wIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cDovL2x1Y2lkdmlzaW9uLmNvbS9tYWlsbWFuL2xpc3RpbmZvL3NkbnA8L2E+ICZsdDs8YSBocmVm PSJodHRwOi8vbHVjaWR2aXNpb24uY29tL21haWxtYW4vbGlzdGluZm8vc2RucCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHA6Ly9sdWNpZHZpc2lvbi5jb20vbWFpbG1hbi9saXN0aW5mby9zZG5wPC9hPiZn dDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxi cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5TRE5Q IG1haWxpbmcgbGlzdDxicj5TRE5QQGx1Y2lkdmlzaW9uLmNvbTxicj48YSBocmVmPSJodHRwOi8v bHVjaWR2aXNpb24uY29tL21haWxtYW4vbGlzdGluZm8vc2RucCIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHA6Ly9sdWNpZHZpc2lvbi5jb20vbWFpbG1hbi9saXN0aW5mby9zZG5wPC9hPiAmbHQ7PGEgaHJl Zj0iaHR0cDovL2x1Y2lkdmlzaW9uLmNvbS9tYWlsbWFuL2xpc3RpbmZvL3NkbnAiIHRhcmdldD0i X2JsYW5rIj5odHRwOi8vbHVjaWR2aXNpb24uY29tL21haWxtYW4vbGlzdGluZm8vc2RucDwvYT4m Z3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+PGRpdiBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0 eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PGhyIHNpemU9MyB3aWR0aD0iOTUlIiBh bGlnbj1jZW50ZXI+PC9zcGFuPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzJz5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5TRE5QIG1haWxpbmcgbGlzdDxicj5T RE5QQGx1Y2lkdmlzaW9uLmNvbTxicj48YSBocmVmPSJodHRwOi8vbHVjaWR2aXNpb24uY29tL21h aWxtYW4vbGlzdGluZm8vc2RucCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9sdWNpZHZpc2lvbi5j b20vbWFpbG1hbi9saXN0aW5mby9zZG5wPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvJz5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj5TRE5QIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86U0ROUEBs dWNpZHZpc2lvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5TRE5QQGx1Y2lkdmlzaW9uLmNvbTwvYT48 YnI+PGEgaHJlZj0iaHR0cDovL2x1Y2lkdmlzaW9uLmNvbS9tYWlsbWFuL2xpc3RpbmZvL3NkbnAi IHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbHVjaWR2aXNpb24uY29tL21haWxtYW4vbGlzdGluZm8v c2RucDwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8 bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48YnI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+c29wIG1haWxpbmcgbGlzdDxicj48YSBo cmVmPSJtYWlsdG86c29wQGlldGYub3JnIj5zb3BAaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29wIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb3A8L2E+PG86cD48L286cD48 L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2Pjwv ZGl2PjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ ------_=_NextPart_001_01CCECC1.0B16EA09-- From mphmmr@gmail.com Thu Feb 16 07:39:45 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A533121F87FF for ; Thu, 16 Feb 2012 07:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.781 X-Spam-Level: X-Spam-Status: No, score=-2.781 tagged_above=-999 required=5 tests=[AWL=0.817, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 FbYFpXsmDPEa for ; Thu, 16 Feb 2012 07:39:41 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 50E0221F87AD for ; Thu, 16 Feb 2012 07:39:40 -0800 (PST) Received: by eaal12 with SMTP id l12so828648eaa.31 for ; Thu, 16 Feb 2012 07:39:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+BiQ0qWVZneYn5vrNIlG+i3IlOanOyW1PbPKNFOaL4U=; b=AYqcFktisFeTkRBIkKulDkW8J3YNBDOmSx7IYwKTyvGIBLCAmyyzFxCyHrLi8P1hq8 Yl9eoOjtlLLS4vBg4pT1CDQOkqngxfUKVHgGGm7lfCarfdBXwaSW+FP/5NsAmrl5Id6R Ho12Fv0qfXXoB7+oMVwfI+iebQdy0MLA9TE44= MIME-Version: 1.0 Received: by 10.112.86.106 with SMTP id o10mr1120482lbz.27.1329406779282; Thu, 16 Feb 2012 07:39:39 -0800 (PST) Received: by 10.112.104.70 with HTTP; Thu, 16 Feb 2012 07:39:39 -0800 (PST) In-Reply-To: References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> Date: Thu, 16 Feb 2012 10:39:39 -0500 Message-ID: From: Michael Hammer To: Ping Pan Content-Type: multipart/alternative; boundary=bcaec554e108d754d704b916a238 Cc: Thomas Nadeau , robert@raszuk.net, sdnp , "Monique Morrow \(mmorrow\)" , sop@ietf.org, "Ashish Dalela \(adalela\)" Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 15:39:45 -0000 --bcaec554e108d754d704b916a238 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable All, The question I would ask is how many Cloud services do we think there will be long run. Then ask, how many times the same methods/commands will need to be re-invented: Create, Update, Delete? Also, ask yourself, if you have to do multiple of those cloud services in synchronized fashion, would a tool designed for just one of those answer the mail? Can we abstract out the common elements and cover and integrate component parts? Cloud seems to be in the state the telephone company found itself 100 years ago. Everything works fine so long as you do it Edison's way, or Tesla's or whomever. We had to go through a monopoly state before figuring out how to standardize. Looking to skip the monopoly phase this time around. Mike On Thu, Feb 16, 2012 at 10:23 AM, Ping Pan wrote: > Yeah, I have read all the drafts during the DC BoF discussion. In general= , > this makes sense... > > My thinking is that we may not want to standardize the interior DC > management, as each vendor has own solution. But at the same time, we nee= d > to enable applications and services to ride on top of DC resources. In > other words, SDN is in the position to enable Virtual DC's, and create th= e > interface to communicate with networking resources at abstraction level. > SDN should not be viewed as the NMS for DC's. > > There are a lot of work to be done here, and many parts are moving. Let's > work together. > > Ping > > > On Thu, Feb 16, 2012 at 7:02 AM, Ashish Dalela (adalela) < > adalela@cisco.com> wrote: > >> ** ** >> >> SOP has the following main goals =96 **** >> >> ** ** >> >> **1. **Fix interoperability issues with cloud services today. Main >> examples are inter-cloud, hybrid-cloud, and multi-vendor cloud. All clou= d >> services are being enabled through proprietary APIs today, which don=92t >> interoperate. To interoperate across vendors, providers and customers, w= e >> need an open standard. Ability to go across administrative domains is a >> basic requirement.**** >> >> ** ** >> >> **2. **A clear separation between service-independent and >> service-dependent pieces in cloud services. SOP is about >> service-independent pieces. Using SOP, a variety of services could be >> accessed or advertized. Separation between service-independent and >> service-dependent pieces makes the scheme extensible to any type of serv= ice >> =96 current or future.**** >> >> ** ** >> >> **3. **Create a common scheme for service orchestration that can be >> used across compute, network, storage, security, applications, etc. A >> common set of constructs that can be applied to any service type whether= it >> is infrastructure or application.**** >> >> ** ** >> >> http://tools.ietf.org/html/draft-dalela-orchestration-00**** >> >> ** ** >> >> The above draft describes the problems SOP is aimed to address. This is >> the =93requirements=94 draft.**** >> >> ** ** >> >> The other drafts are:**** >> >> ** ** >> >> http://tools.ietf.org/html/draft-dalela-sop-architecture-00 - describes >> the use-cases and network deployments with the protocol**** >> >> http://tools.ietf.org/html/draft-dalela-sop-00 - describes the >> protocol=92s messages **** >> >> http://tools.ietf.org/html/draft-dalela-sdf-00 - describes service >> naming, workflow construction, etc.**** >> >> http://tools.ietf.org/html/draft-dalela-sop-flows-00 - describes some >> message flows**** >> >> ** ** >> >> Thanks, Ashish**** >> >> ** ** >> >> ** ** >> >> *From:* Thomas Nadeau [mailto:tnadeau@lucidvision.com] >> *Sent:* Thursday, February 16, 2012 7:59 PM >> *To:* Monique Morrow (mmorrow) >> *Cc:* Ping Pan; robert@raszuk.net; sdnp; sop@ietf.org >> *Subject:* Re: [Sdnp] FW: New Non-WG Mailing List: sop -- Service >> Orchestration and Desciption for Cloud Services**** >> >> ** ** >> >> ** ** >> >> Can you please explain what the purpose of SOP is and what >> its goals are?**** >> >> People on this list have been also asking how it differs from SDN(p), so >> it**** >> >> might be helpful to include that as well. 8)**** >> >> **** >> >> --Tom**** >> >> ** ** >> >> ** ** >> >> ** ** >> >> On Feb 16, 2012, at 9:09 AM, Monique Morrow wrote:**** >> >> >> >> **** >> >> Guys >> >> Please join the SOP mailer >> >> >> List address: *sop@ietf.org >> *Archive: *http://www.ietf.org/mail-archive/web/sop/ >> *To subscribe: *https://www.ietf.org/mailman/listinfo/sop >> * >> >> TIA >> >> Monique >> >> >> On 2/14/12 10:45 PM, "Ping Pan" wrote: >> >> >> **** >> >> Where does OpenStack Quantum fit? >> >> OpenStack Quantum is to have agents in controllers and networking device= s >> for the purpose of better transport. This is well within the goal of SDN= . >> >> Ping >> >> On Tue, Feb 14, 2012 at 1:37 PM, Robert Raszuk wrote= : >> >> **** >> >> >> Actually I think those are quite separate problem spaces. >> >> SOP aim to address the requirement of cloud to cloud communication >> (hybrid or multi-domain). The way I think about this is how to standardi= ze >> and synchronize OpenStack to OpenStack instrumentation signaling. The ne= xt >> step would be to actually also provide cloud to cloud communication laye= r. >> Simple example: How to launch N VMs in various data centers to be part o= f >> common resources for customer X. >> >> On the contrary SDNx seems to me of totally different caliber. One way t= o >> look at this is what and how we could use APIs exposed by existing netwo= rk >> control planes to define and accomplish new network services. I quite do >> not see current network element control planes nor their APIs as much >> relevant to cloud services. >> >> My own personal view ;) >> >> Regards, >> R. >> >> >> >> **** >> >> I'd like to get some clarification (from anyone who might know or >> have an opinion) on how this would interact with/be distinct from any >> of the SDNP (or whatever name we decide upon) proposed work. Is this >> duplication/people striking out on their own from the nascent SDNP >> effort, a companion effort that became clear as we have begun >> segmenting the problem space, or something else entirely? Since this >> is the first I've heard of the list, I'm thinking it's a separate >> effort, but I figured I would raise the topic for discussion. >> >> Thanks, >> >> Wes George >> >> -----Original Message----- From: ietf-announce-bounces@ietf.org >> [mailto:ietf-announce-bounces@ietf.org = < >> mailto:ietf-announce-bounces@ietf.org > >> ] On Behalf Of IETF >> Secretariat Sent: Tuesday, February 14, 2012 2:25 PM To: IETF >> Announcement list Cc: sop@ietf.org; Monique Morrow Subject: New >> Non-WG Mailing List: sop -- Service Orchestration and Desciption for >> Cloud Services >> >> >> >> A new IETF non-working group email list has been created. >> >> List address: sop@ietf.org Archive: >> http://www.ietf.org/mail-archive/web/sop/ < >> http://www.ietf.org/mail-archive/web/sop/> To subscribe: >> https://www.ietf.org/mailman/listinfo/sop < >> https://www.ietf.org/mailman/listinfo/sop> >> >> Purpose: Cloud services need to interoperate across cloud providers, >> service vendors and private/public domains. To enable this >> interoperability, there is need for a standard wire-format for >> exchanging service information. This mailing lists is for discussing >> protocols, data formats and server descriptions formats that allow >> cloud services to be discovered and used across private and public >> domains. Using these, it would be possible to interoperate diverse >> APIs and cloud services across service providers, service vendors and >> service users. >> >> For additional information, please contact the list administrators. >> _______________________________________________ IETF-Announce mailing >> list IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce < >> https://www.ietf.org/mailman/listinfo/ietf-announce> >> >> This E-mail and any of its attachments may contain Time Warner Cable >> proprietary information, which is privileged, confidential, or >> subject to copyright belonging to Time Warner Cable. This E-mail is >> intended solely for the use of the individual or entity to which it >> is addressed. If you are not the intended recipient of this E-mail, >> you are hereby notified that any dissemination, distribution, >> copying, or action taken in relation to the contents of and >> attachments to this E-mail is strictly prohibited and may be >> unlawful. If you have received this E-mail in error, please notify >> the sender immediately and permanently delete the original and any >> copy of this E-mail and any printout. >> _______________________________________________ SDNP mailing list >> SDNP@lucidvision.com http://lucidvision.com/mailman/listinfo/sdnp < >> http://lucidvision.com/mailman/listinfo/sdnp> >> >> **** >> >> >> _______________________________________________ >> SDNP mailing list >> SDNP@lucidvision.com >> http://lucidvision.com/mailman/listinfo/sdnp < >> http://lucidvision.com/mailman/listinfo/sdnp> **** >> >> ** ** >> ------------------------------ >> >> _______________________________________________ >> SDNP mailing list >> SDNP@lucidvision.com >> http://lucidvision.com/mailman/listinfo/sdnp**** >> >> _______________________________________________ >> SDNP mailing list >> SDNP@lucidvision.com >> http://lucidvision.com/mailman/listinfo/sdnp**** >> >> ** ** >> >> _______________________________________________ >> sop mailing list >> sop@ietf.org >> https://www.ietf.org/mailman/listinfo/sop >> >> > > _______________________________________________ > sop mailing list > sop@ietf.org > https://www.ietf.org/mailman/listinfo/sop > > --bcaec554e108d754d704b916a238 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable All,

The question I would ask is how many Cloud services= do we think there will be long run.
Then ask, how many times the= same methods/commands will need to be re-invented: =A0Create, Update, Dele= te?

Also, ask yourself, if you have to do multiple of those= cloud services in synchronized fashion, would a tool designed for just one= of those answer the mail?
Can we abstract out the common element= s and cover and integrate component parts?

Cloud seems to be in the state the telephone company fo= und itself 100 years ago. =A0Everything works fine so long as you do it Edi= son's way, or Tesla's or whomever. =A0We had to go through a monopo= ly state before figuring out how to standardize. =A0Looking to skip the mon= opoly phase this time around.

Mike


On Th= u, Feb 16, 2012 at 10:23 AM, Ping Pan <ping@pingpan.org> wrote:
Yeah, I have read all the drafts during the DC BoF discussion. In general, = this makes sense...

My thinking is that we may not want = to standardize the interior DC management, as each vendor has own solution.= =A0But at the same time, we need to enable applications and services to rid= e on top of DC resources. In other words, SDN is in the position to enable = Virtual=A0DC's, and create the interface to communicate with networking= resources at=A0abstraction=A0level. SDN should not be viewed as the NMS fo= r DC's.

There are a lot of work to be done here, and many parts= are moving. Let's work together.

Ping

On Thu, Feb 16, = 2012 at 7:02 AM, Ashish Dalela (adalela) <adalela@cisco.com>= wrote:

= =A0

SOP has the following main goals =96 <= /p>

=A0

1.=A0 Fix interoperability issues wit= h cloud services today. Main examples are inter-cloud, hybrid-cloud, and mu= lti-vendor cloud. All cloud services are being enabled through proprietary = APIs today, which don=92t interoperate. To interoperate across vendors, pro= viders and customers, we need an open standard. Ability to go across admini= strative domains is a basic requirement.

=A0

2.=A0 = A clear separation between service-independent and ser= vice-dependent pieces in cloud services. SOP is about service-independent p= ieces. Using SOP, a variety of services could be accessed or advertized. Se= paration between service-independent and service-dependent pieces makes the= scheme extensible to any type of service =96 current or future.<= /u>

=A0

3.=A0 = Create a common scheme for service orchestration that = can be used across compute, network, storage, security, applications, etc. = A common set of constructs that can be applied to any service type whether = it is infrastructure or application.

<= /u>=A0

http://tools.ietf.org/html/draft-dale= la-orchestration-00

=A0

The above draft describes the problems SOP = is aimed to address. This is the =93requirements=94 draft.

=A0

The other drafts are:<= /p>

=A0

http://tools.ietf.org/html/draft-dalela-sop-archite= cture-00 - describes the use-cases and network deployments with the pro= tocol

http://tools.ietf.org/html/draft-dalela-sop-00 - describes the prot= ocol=92s messages

http://tools.ietf.org/html/draft-dalela-sdf-00 - describes service = naming, workflow construction, etc.

http://tools.ietf.org/html/draft-dalela-sop-flows-00 - desc= ribes some message flows

=A0

Thanks, Ashish

=A0

=A0

From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]
Sent: Thursday, February 16, 2012 7:59 PM
To: Monique Morr= ow (mmorrow)
Cc: Ping Pan; robert@raszuk.net; sdnp; sop@ietf.org
Subject: Re: [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orch= estration and Desciption for Cloud Services

<= /div>

=A0

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Can you please explain what th= e purpose of SOP is and what its goals are?

People on this list have been also asking how it differs fro= m SDN(p), so it

might be helpful to include that as well.= 8)

=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 --Tom

=A0

=A0

=A0

On Feb 16, 2012, at 9:09 A= M, Monique Morrow wrote:



Guys

Please join the SOP mailer


List address: sop@ietf.org
<= /u>Archive: http://www.ietf.org/mail-archive/web= /sop/
To subscribe: https://www.ietf.org/ma= ilman/listinfo/sop


TIA

Monique


On 2/14/12 10:45 PM, "Ping Pan"= <ping@pingpan.org> wrote:


Where does OpenStack Quantum fit?

OpenStack Quantum is to have agents in controllers and networking devic= es for the purpose of better transport. This is well within the goal of SDN= .

Ping

On Tue, Feb 14, 2012 at 1:37 PM, Robert Raszuk <= robert@raszuk.net> wrote:


Actual= ly I think those are quite separate problem spaces.

SOP aim to addre= ss the requirement of cloud to cloud communication (hybrid or multi-domain)= . The way I think about this is how to standardize and synchronize OpenStac= k to OpenStack instrumentation signaling. The next step would be to actuall= y also provide cloud to cloud communication layer. Simple example: How to l= aunch N VMs in various data centers to be part of common resources for cust= omer X.

On the contrary SDNx seems to me of totally different caliber. One way = to look at this is what and how we could use APIs exposed by existing netwo= rk control planes to define and accomplish new network services. I quite do= not see current network element control planes nor their APIs as much rele= vant to cloud services.

My own personal view ;)

Regards,
R.



=

I'd like to get some clarification (from anyone who might know o= r
have an opinion) on how this would interact with/be distinct from any
of= the SDNP (or whatever name we decide upon) proposed work. Is this
dupli= cation/people striking out on their own from the nascent SDNP
effort, a = companion effort that became clear as we have begun
segmenting the problem space, or something else entirely? Since this
is = the first I've heard of the list, I'm thinking it's a separate<= br>effort, but I figured I would raise the topic for discussion.

Thanks,

Wes George

-----Original Message----- From: ietf-a= nnounce-bounces@ietf.org
[mailto:ietf-announce-bounces@ietf.org <mailto:iet= f-announce-bounces@ietf.org> ] On Behalf Of IETF
Secretariat Sent: Tuesday, February 14, 2012 2:25 PM To: IETF
Announceme= nt list Cc: sop@ietf.org; Monique Morrow Subject: New
Non-WG Mail= ing List: sop -- Service Orchestration and Desciption for
Cloud Services=



A new IETF non-working group email list has been created.
List address: sop@ietf.org Archive:
http://www.ietf.org/mail-archi= ve/web/sop/ <http://www.ietf.org/mail-archive/web/sop/> =A0To su= bscribe:
htt= ps://www.ietf.org/mailman/listinfo/sop <https://www.ietf.org/mailman/li= stinfo/sop>

Purpose: Cloud services need to interoperate across cloud providers,service vendors and private/public domains. To enable this
interoperabi= lity, there is need for a standard wire-format for
exchanging service in= formation. This mailing lists is for discussing
protocols, data formats and server descriptions formats that allow
cloud= services to be discovered and used across private and public
domains. U= sing these, it would be possible to interoperate diverse
APIs and cloud = services across service providers, service vendors and
service users.

For additional information, please contact the list a= dministrators.
_______________________________________________ IETF-Anno= unce mailing
list IETF-Announce@ietf.org
https://www.ie= tf.org/mailman/listinfo/ietf-announce <https://www.ietf.org/m= ailman/listinfo/ietf-announce>

This E-mail and any of its attachments may contain Time Warner Cableproprietary information, which is privileged, confidential, or
subject = to copyright belonging to Time Warner Cable. This E-mail is
intended sol= ely for the use of the individual or entity to which it
is addressed. If you are not the intended recipient of this E-mail,
you = are hereby notified that any dissemination, distribution,
copying, or ac= tion taken in relation to the contents of and
attachments to this E-mail= is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify
the s= ender immediately and permanently delete the original and any
copy of th= is E-mail and any printout.
____________________________________________= ___ SDNP mailing list
SDNP@lucidvision.com http://lucidvision.com/mailman/listinfo/sdnp <http://lucidvision.com/mailman/listinfo/sdnp>


______= _________________________________________
SDNP mailing list
SDNP@l= ucidvision.com
= http://lucidvision.com/mailman/listinfo/sdnp <http://lucidvision.com= /mailman/listinfo/sdnp>

= =A0

_= ______________________________________________
SDNP mailing list
SDNP@lucidvision.com
http://lucidvision.com/= mailman/listinfo/sdnp

_______________________________________________
SDNP mailing list
SDNP@lucidvision.com=
http://lucidvision.com/mailman/listinfo/sdnp

=A0

<= /div>
____________________________________= ___________
sop mailing list
sop@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sop



_______________________________________________
sop mailing list
sop@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sop


--bcaec554e108d754d704b916a238-- From ping@pingpan.org Thu Feb 16 07:52:16 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D244721F86D7 for ; Thu, 16 Feb 2012 07:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 Ar1emZqhbB0T for ; Thu, 16 Feb 2012 07:52:12 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with SMTP id 385F721F85C4 for ; Thu, 16 Feb 2012 07:52:11 -0800 (PST) Received: from mail-qw0-f44.google.com ([209.85.216.44]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTz0mKogTBf8CxCsDjnw3hr2Jp2QH3Vvm@postini.com; Thu, 16 Feb 2012 07:52:11 PST Received: by qafi29 with SMTP id i29so4488332qaf.10 for ; Thu, 16 Feb 2012 07:52:10 -0800 (PST) Received: by 10.229.105.141 with SMTP id t13mr2034685qco.108.1329407529955; Thu, 16 Feb 2012 07:52:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.80.200 with HTTP; Thu, 16 Feb 2012 07:51:28 -0800 (PST) In-Reply-To: <618BE8B40039924EB9AED233D4A09C5103001E8E@XMB-BGL-416.cisco.com> References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C5103001E8E@XMB-BGL-416.cisco.com> From: Ping Pan Date: Thu, 16 Feb 2012 07:51:28 -0800 Message-ID: To: "Ashish Dalela (adalela)" Content-Type: multipart/alternative; boundary=00235429cfac95b22004b916cf4a X-Gm-Message-State: ALoCoQnSfqmFrgjMZTCW6WzxfvBaEvRSwRl4Y5e48TL6M4AqttSh4xQPU0pMM/CL8cYn145n1wLA Cc: Thomas Nadeau , "Monique Morrow \(mmorrow\)" , sop@ietf.org, robert@raszuk.net, sdnp Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 15:52:16 -0000 --00235429cfac95b22004b916cf4a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There are talks on more control from applications to the networks. IMHO, this is more of a misunderstanding than anything else. First, many DC operators have leased the circuits or built the network. They have every right to decide the policy at edge and aggregate traffic onto the network they lease or own. Second, I think that the service providers would have no problem to expedite the BW provisioning process when a customer is asking for more, but no service provider to my best knowledge would allow the customers to alter the routes inside their networks. So deep-control to me means a cleaner, simpler and faster way to provisioning network resources through a consistent interface. Ping On Thu, Feb 16, 2012 at 7:38 AM, Ashish Dalela (adalela) wrote: > ** ** > > Well, yes, one of the use-case is to solve interoperability issues betwee= n > and across clouds.**** > > ** ** > > I also have heard from folks the need for =E2=80=9Cdeep control=E2=80=9D = in which a > customer outside the cloud wants to tweak or control the infrastructure o= r > application at a low granularity. I think that would be hard, although no= t > impossible, if the mechanisms outside and inside were different =E2=80=93= as you > will have to create mappings.**** > > ** ** > > That is a topic quite open for discussion.**** > > ** ** > > Thanks, Ashish**** > > ** ** > > ** ** > > *From:* Ping Pan [mailto:ping@pingpan.org] > *Sent:* Thursday, February 16, 2012 8:54 PM > *To:* Ashish Dalela (adalela) > *Cc:* Thomas Nadeau; Monique Morrow (mmorrow); sdnp; sop@ietf.org; > robert@raszuk.net > *Subject:* Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service > Orchestration and Desciption for Cloud Services**** > > ** ** > > Yeah, I have read all the drafts during the DC BoF discussion. In general= , > this makes sense...**** > > ** ** > > My thinking is that we may not want to standardize the interior DC > management, as each vendor has own solution. But at the same time, we nee= d > to enable applications and services to ride on top of DC resources. In > other words, SDN is in the position to enable Virtual DC's, and create th= e > interface to communicate with networking resources at abstraction level. > SDN should not be viewed as the NMS for DC's.**** > > ** ** > > There are a lot of work to be done here, and many parts are moving. Let's > work together.**** > > ** ** > > Ping**** > > ** ** > > ** ** > > On Thu, Feb 16, 2012 at 7:02 AM, Ashish Dalela (adalela) < > adalela@cisco.com> wrote:**** > > **** > > SOP has the following main goals =E2=80=93 **** > > **** > > 1. Fix interoperability issues with cloud services today. Main examples > are inter-cloud, hybrid-cloud, and multi-vendor cloud. All cloud services > are being enabled through proprietary APIs today, which don=E2=80=99t int= eroperate. > To interoperate across vendors, providers and customers, we need an open > standard. Ability to go across administrative domains is a basic > requirement.**** > > **** > > 2. A clear separation between service-independent and service-dependent > pieces in cloud services. SOP is about service-independent pieces. Using > SOP, a variety of services could be accessed or advertized. Separation > between service-independent and service-dependent pieces makes the scheme > extensible to any type of service =E2=80=93 current or future.**** > > **** > > 3. Create a common scheme for service orchestration that can be used > across compute, network, storage, security, applications, etc. A common s= et > of constructs that can be applied to any service type whether it is > infrastructure or application.**** > > **** > > http://tools.ietf.org/html/draft-dalela-orchestration-00**** > > **** > > The above draft describes the problems SOP is aimed to address. This is > the =E2=80=9Crequirements=E2=80=9D draft.**** > > **** > > The other drafts are:**** > > **** > > http://tools.ietf.org/html/draft-dalela-sop-architecture-00 - describes > the use-cases and network deployments with the protocol**** > > http://tools.ietf.org/html/draft-dalela-sop-00 - describes the protocol= =E2=80=99s > messages **** > > http://tools.ietf.org/html/draft-dalela-sdf-00 - describes service > naming, workflow construction, etc.**** > > http://tools.ietf.org/html/draft-dalela-sop-flows-00 - describes some > message flows**** > > **** > > Thanks, Ashish**** > > **** > > **** > > *From:* Thomas Nadeau [mailto:tnadeau@lucidvision.com] > *Sent:* Thursday, February 16, 2012 7:59 PM > *To:* Monique Morrow (mmorrow) > *Cc:* Ping Pan; robert@raszuk.net; sdnp; sop@ietf.org > *Subject:* Re: [Sdnp] FW: New Non-WG Mailing List: sop -- Service > Orchestration and Desciption for Cloud Services**** > > **** > > **** > > Can you please explain what the purpose of SOP is and what it= s > goals are?**** > > People on this list have been also asking how it differs from SDN(p), so = it > **** > > might be helpful to include that as well. 8)**** > > **** > > --Tom**** > > **** > > **** > > **** > > On Feb 16, 2012, at 9:09 AM, Monique Morrow wrote:**** > > ** ** > > Guys > > Please join the SOP mailer > > > List address: *sop@ietf.org > *Archive: *http://www.ietf.org/mail-archive/web/sop/ > *To subscribe: *https://www.ietf.org/mailman/listinfo/sop > * > > TIA > > Monique > > > On 2/14/12 10:45 PM, "Ping Pan" wrote: > > **** > > Where does OpenStack Quantum fit? > > OpenStack Quantum is to have agents in controllers and networking devices > for the purpose of better transport. This is well within the goal of SDN. > > Ping > > On Tue, Feb 14, 2012 at 1:37 PM, Robert Raszuk wrote:= * > *** > > > Actually I think those are quite separate problem spaces. > > SOP aim to address the requirement of cloud to cloud communication (hybri= d > or multi-domain). The way I think about this is how to standardize and > synchronize OpenStack to OpenStack instrumentation signaling. The next st= ep > would be to actually also provide cloud to cloud communication layer. > Simple example: How to launch N VMs in various data centers to be part of > common resources for customer X. > > On the contrary SDNx seems to me of totally different caliber. One way to > look at this is what and how we could use APIs exposed by existing networ= k > control planes to define and accomplish new network services. I quite do > not see current network element control planes nor their APIs as much > relevant to cloud services. > > My own personal view ;) > > Regards, > R. > > > **** > > I'd like to get some clarification (from anyone who might know or > have an opinion) on how this would interact with/be distinct from any > of the SDNP (or whatever name we decide upon) proposed work. Is this > duplication/people striking out on their own from the nascent SDNP > effort, a companion effort that became clear as we have begun > segmenting the problem space, or something else entirely? Since this > is the first I've heard of the list, I'm thinking it's a separate > effort, but I figured I would raise the topic for discussion. > > Thanks, > > Wes George > > -----Original Message----- From: ietf-announce-bounces@ietf.org > [mailto:ietf-announce-bounces@ietf.org < > mailto:ietf-announce-bounces@ietf.org > ] > On Behalf Of IETF > Secretariat Sent: Tuesday, February 14, 2012 2:25 PM To: IETF > Announcement list Cc: sop@ietf.org; Monique Morrow Subject: New > Non-WG Mailing List: sop -- Service Orchestration and Desciption for > Cloud Services > > > > A new IETF non-working group email list has been created. > > List address: sop@ietf.org Archive: > http://www.ietf.org/mail-archive/web/sop/ < > http://www.ietf.org/mail-archive/web/sop/> To subscribe: > https://www.ietf.org/mailman/listinfo/sop < > https://www.ietf.org/mailman/listinfo/sop> > > Purpose: Cloud services need to interoperate across cloud providers, > service vendors and private/public domains. To enable this > interoperability, there is need for a standard wire-format for > exchanging service information. This mailing lists is for discussing > protocols, data formats and server descriptions formats that allow > cloud services to be discovered and used across private and public > domains. Using these, it would be possible to interoperate diverse > APIs and cloud services across service providers, service vendors and > service users. > > For additional information, please contact the list administrators. > _______________________________________________ IETF-Announce mailing > list IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce < > https://www.ietf.org/mailman/listinfo/ietf-announce> > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or > subject to copyright belonging to Time Warner Cable. This E-mail is > intended solely for the use of the individual or entity to which it > is addressed. If you are not the intended recipient of this E-mail, > you are hereby notified that any dissemination, distribution, > copying, or action taken in relation to the contents of and > attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any > copy of this E-mail and any printout. > _______________________________________________ SDNP mailing list > SDNP@lucidvision.com http://lucidvision.com/mailman/listinfo/sdnp < > http://lucidvision.com/mailman/listinfo/sdnp> **** > > > _______________________________________________ > SDNP mailing list > SDNP@lucidvision.com > http://lucidvision.com/mailman/listinfo/sdnp < > http://lucidvision.com/mailman/listinfo/sdnp> **** > > **** > ------------------------------ > > _______________________________________________ > SDNP mailing list > SDNP@lucidvision.com > http://lucidvision.com/mailman/listinfo/sdnp**** > > _______________________________________________ > SDNP mailing list > SDNP@lucidvision.com > http://lucidvision.com/mailman/listinfo/sdnp**** > > **** > > > _______________________________________________ > sop mailing list > sop@ietf.org > https://www.ietf.org/mailman/listinfo/sop**** > > ** ** > --00235429cfac95b22004b916cf4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There are talks on more control from applications to the networks.

=
IMHO, this is more of a misunderstanding than anything else.=C2= =A0

First, many DC operators have leased the circu= its or built the network. They have every right to decide the policy at edg= e and aggregate traffic onto the network they lease or own. Second, I think= that the service providers would have no problem to=C2=A0expedite=C2=A0the= BW provisioning process when a customer is asking for more, but no service= provider to my best knowledge would allow the customers to alter the route= s inside their networks.

So deep-control to me means a cleaner, simpler and fast= er way to provisioning network resources through a consistent interface.

Ping

On Thu= , Feb 16, 2012 at 7:38 AM, Ashish Dalela (adalela) <adalela@cisco.com> wrote:<= br>

=C2=A0=

Well, yes, one of the use= -case is to solve interoperability issues between and across clouds.=

=C2=A0

I also have heard f= rom folks the need for =E2=80=9Cdeep control=E2=80=9D in which a customer o= utside the cloud wants to tweak or control the infrastructure or applicatio= n at a low granularity. I think that would be hard, although not impossible= , if the mechanisms outside and inside were different =E2=80=93 as you will= have to create mappings.

=C2=A0

That is a topic qui= te open for discussion.

=C2=A0

Thanks, Ashish

=C2=A0

=C2=A0

From: Ping Pan [mailto:pi= ng@pingpan.org]
Sent: Thursday, February 16, 2012 8:54 PM
To: Ashish Dalel= a (adalela)
Cc: Thomas Nadeau; Monique Morrow (mmorrow); sdnp; sop@ietf.org; robert@raszuk.net
Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Servic= e Orchestration and Desciption for Cloud Services

<= /div>

=C2=A0

=

Yeah, I have read all the drafts during the DC BoF discussion. In general, = this makes sense...

=C2= =A0

My thinking is that we may = not want to standardize the interior DC management, as each vendor has own = solution.=C2=A0But at the same time, we need to enable applications and ser= vices to ride on top of DC resources. In other words, SDN is in the positio= n to enable Virtual=C2=A0DC's, and create the interface to communicate = with networking resources at=C2=A0abstraction=C2=A0level. SDN should not be= viewed as the NMS for DC's.

=C2=A0

There are a lot of work to be done here, and many parts ar= e moving. Let's work together.

=C2=A0

Ping

=C2=A0

=C2=A0

On Thu, Feb 16, 2012= at 7:02 AM, Ashish Dalela (adalela) <adalela@cisco.com> wrote:

=C2=A0

SO= P has the following main goals =E2=80=93

=C2=A0

1.=C2=A0 Fix interoperabil= ity issues with cloud services today. Main examples are inter-cloud, hybrid= -cloud, and multi-vendor cloud. All cloud services are being enabled throug= h proprietary APIs today, which don=E2=80=99t interoperate. To interoperate= across vendors, providers and customers, we need an open standard. Ability= to go across administrative domains is a basic requirement.<= u>

=C2=A0

2.=C2=A0 A clear s= eparation between service-independent and service-dependent pieces in cloud= services. SOP is about service-independent pieces. Using SOP, a variety of= services could be accessed or advertized. Separation between service-indep= endent and service-dependent pieces makes the scheme extensible to any type= of service =E2=80=93 current or future.

=C2=A0

3.=C2=A0 Create a = common scheme for service orchestration that can be used across compute, ne= twork, storage, security, applications, etc. A common set of constructs tha= t can be applied to any service type whether it is infrastructure or applic= ation.

=C2= =A0

http://tools.ietf.org/html/draft-= dalela-orchestration-00

=C2=A0

The above draft describes the problems S= OP is aimed to address. This is the =E2=80=9Crequirements=E2=80=9D draft.

=C2=A0

The other drafts are:

=C2=A0<= u>

http://tools.ietf.org/html/draft-dalela-sop-arch= itecture-00 - describes the use-cases and network deployments with the = protocol

http://tools.ietf.org/html/draft-dalela-sop-00 - describes the prot= ocol=E2=80=99s messages

http://tools.ietf.org/html/draft-dalela-sdf-00 - describes service = naming, workflow construction, etc.

http://tools.ietf.org/html/draft-dalela-sop-flows-00 - desc= ribes some message flows

=C2=A0

Thanks, Ashish

<= p class=3D"MsoNormal"> =C2=A0

=C2=A0

From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]
Sent: Thursday, February 16, 2012 7:59 PM
To: Monique Morr= ow (mmorrow)
Cc: Ping Pan; robert@raszuk.net; sdnp; sop@ietf.org
Subject: Re: [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orch= estration and Desciption for Cloud Services

<= /div>

=C2=A0

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Can you please explain what t= he purpose of SOP is and what its goals are?

People on this list have been also asking how it differs fro= m SDN(p), so it

might be helpful to include that as well.= 8)

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 --Tom

=C2=A0

=C2=A0

= =C2=A0

On Feb 16, 2012, a= t 9:09 AM, Monique Morrow wrote:

=C2=A0

Guys

Please join the SOP mailer


List address: sop@ietf.org
= Archive: http://www.ietf.org/mail-archive/we= b/sop/
To subscribe: https://www.ietf.org/ma= ilman/listinfo/sop


TIA

Monique


On 2/14/12 10:45 PM, "Ping Pan"= <ping@pingpan.org= > wrote:

Where does OpenStack Quantum fit?

OpenStack Quantum is = to have agents in controllers and networking devices for the purpose of bet= ter transport. This is well within the goal of SDN.

Ping

On Tue, Feb 14, 2012 at 1:37 PM, Robert Raszuk <robert@raszuk.net> w= rote:


Actually I think those are quite separate problem spaces.<= br>
SOP aim to address the requirement of cloud to cloud communication (= hybrid or multi-domain). The way I think about this is how to standardize a= nd synchronize OpenStack to OpenStack instrumentation signaling. The next s= tep would be to actually also provide cloud to cloud communication layer. S= imple example: How to launch N VMs in various data centers to be part of co= mmon resources for customer X.

On the contrary SDNx seems to me of totally different caliber. One way = to look at this is what and how we could use APIs exposed by existing netwo= rk control planes to define and accomplish new network services. I quite do= not see current network element control planes nor their APIs as much rele= vant to cloud services.

My own personal view ;)

Regards,
R.


=

I'd like to get some clarification (from anyone who might know or have an opinion) on how this would interact with/be distinct from any
of= the SDNP (or whatever name we decide upon) proposed work. Is this
dupli= cation/people striking out on their own from the nascent SDNP
effort, a = companion effort that became clear as we have begun
segmenting the problem space, or something else entirely? Since this
is = the first I've heard of the list, I'm thinking it's a separate<= br>effort, but I figured I would raise the topic for discussion.

Thanks,

Wes George

-----Original Message----- From: ietf-announce-= bounces@ietf.org
[mailto:ietf-announce-bounces@ietf.org <mailto:ietf-announ= ce-bounces@ietf.org> ] On Behalf Of IETF
Secretariat Sent: Tuesday, February 14, 2012 2:25 PM To: IETF
Announceme= nt list Cc: sop@ietf.org<= /a>; Monique Morrow Subject: New
Non-WG Mailing List: sop -- Service Orc= hestration and Desciption for
Cloud Services



A new IETF non-working group email list has b= een created.

List address: sop@ietf.org Archive:
http://www.ietf.org/mail-archive/web/sop= / <http://www.ietf.org/mail-archive/web/sop/> =C2=A0To subscribe= :
htt= ps://www.ietf.org/mailman/listinfo/sop <https://www.ietf.org/mailman/li= stinfo/sop>

Purpose: Cloud services need to interoperate across cloud providers,service vendors and private/public domains. To enable this
interoperabi= lity, there is need for a standard wire-format for
exchanging service in= formation. This mailing lists is for discussing
protocols, data formats and server descriptions formats that allow
cloud= services to be discovered and used across private and public
domains. U= sing these, it would be possible to interoperate diverse
APIs and cloud = services across service providers, service vendors and
service users.

For additional information, please contact the list a= dministrators.
_______________________________________________ IETF-Anno= unce mailing
list IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce <= https://www.ietf.org/mailman/listinfo/ietf-announce>

This E-mail and any of its attachments may contain Time Warner Cableproprietary information, which is privileged, confidential, or
subject = to copyright belonging to Time Warner Cable. This E-mail is
intended sol= ely for the use of the individual or entity to which it
is addressed. If you are not the intended recipient of this E-mail,
you = are hereby notified that any dissemination, distribution,
copying, or ac= tion taken in relation to the contents of and
attachments to this E-mail= is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify
the s= ender immediately and permanently delete the original and any
copy of th= is E-mail and any printout.
____________________________________________= ___ SDNP mailing list
SDNP@lucidvision.= com http://lucidvision.com/mailman/listinfo/sdnp <http://lucidvi= sion.com/mailman/listinfo/sdnp>


___________________________________= ____________
SDNP mailing list
SDNP@lucidvision.com
= http://lucidvision.com/mailman/listinfo/sdnp <http://lucidvision.com= /mailman/listinfo/sdnp>

=C2=A0

_= ______________________________________________
SDNP mailing list
SDNP@lucidvision.com
http://lucidvision.com/mailman/listinfo/sdn= p

______________________________________________= _
SDNP mailing list
SDNP@lucidvision.com
http://lucidvision.com/mailman/listinf= o/sdnp

=C2=A0


_________= ______________________________________
sop mailing list
sop@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sop

=C2=A0

=

--00235429cfac95b22004b916cf4a-- From ping@pingpan.org Thu Feb 16 07:58:34 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD66321F8778 for ; Thu, 16 Feb 2012 07:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 ixzkxs986JNr for ; Thu, 16 Feb 2012 07:58:29 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with SMTP id BBE8921F8808 for ; Thu, 16 Feb 2012 07:58:18 -0800 (PST) Received: from mail-gx0-f179.google.com ([209.85.161.179]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTz0nmmgYPyc62u5r8IGc3OLyTWvEAwyC@postini.com; Thu, 16 Feb 2012 07:58:18 PST Received: by ggnq4 with SMTP id q4so1765401ggn.24 for ; Thu, 16 Feb 2012 07:58:17 -0800 (PST) Received: by 10.229.105.141 with SMTP id t13mr2047387qco.108.1329407897567; Thu, 16 Feb 2012 07:58:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.80.200 with HTTP; Thu, 16 Feb 2012 07:57:37 -0800 (PST) In-Reply-To: References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> From: Ping Pan Date: Thu, 16 Feb 2012 07:57:37 -0800 Message-ID: To: Michael Hammer Content-Type: multipart/alternative; boundary=00235429cfac7f030004b916e58e X-Gm-Message-State: ALoCoQks3yoBFVlXUgvDEDayAQURrT/ITnL5dZVu9cQDcrRMAV2MdBw1XEyr1NZWmNys97H6MB0y Cc: Thomas Nadeau , robert@raszuk.net, sdnp , "Monique Morrow \(mmorrow\)" , sop@ietf.org, "Ashish Dalela \(adalela\)" Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 15:58:34 -0000 --00235429cfac7f030004b916e58e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael, I would ask the question somewhat differently: what can we do to enable more new services and applications to make the best use of the network resources? ;-) We are at the very early stage of cloud networking. We should not limit ourselves on what we may accomplish with DC's. There is no hurry to jump onto the solution, while the problem space itself is becoming more interesting and lucrative at a stunning speed. ;-) Make sense? Regards, Ping On Thu, Feb 16, 2012 at 7:39 AM, Michael Hammer wrote: > All, > > The question I would ask is how many Cloud services do we think there wil= l > be long run. > Then ask, how many times the same methods/commands will need to be > re-invented: Create, Update, Delete? > > Also, ask yourself, if you have to do multiple of those cloud services in > synchronized fashion, would a tool designed for just one of those answer > the mail? > Can we abstract out the common elements and cover and integrate component > parts? > > Cloud seems to be in the state the telephone company found itself 100 > years ago. Everything works fine so long as you do it Edison's way, or > Tesla's or whomever. We had to go through a monopoly state before figuri= ng > out how to standardize. Looking to skip the monopoly phase this time > around. > > Mike > > > On Thu, Feb 16, 2012 at 10:23 AM, Ping Pan wrote: > >> Yeah, I have read all the drafts during the DC BoF discussion. In >> general, this makes sense... >> >> My thinking is that we may not want to standardize the interior DC >> management, as each vendor has own solution. But at the same time, we ne= ed >> to enable applications and services to ride on top of DC resources. In >> other words, SDN is in the position to enable Virtual DC's, and create t= he >> interface to communicate with networking resources at abstraction level. >> SDN should not be viewed as the NMS for DC's. >> >> There are a lot of work to be done here, and many parts are moving. Let'= s >> work together. >> >> Ping >> >> >> On Thu, Feb 16, 2012 at 7:02 AM, Ashish Dalela (adalela) < >> adalela@cisco.com> wrote: >> >>> ** ** >>> >>> SOP has the following main goals =E2=80=93 **** >>> >>> ** ** >>> >>> **1. **Fix interoperability issues with cloud services today. Main >>> examples are inter-cloud, hybrid-cloud, and multi-vendor cloud. All clo= ud >>> services are being enabled through proprietary APIs today, which don=E2= =80=99t >>> interoperate. To interoperate across vendors, providers and customers, = we >>> need an open standard. Ability to go across administrative domains is a >>> basic requirement.**** >>> >>> ** ** >>> >>> **2. **A clear separation between service-independent and >>> service-dependent pieces in cloud services. SOP is about >>> service-independent pieces. Using SOP, a variety of services could be >>> accessed or advertized. Separation between service-independent and >>> service-dependent pieces makes the scheme extensible to any type of ser= vice >>> =E2=80=93 current or future.**** >>> >>> ** ** >>> >>> **3. **Create a common scheme for service orchestration that can be >>> used across compute, network, storage, security, applications, etc. A >>> common set of constructs that can be applied to any service type whethe= r it >>> is infrastructure or application.**** >>> >>> ** ** >>> >>> http://tools.ietf.org/html/draft-dalela-orchestration-00**** >>> >>> ** ** >>> >>> The above draft describes the problems SOP is aimed to address. This is >>> the =E2=80=9Crequirements=E2=80=9D draft.**** >>> >>> ** ** >>> >>> The other drafts are:**** >>> >>> ** ** >>> >>> http://tools.ietf.org/html/draft-dalela-sop-architecture-00 - describes >>> the use-cases and network deployments with the protocol**** >>> >>> http://tools.ietf.org/html/draft-dalela-sop-00 - describes the >>> protocol=E2=80=99s messages **** >>> >>> http://tools.ietf.org/html/draft-dalela-sdf-00 - describes service >>> naming, workflow construction, etc.**** >>> >>> http://tools.ietf.org/html/draft-dalela-sop-flows-00 - describes some >>> message flows**** >>> >>> ** ** >>> >>> Thanks, Ashish**** >>> >>> ** ** >>> >>> ** ** >>> >>> *From:* Thomas Nadeau [mailto:tnadeau@lucidvision.com] >>> *Sent:* Thursday, February 16, 2012 7:59 PM >>> *To:* Monique Morrow (mmorrow) >>> *Cc:* Ping Pan; robert@raszuk.net; sdnp; sop@ietf.org >>> *Subject:* Re: [Sdnp] FW: New Non-WG Mailing List: sop -- Service >>> Orchestration and Desciption for Cloud Services**** >>> >>> ** ** >>> >>> ** ** >>> >>> Can you please explain what the purpose of SOP is and what >>> its goals are?**** >>> >>> People on this list have been also asking how it differs from SDN(p), s= o >>> it**** >>> >>> might be helpful to include that as well. 8)**** >>> >>> **** >>> >>> --Tom**** >>> >>> ** ** >>> >>> ** ** >>> >>> ** ** >>> >>> On Feb 16, 2012, at 9:09 AM, Monique Morrow wrote:**** >>> >>> >>> >>> **** >>> >>> Guys >>> >>> Please join the SOP mailer >>> >>> >>> List address: *sop@ietf.org >>> *Archive: *http://www.ietf.org/mail-archive/web/sop/ >>> *To subscribe: *https://www.ietf.org/mailman/listinfo/sop >>> * >>> >>> TIA >>> >>> Monique >>> >>> >>> On 2/14/12 10:45 PM, "Ping Pan" wrote: >>> >>> >>> **** >>> >>> Where does OpenStack Quantum fit? >>> >>> OpenStack Quantum is to have agents in controllers and networking >>> devices for the purpose of better transport. This is well within the go= al >>> of SDN. >>> >>> Ping >>> >>> On Tue, Feb 14, 2012 at 1:37 PM, Robert Raszuk >>> wrote: >>> >>> **** >>> >>> >>> Actually I think those are quite separate problem spaces. >>> >>> SOP aim to address the requirement of cloud to cloud communication >>> (hybrid or multi-domain). The way I think about this is how to standard= ize >>> and synchronize OpenStack to OpenStack instrumentation signaling. The n= ext >>> step would be to actually also provide cloud to cloud communication lay= er. >>> Simple example: How to launch N VMs in various data centers to be part = of >>> common resources for customer X. >>> >>> On the contrary SDNx seems to me of totally different caliber. One way >>> to look at this is what and how we could use APIs exposed by existing >>> network control planes to define and accomplish new network services. I >>> quite do not see current network element control planes nor their APIs = as >>> much relevant to cloud services. >>> >>> My own personal view ;) >>> >>> Regards, >>> R. >>> >>> >>> >>> **** >>> >>> I'd like to get some clarification (from anyone who might know or >>> have an opinion) on how this would interact with/be distinct from any >>> of the SDNP (or whatever name we decide upon) proposed work. Is this >>> duplication/people striking out on their own from the nascent SDNP >>> effort, a companion effort that became clear as we have begun >>> segmenting the problem space, or something else entirely? Since this >>> is the first I've heard of the list, I'm thinking it's a separate >>> effort, but I figured I would raise the topic for discussion. >>> >>> Thanks, >>> >>> Wes George >>> >>> -----Original Message----- From: ietf-announce-bounces@ietf.org >>> [mailto:ietf-announce-bounces@ietf.org = < >>> mailto:ietf-announce-bounces@ietf.org > >>> ] On Behalf Of IETF >>> Secretariat Sent: Tuesday, February 14, 2012 2:25 PM To: IETF >>> Announcement list Cc: sop@ietf.org; Monique Morrow Subject: New >>> Non-WG Mailing List: sop -- Service Orchestration and Desciption for >>> Cloud Services >>> >>> >>> >>> A new IETF non-working group email list has been created. >>> >>> List address: sop@ietf.org Archive: >>> http://www.ietf.org/mail-archive/web/sop/ < >>> http://www.ietf.org/mail-archive/web/sop/> To subscribe: >>> https://www.ietf.org/mailman/listinfo/sop < >>> https://www.ietf.org/mailman/listinfo/sop> >>> >>> Purpose: Cloud services need to interoperate across cloud providers, >>> service vendors and private/public domains. To enable this >>> interoperability, there is need for a standard wire-format for >>> exchanging service information. This mailing lists is for discussing >>> protocols, data formats and server descriptions formats that allow >>> cloud services to be discovered and used across private and public >>> domains. Using these, it would be possible to interoperate diverse >>> APIs and cloud services across service providers, service vendors and >>> service users. >>> >>> For additional information, please contact the list administrators. >>> _______________________________________________ IETF-Announce mailing >>> list IETF-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-announce < >>> https://www.ietf.org/mailman/listinfo/ietf-announce> >>> >>> This E-mail and any of its attachments may contain Time Warner Cable >>> proprietary information, which is privileged, confidential, or >>> subject to copyright belonging to Time Warner Cable. This E-mail is >>> intended solely for the use of the individual or entity to which it >>> is addressed. If you are not the intended recipient of this E-mail, >>> you are hereby notified that any dissemination, distribution, >>> copying, or action taken in relation to the contents of and >>> attachments to this E-mail is strictly prohibited and may be >>> unlawful. If you have received this E-mail in error, please notify >>> the sender immediately and permanently delete the original and any >>> copy of this E-mail and any printout. >>> _______________________________________________ SDNP mailing list >>> SDNP@lucidvision.com http://lucidvision.com/mailman/listinfo/sdnp < >>> http://lucidvision.com/mailman/listinfo/sdnp> >>> >>> **** >>> >>> >>> _______________________________________________ >>> SDNP mailing list >>> SDNP@lucidvision.com >>> http://lucidvision.com/mailman/listinfo/sdnp < >>> http://lucidvision.com/mailman/listinfo/sdnp> **** >>> >>> ** ** >>> ------------------------------ >>> >>> _______________________________________________ >>> SDNP mailing list >>> SDNP@lucidvision.com >>> http://lucidvision.com/mailman/listinfo/sdnp**** >>> >>> _______________________________________________ >>> SDNP mailing list >>> SDNP@lucidvision.com >>> http://lucidvision.com/mailman/listinfo/sdnp**** >>> >>> ** ** >>> >>> _______________________________________________ >>> sop mailing list >>> sop@ietf.org >>> https://www.ietf.org/mailman/listinfo/sop >>> >>> >> >> _______________________________________________ >> sop mailing list >> sop@ietf.org >> https://www.ietf.org/mailman/listinfo/sop >> >> > --00235429cfac7f030004b916e58e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael,

I would ask the question somewhat differently: = what can we do to enable more new services and applications to make the bes= t use of the network resources? ;-)

We are at the = very early stage of cloud networking. We should not limit ourselves on what= we may accomplish with DC's. There is no hurry to jump onto the soluti= on, while the problem space itself is becoming more interesting and lucrati= ve at a stunning speed. ;-)=C2=A0

Make sense?

Regards,

Ping

On Thu, Feb 16, 2012= at 7:39 AM, Michael Hammer <mphmmr@gmail.com> wrote:
All,

The question I would= ask is how many Cloud services do we think there will be long run.
Then ask, how many times the same methods/commands will need to be re-inven= ted: =C2=A0Create, Update, Delete?

Also, ask yourself, if you have to do multiple of those= cloud services in synchronized fashion, would a tool designed for just one= of those answer the mail?
Can we abstract out the common element= s and cover and integrate component parts?

Cloud seems to be in the state the telephone company fo= und itself 100 years ago. =C2=A0Everything works fine so long as you do it = Edison's way, or Tesla's or whomever. =C2=A0We had to go through a = monopoly state before figuring out how to standardize. =C2=A0Looking to ski= p the monopoly phase this time around.

Mike
=

On Thu, Feb 16, 2012 at 10:23 AM, Ping P= an <ping@pingpan.org> wrote:
Yeah, I have read all the drafts during the DC BoF discussion. In general, = this makes sense...

My thinking is that we may not want = to standardize the interior DC management, as each vendor has own solution.= =C2=A0But at the same time, we need to enable applications and services to = ride on top of DC resources. In other words, SDN is in the position to enab= le Virtual=C2=A0DC's, and create the interface to communicate with netw= orking resources at=C2=A0abstraction=C2=A0level. SDN should not be viewed a= s the NMS for DC's.

There are a lot of work to be done here, and many parts= are moving. Let's work together.

Ping


On Thu, Feb 16, 2012 at 7:02 = AM, Ashish Dalela (adalela) <adalela@cisco.com> wrote:

= =C2=A0

SOP has the following main goals =E2=80=93

=C2=A0

1.=C2=A0 Fix interoperability issues = with cloud services today. Main examples are inter-cloud, hybrid-cloud, and= multi-vendor cloud. All cloud services are being enabled through proprieta= ry APIs today, which don=E2=80=99t interoperate. To interoperate across ven= dors, providers and customers, we need an open standard. Ability to go acro= ss administrative domains is a basic requirement.

=C2=A0

2.= =C2=A0 A clear separation between service-independent = and service-dependent pieces in cloud services. SOP is about service-indepe= ndent pieces. Using SOP, a variety of services could be accessed or adverti= zed. Separation between service-independent and service-dependent pieces ma= kes the scheme extensible to any type of service =E2=80=93 current or futur= e.

=C2=A0

3.= =C2=A0 Create a common scheme for service orchestratio= n that can be used across compute, network, storage, security, applications= , etc. A common set of constructs that can be applied to any service type w= hether it is infrastructure or application.

<= /u>=C2=A0

http://tools.ietf.org/html/draft-d= alela-orchestration-00

=C2=A0

The above draft describes the problems S= OP is aimed to address. This is the =E2=80=9Crequirements=E2=80=9D draft.

=C2=A0

The other drafts are:

=C2=A0<= /span>

http://tools.ietf.org/html/draft-dalela-sop-arch= itecture-00 - describes the use-cases and network deployments with the = protocol

http://tools.ietf.org/html/draft-dalela-sop-00 - describes the prot= ocol=E2=80=99s messages

http://tools.ietf.org/html/draft-dalela-sdf-00 - describes service = naming, workflow construction, etc.

http://tools.ietf.org/html/draft-dalela-sop-flows-00 - desc= ribes some message flows

=C2=A0

Thanks, Ashish

<= p class=3D"MsoNormal"> =C2=A0

=C2=A0

From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]
Sent: Thursday, February 16, 2012 7:59 PM
To: Monique Morr= ow (mmorrow)
Cc: Ping Pan; robert@raszuk.net; sdnp; sop@ietf.org
Subject: Re: [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orch= estration and Desciption for Cloud Services

<= /div>

=C2=A0

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <= /span>Can you please explain what the purpose of SOP is and what its goals = are?

People on this list have = been also asking how it differs from SDN(p), so it

might be helpful to include that as well.= 8)

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --Tom

=C2=A0

=C2=A0

= =C2=A0

On Feb 16, 2012, a= t 9:09 AM, Monique Morrow wrote:



Guys

Please join the SOP mailer


List address: sop@ietf.org
<= /u>Archive: http://www.ietf.org/mail-archive/web= /sop/
To subscribe: https://www.ietf.org/ma= ilman/listinfo/sop


TIA

Monique


On 2/14/12 10:45 PM, "Ping Pan"= <ping@pingpan.org> wrote:


Where does OpenStack Quantum fit?

OpenStack Quantum is to have agents in controllers and networking devic= es for the purpose of better transport. This is well within the goal of SDN= .

Ping

On Tue, Feb 14, 2012 at 1:37 PM, Robert Raszuk <= robert@raszuk.net> wrote:


Actual= ly I think those are quite separate problem spaces.

SOP aim to addre= ss the requirement of cloud to cloud communication (hybrid or multi-domain)= . The way I think about this is how to standardize and synchronize OpenStac= k to OpenStack instrumentation signaling. The next step would be to actuall= y also provide cloud to cloud communication layer. Simple example: How to l= aunch N VMs in various data centers to be part of common resources for cust= omer X.

On the contrary SDNx seems to me of totally different caliber. One way = to look at this is what and how we could use APIs exposed by existing netwo= rk control planes to define and accomplish new network services. I quite do= not see current network element control planes nor their APIs as much rele= vant to cloud services.

My own personal view ;)

Regards,
R.



=

I'd like to get some clarification (from anyone who might know o= r
have an opinion) on how this would interact with/be distinct from any
of= the SDNP (or whatever name we decide upon) proposed work. Is this
dupli= cation/people striking out on their own from the nascent SDNP
effort, a = companion effort that became clear as we have begun
segmenting the problem space, or something else entirely? Since this
is = the first I've heard of the list, I'm thinking it's a separate<= br>effort, but I figured I would raise the topic for discussion.

Thanks,

Wes George

-----Original Message----- From: ietf-a= nnounce-bounces@ietf.org
[mailto:ietf-announce-bounces@ietf.org <mailto:iet= f-announce-bounces@ietf.org> ] On Behalf Of IETF
Secretariat Sent: Tuesday, February 14, 2012 2:25 PM To: IETF
Announceme= nt list Cc: sop@ietf.org; Monique Morrow Subject: New
Non-WG Mail= ing List: sop -- Service Orchestration and Desciption for
Cloud Services=



A new IETF non-working group email list has been created.
List address: sop@ietf.org Archive:
http://www.ietf.org/mail-archi= ve/web/sop/ <http://www.ietf.org/mail-archive/web/sop/> =C2=A0To= subscribe:
htt= ps://www.ietf.org/mailman/listinfo/sop <https://www.ietf.org/mailman/li= stinfo/sop>

Purpose: Cloud services need to interoperate across cloud providers,service vendors and private/public domains. To enable this
interoperabi= lity, there is need for a standard wire-format for
exchanging service in= formation. This mailing lists is for discussing
protocols, data formats and server descriptions formats that allow
cloud= services to be discovered and used across private and public
domains. U= sing these, it would be possible to interoperate diverse
APIs and cloud = services across service providers, service vendors and
service users.

For additional information, please contact the list a= dministrators.
_______________________________________________ IETF-Anno= unce mailing
list IETF-Announce@ietf.org
https://www.ie= tf.org/mailman/listinfo/ietf-announce <https://www.ietf.org/m= ailman/listinfo/ietf-announce>

This E-mail and any of its attachments may contain Time Warner Cableproprietary information, which is privileged, confidential, or
subject = to copyright belonging to Time Warner Cable. This E-mail is
intended sol= ely for the use of the individual or entity to which it
is addressed. If you are not the intended recipient of this E-mail,
you = are hereby notified that any dissemination, distribution,
copying, or ac= tion taken in relation to the contents of and
attachments to this E-mail= is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify
the s= ender immediately and permanently delete the original and any
copy of th= is E-mail and any printout.
____________________________________________= ___ SDNP mailing list
SDNP@lucidvision.com http://lucidvision.com/mailman/listinfo/sdnp <http://lucidvision.com/mailman/listinfo/sdnp>


______= _________________________________________
SDNP mailing list
SDNP@l= ucidvision.com
= http://lucidvision.com/mailman/listinfo/sdnp <http://lucidvision.com= /mailman/listinfo/sdnp>

= =C2=A0

_= ______________________________________________
SDNP mailing list
SDNP@lucidvision.com
http://lucidvision.com/= mailman/listinfo/sdnp

_______________________________________________
SDNP mailing list
SDNP@lucidvision.com=
http://lucidvision.com/mailman/listinfo/sdnp

=C2=A0


______________________________________________= _
sop mailing list
sop@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sop



_______________________________________________
sop mailing list
sop@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sop



--00235429cfac7f030004b916e58e-- From adalela@cisco.com Thu Feb 16 08:09:57 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C4921F883C for ; Thu, 16 Feb 2012 08:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.71 X-Spam-Level: X-Spam-Status: No, score=-6.71 tagged_above=-999 required=5 tests=[AWL=3.888, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 qeVQbHxpD7CR for ; Thu, 16 Feb 2012 08:09:52 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAC421F883D for ; Thu, 16 Feb 2012 08:09:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=54270; q=dns/txt; s=iport; t=1329408588; x=1330618188; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=dIdQTvZe5+ZWpF2djDe3RXX1dNi+zpgvwWzUnQDiqvY=; b=XrHHE17IfpiKkq34qf5r6IFpdsuu5pDZvz/QySlKwrwFTnWohFCbe/hu vVQN8e9LOKAZHPNmDtjljofNsiDfrfuGbeMNiib0bVQ9rIa3DB5y4voAc cXm5s2icEoXFH593v17tMJ6vOr3FVPBGD19lcLnyUgLFsvpcuLfth7VCW c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgFABwpPU9Io8UY/2dsb2JhbABEgk2CRJp4iBMBh1eBdoFyAQEBBAEBAQ8BCQcKAz4EBwwEAgEGAhEBAwEBCwIEEAECBAECAgIBASUfAwUBCAEBBAsICAESB4dmmjABjGWRaYtkAQcBAQMBAgIDBwkICAICMYNbJAEJBhECAwIEAQIEAwQFAgUDA4IUM2MEiEyfWw X-IronPort-AV: E=Sophos;i="4.73,430,1325462400"; d="scan'208,217";a="5722656" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 16 Feb 2012 16:09:46 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1GG9kmL028681; Thu, 16 Feb 2012 16:09:46 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Feb 2012 21:39:46 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCECC5.666D81B5" Date: Thu, 16 Feb 2012 21:39:45 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C5103001EA3@XMB-BGL-416.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services Thread-Index: AczswwEuprH3a78jStiTjnCrOXJLXgAAagNA References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C5103001E8E@XMB-BGL-416.cisco.com> From: "Ashish Dalela (adalela)" To: "Ping Pan" X-OriginalArrivalTime: 16 Feb 2012 16:09:46.0224 (UTC) FILETIME=[66AD2F00:01CCECC5] Cc: sop@ietf.org Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 16:09:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCECC5.666D81B5 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IA0KDQpQaW5nLA0KDQogDQoNClRoaXMgaXNu4oCZdCBqdXN0IGFib3V0IHRoZSBuZXR3b3JrIHJl c291cmNlcyBhbmQgU09QIGlzbuKAmXQgb25seSBhYm91dCBwcm92aXNpb25pbmcgbmV0d29yayBy ZXNvdXJjZXMuIFRoZSBwcm90b2NvbCBkZWZpbml0aW9uIGlzIGdlbmVyYWxpemVkIHRvIHN1cHBv cnQgYW55IGtpbmQgb2Ygc2VydmljZSDigJMgbmV0d29yayBpbmNsdWRlZC4NCg0KIA0KDQpUbyB5 b3VyIHBvaW50IGFib3V0IGNoYW5naW5nIHJvdXRlcyDigJMgSSBhZ3JlZSB0byB0aGF0IGNvbXBs ZXRlbHkuIFRoZSBnb2FsIGlzbuKAmXQgdG8gcmVwbGFjZSByb3V0aW5nIHByb3RvY29scyEgU09Q IHdpbGwgdXNlIG5ldHdvcmsgcm91dGVzLiBBcyB5b3Ugc2F5LCBpdCBjYW4gYmUgdXNlZCB0byBw cm92aXNpb24g4oCccG9saWNpZXPigJ0uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQpUaGFu a3MsIEFzaGlzaA0KDQogDQoNCkZyb206IFBpbmcgUGFuIFttYWlsdG86cGluZ0BwaW5ncGFuLm9y Z10gDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTYsIDIwMTIgOToyMSBQTQ0KVG86IEFzaGlz aCBEYWxlbGEgKGFkYWxlbGEpDQpDYzogVGhvbWFzIE5hZGVhdTsgTW9uaXF1ZSBNb3Jyb3cgKG1t b3Jyb3cpOyBzZG5wOyBzb3BAaWV0Zi5vcmc7IHJvYmVydEByYXN6dWsubmV0DQpTdWJqZWN0OiBS ZTogW3NvcF0gW1NkbnBdIEZXOiBOZXcgTm9uLVdHIE1haWxpbmcgTGlzdDogc29wIC0tIFNlcnZp Y2UgT3JjaGVzdHJhdGlvbiBhbmQgRGVzY2lwdGlvbiBmb3IgQ2xvdWQgU2VydmljZXMNCg0KIA0K DQpUaGVyZSBhcmUgdGFsa3Mgb24gbW9yZSBjb250cm9sIGZyb20gYXBwbGljYXRpb25zIHRvIHRo ZSBuZXR3b3Jrcy4NCg0KIA0KDQpJTUhPLCB0aGlzIGlzIG1vcmUgb2YgYSBtaXN1bmRlcnN0YW5k aW5nIHRoYW4gYW55dGhpbmcgZWxzZS4gDQoNCiANCg0KRmlyc3QsIG1hbnkgREMgb3BlcmF0b3Jz IGhhdmUgbGVhc2VkIHRoZSBjaXJjdWl0cyBvciBidWlsdCB0aGUgbmV0d29yay4gVGhleSBoYXZl IGV2ZXJ5IHJpZ2h0IHRvIGRlY2lkZSB0aGUgcG9saWN5IGF0IGVkZ2UgYW5kIGFnZ3JlZ2F0ZSB0 cmFmZmljIG9udG8gdGhlIG5ldHdvcmsgdGhleSBsZWFzZSBvciBvd24uIFNlY29uZCwgSSB0aGlu ayB0aGF0IHRoZSBzZXJ2aWNlIHByb3ZpZGVycyB3b3VsZCBoYXZlIG5vIHByb2JsZW0gdG8gZXhw ZWRpdGUgdGhlIEJXIHByb3Zpc2lvbmluZyBwcm9jZXNzIHdoZW4gYSBjdXN0b21lciBpcyBhc2tp bmcgZm9yIG1vcmUsIGJ1dCBubyBzZXJ2aWNlIHByb3ZpZGVyIHRvIG15IGJlc3Qga25vd2xlZGdl IHdvdWxkIGFsbG93IHRoZSBjdXN0b21lcnMgdG8gYWx0ZXIgdGhlIHJvdXRlcyBpbnNpZGUgdGhl aXIgbmV0d29ya3MuDQoNCiANCg0KU28gZGVlcC1jb250cm9sIHRvIG1lIG1lYW5zIGEgY2xlYW5l ciwgc2ltcGxlciBhbmQgZmFzdGVyIHdheSB0byBwcm92aXNpb25pbmcgbmV0d29yayByZXNvdXJj ZXMgdGhyb3VnaCBhIGNvbnNpc3RlbnQgaW50ZXJmYWNlLg0KDQogDQoNClBpbmcNCg0KIA0KDQpP biBUaHUsIEZlYiAxNiwgMjAxMiBhdCA3OjM4IEFNLCBBc2hpc2ggRGFsZWxhIChhZGFsZWxhKSA8 YWRhbGVsYUBjaXNjby5jb20+IHdyb3RlOg0KDQogDQoNCldlbGwsIHllcywgb25lIG9mIHRoZSB1 c2UtY2FzZSBpcyB0byBzb2x2ZSBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlcyBiZXR3ZWVuIGFuZCBh Y3Jvc3MgY2xvdWRzLg0KDQogDQoNCkkgYWxzbyBoYXZlIGhlYXJkIGZyb20gZm9sa3MgdGhlIG5l ZWQgZm9yIOKAnGRlZXAgY29udHJvbOKAnSBpbiB3aGljaCBhIGN1c3RvbWVyIG91dHNpZGUgdGhl IGNsb3VkIHdhbnRzIHRvIHR3ZWFrIG9yIGNvbnRyb2wgdGhlIGluZnJhc3RydWN0dXJlIG9yIGFw cGxpY2F0aW9uIGF0IGEgbG93IGdyYW51bGFyaXR5LiBJIHRoaW5rIHRoYXQgd291bGQgYmUgaGFy ZCwgYWx0aG91Z2ggbm90IGltcG9zc2libGUsIGlmIHRoZSBtZWNoYW5pc21zIG91dHNpZGUgYW5k IGluc2lkZSB3ZXJlIGRpZmZlcmVudCDigJMgYXMgeW91IHdpbGwgaGF2ZSB0byBjcmVhdGUgbWFw cGluZ3MuDQoNCiANCg0KVGhhdCBpcyBhIHRvcGljIHF1aXRlIG9wZW4gZm9yIGRpc2N1c3Npb24u DQoNCiANCg0KVGhhbmtzLCBBc2hpc2gNCg0KIA0KDQogDQoNCkZyb206IFBpbmcgUGFuIFttYWls dG86cGluZ0BwaW5ncGFuLm9yZ10gDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTYsIDIwMTIg ODo1NCBQTQ0KVG86IEFzaGlzaCBEYWxlbGEgKGFkYWxlbGEpDQpDYzogVGhvbWFzIE5hZGVhdTsg TW9uaXF1ZSBNb3Jyb3cgKG1tb3Jyb3cpOyBzZG5wOyBzb3BAaWV0Zi5vcmc7IHJvYmVydEByYXN6 dWsubmV0DQpTdWJqZWN0OiBSZTogW3NvcF0gW1NkbnBdIEZXOiBOZXcgTm9uLVdHIE1haWxpbmcg TGlzdDogc29wIC0tIFNlcnZpY2UgT3JjaGVzdHJhdGlvbiBhbmQgRGVzY2lwdGlvbiBmb3IgQ2xv dWQgU2VydmljZXMNCg0KIA0KDQpZZWFoLCBJIGhhdmUgcmVhZCBhbGwgdGhlIGRyYWZ0cyBkdXJp bmcgdGhlIERDIEJvRiBkaXNjdXNzaW9uLiBJbiBnZW5lcmFsLCB0aGlzIG1ha2VzIHNlbnNlLi4u DQoNCiANCg0KTXkgdGhpbmtpbmcgaXMgdGhhdCB3ZSBtYXkgbm90IHdhbnQgdG8gc3RhbmRhcmRp emUgdGhlIGludGVyaW9yIERDIG1hbmFnZW1lbnQsIGFzIGVhY2ggdmVuZG9yIGhhcyBvd24gc29s dXRpb24uIEJ1dCBhdCB0aGUgc2FtZSB0aW1lLCB3ZSBuZWVkIHRvIGVuYWJsZSBhcHBsaWNhdGlv bnMgYW5kIHNlcnZpY2VzIHRvIHJpZGUgb24gdG9wIG9mIERDIHJlc291cmNlcy4gSW4gb3RoZXIg d29yZHMsIFNETiBpcyBpbiB0aGUgcG9zaXRpb24gdG8gZW5hYmxlIFZpcnR1YWwgREMncywgYW5k IGNyZWF0ZSB0aGUgaW50ZXJmYWNlIHRvIGNvbW11bmljYXRlIHdpdGggbmV0d29ya2luZyByZXNv dXJjZXMgYXQgYWJzdHJhY3Rpb24gbGV2ZWwuIFNETiBzaG91bGQgbm90IGJlIHZpZXdlZCBhcyB0 aGUgTk1TIGZvciBEQydzLg0KDQogDQoNClRoZXJlIGFyZSBhIGxvdCBvZiB3b3JrIHRvIGJlIGRv bmUgaGVyZSwgYW5kIG1hbnkgcGFydHMgYXJlIG1vdmluZy4gTGV0J3Mgd29yayB0b2dldGhlci4N Cg0KIA0KDQpQaW5nDQoNCiANCg0KIA0KDQpPbiBUaHUsIEZlYiAxNiwgMjAxMiBhdCA3OjAyIEFN LCBBc2hpc2ggRGFsZWxhIChhZGFsZWxhKSA8YWRhbGVsYUBjaXNjby5jb20+IHdyb3RlOg0KDQog DQoNClNPUCBoYXMgdGhlIGZvbGxvd2luZyBtYWluIGdvYWxzIOKAkyANCg0KIA0KDQoxLiAgRml4 IGludGVyb3BlcmFiaWxpdHkgaXNzdWVzIHdpdGggY2xvdWQgc2VydmljZXMgdG9kYXkuIE1haW4g ZXhhbXBsZXMgYXJlIGludGVyLWNsb3VkLCBoeWJyaWQtY2xvdWQsIGFuZCBtdWx0aS12ZW5kb3Ig Y2xvdWQuIEFsbCBjbG91ZCBzZXJ2aWNlcyBhcmUgYmVpbmcgZW5hYmxlZCB0aHJvdWdoIHByb3By aWV0YXJ5IEFQSXMgdG9kYXksIHdoaWNoIGRvbuKAmXQgaW50ZXJvcGVyYXRlLiBUbyBpbnRlcm9w ZXJhdGUgYWNyb3NzIHZlbmRvcnMsIHByb3ZpZGVycyBhbmQgY3VzdG9tZXJzLCB3ZSBuZWVkIGFu IG9wZW4gc3RhbmRhcmQuIEFiaWxpdHkgdG8gZ28gYWNyb3NzIGFkbWluaXN0cmF0aXZlIGRvbWFp bnMgaXMgYSBiYXNpYyByZXF1aXJlbWVudC4NCg0KIA0KDQoyLiAgQSBjbGVhciBzZXBhcmF0aW9u IGJldHdlZW4gc2VydmljZS1pbmRlcGVuZGVudCBhbmQgc2VydmljZS1kZXBlbmRlbnQgcGllY2Vz IGluIGNsb3VkIHNlcnZpY2VzLiBTT1AgaXMgYWJvdXQgc2VydmljZS1pbmRlcGVuZGVudCBwaWVj ZXMuIFVzaW5nIFNPUCwgYSB2YXJpZXR5IG9mIHNlcnZpY2VzIGNvdWxkIGJlIGFjY2Vzc2VkIG9y IGFkdmVydGl6ZWQuIFNlcGFyYXRpb24gYmV0d2VlbiBzZXJ2aWNlLWluZGVwZW5kZW50IGFuZCBz ZXJ2aWNlLWRlcGVuZGVudCBwaWVjZXMgbWFrZXMgdGhlIHNjaGVtZSBleHRlbnNpYmxlIHRvIGFu eSB0eXBlIG9mIHNlcnZpY2Ug4oCTIGN1cnJlbnQgb3IgZnV0dXJlLg0KDQogDQoNCjMuICBDcmVh dGUgYSBjb21tb24gc2NoZW1lIGZvciBzZXJ2aWNlIG9yY2hlc3RyYXRpb24gdGhhdCBjYW4gYmUg dXNlZCBhY3Jvc3MgY29tcHV0ZSwgbmV0d29yaywgc3RvcmFnZSwgc2VjdXJpdHksIGFwcGxpY2F0 aW9ucywgZXRjLiBBIGNvbW1vbiBzZXQgb2YgY29uc3RydWN0cyB0aGF0IGNhbiBiZSBhcHBsaWVk IHRvIGFueSBzZXJ2aWNlIHR5cGUgd2hldGhlciBpdCBpcyBpbmZyYXN0cnVjdHVyZSBvciBhcHBs aWNhdGlvbi4NCg0KIA0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kYWxlbGEt b3JjaGVzdHJhdGlvbi0wMA0KDQogDQoNClRoZSBhYm92ZSBkcmFmdCBkZXNjcmliZXMgdGhlIHBy b2JsZW1zIFNPUCBpcyBhaW1lZCB0byBhZGRyZXNzLiBUaGlzIGlzIHRoZSDigJxyZXF1aXJlbWVu dHPigJ0gZHJhZnQuDQoNCiANCg0KVGhlIG90aGVyIGRyYWZ0cyBhcmU6DQoNCiANCg0KaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZGFsZWxhLXNvcC1hcmNoaXRlY3R1cmUtMDAgLSBk ZXNjcmliZXMgdGhlIHVzZS1jYXNlcyBhbmQgbmV0d29yayBkZXBsb3ltZW50cyB3aXRoIHRoZSBw cm90b2NvbA0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kYWxlbGEtc29wLTAw IC0gZGVzY3JpYmVzIHRoZSBwcm90b2NvbOKAmXMgbWVzc2FnZXMgDQoNCmh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWRhbGVsYS1zZGYtMDAgLSBkZXNjcmliZXMgc2VydmljZSBuYW1p bmcsIHdvcmtmbG93IGNvbnN0cnVjdGlvbiwgZXRjLg0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1kYWxlbGEtc29wLWZsb3dzLTAwIC0gZGVzY3JpYmVzIHNvbWUgbWVzc2FnZSBm bG93cw0KDQogDQoNClRoYW5rcywgQXNoaXNoDQoNCiANCg0KIA0KDQpGcm9tOiBUaG9tYXMgTmFk ZWF1IFttYWlsdG86dG5hZGVhdUBsdWNpZHZpc2lvbi5jb21dIA0KU2VudDogVGh1cnNkYXksIEZl YnJ1YXJ5IDE2LCAyMDEyIDc6NTkgUE0NClRvOiBNb25pcXVlIE1vcnJvdyAobW1vcnJvdykNCkNj OiBQaW5nIFBhbjsgcm9iZXJ0QHJhc3p1ay5uZXQ7IHNkbnA7IHNvcEBpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtTZG5wXSBGVzogTmV3IE5vbi1XRyBNYWlsaW5nIExpc3Q6IHNvcCAtLSBTZXJ2aWNl IE9yY2hlc3RyYXRpb24gYW5kIERlc2NpcHRpb24gZm9yIENsb3VkIFNlcnZpY2VzDQoNCiANCg0K IA0KDQogICAgICAgICAgICBDYW4geW91IHBsZWFzZSBleHBsYWluIHdoYXQgdGhlIHB1cnBvc2Ug b2YgU09QIGlzIGFuZCB3aGF0IGl0cyBnb2FscyBhcmU/DQoNClBlb3BsZSBvbiB0aGlzIGxpc3Qg aGF2ZSBiZWVuIGFsc28gYXNraW5nIGhvdyBpdCBkaWZmZXJzIGZyb20gU0ROKHApLCBzbyBpdA0K DQptaWdodCBiZSBoZWxwZnVsIHRvIGluY2x1ZGUgdGhhdCBhcyB3ZWxsLiA4KQ0KDQogICAgICAg ICAgICANCg0KICAgICAgICAgICAgLS1Ub20NCg0KIA0KDQogDQoNCiANCg0KT24gRmViIDE2LCAy MDEyLCBhdCA5OjA5IEFNLCBNb25pcXVlIE1vcnJvdyB3cm90ZToNCg0KIA0KDQpHdXlzIA0KDQpQ bGVhc2Ugam9pbiB0aGUgU09QIG1haWxlciANCg0KDQpMaXN0IGFkZHJlc3M6IHNvcEBpZXRmLm9y Zw0KQXJjaGl2ZTogaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NvcC8NClRv IHN1YnNjcmliZTogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb3ANCg0K DQpUSUENCg0KTW9uaXF1ZQ0KDQoNCk9uIDIvMTQvMTIgMTA6NDUgUE0sICJQaW5nIFBhbiIgPHBp bmdAcGluZ3Bhbi5vcmc+IHdyb3RlOg0KDQpXaGVyZSBkb2VzIE9wZW5TdGFjayBRdWFudHVtIGZp dD8NCg0KT3BlblN0YWNrIFF1YW50dW0gaXMgdG8gaGF2ZSBhZ2VudHMgaW4gY29udHJvbGxlcnMg YW5kIG5ldHdvcmtpbmcgZGV2aWNlcyBmb3IgdGhlIHB1cnBvc2Ugb2YgYmV0dGVyIHRyYW5zcG9y dC4gVGhpcyBpcyB3ZWxsIHdpdGhpbiB0aGUgZ29hbCBvZiBTRE4uDQoNClBpbmcNCg0KT24gVHVl LCBGZWIgMTQsIDIwMTIgYXQgMTozNyBQTSwgUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5u ZXQ+IHdyb3RlOg0KDQoNCkFjdHVhbGx5IEkgdGhpbmsgdGhvc2UgYXJlIHF1aXRlIHNlcGFyYXRl IHByb2JsZW0gc3BhY2VzLg0KDQpTT1AgYWltIHRvIGFkZHJlc3MgdGhlIHJlcXVpcmVtZW50IG9m IGNsb3VkIHRvIGNsb3VkIGNvbW11bmljYXRpb24gKGh5YnJpZCBvciBtdWx0aS1kb21haW4pLiBU aGUgd2F5IEkgdGhpbmsgYWJvdXQgdGhpcyBpcyBob3cgdG8gc3RhbmRhcmRpemUgYW5kIHN5bmNo cm9uaXplIE9wZW5TdGFjayB0byBPcGVuU3RhY2sgaW5zdHJ1bWVudGF0aW9uIHNpZ25hbGluZy4g VGhlIG5leHQgc3RlcCB3b3VsZCBiZSB0byBhY3R1YWxseSBhbHNvIHByb3ZpZGUgY2xvdWQgdG8g Y2xvdWQgY29tbXVuaWNhdGlvbiBsYXllci4gU2ltcGxlIGV4YW1wbGU6IEhvdyB0byBsYXVuY2gg TiBWTXMgaW4gdmFyaW91cyBkYXRhIGNlbnRlcnMgdG8gYmUgcGFydCBvZiBjb21tb24gcmVzb3Vy Y2VzIGZvciBjdXN0b21lciBYLg0KDQpPbiB0aGUgY29udHJhcnkgU0ROeCBzZWVtcyB0byBtZSBv ZiB0b3RhbGx5IGRpZmZlcmVudCBjYWxpYmVyLiBPbmUgd2F5IHRvIGxvb2sgYXQgdGhpcyBpcyB3 aGF0IGFuZCBob3cgd2UgY291bGQgdXNlIEFQSXMgZXhwb3NlZCBieSBleGlzdGluZyBuZXR3b3Jr IGNvbnRyb2wgcGxhbmVzIHRvIGRlZmluZSBhbmQgYWNjb21wbGlzaCBuZXcgbmV0d29yayBzZXJ2 aWNlcy4gSSBxdWl0ZSBkbyBub3Qgc2VlIGN1cnJlbnQgbmV0d29yayBlbGVtZW50IGNvbnRyb2wg cGxhbmVzIG5vciB0aGVpciBBUElzIGFzIG11Y2ggcmVsZXZhbnQgdG8gY2xvdWQgc2VydmljZXMu DQoNCk15IG93biBwZXJzb25hbCB2aWV3IDspDQoNClJlZ2FyZHMsDQpSLg0KDQoNCg0KSSdkIGxp a2UgdG8gZ2V0IHNvbWUgY2xhcmlmaWNhdGlvbiAoZnJvbSBhbnlvbmUgd2hvIG1pZ2h0IGtub3cg b3INCmhhdmUgYW4gb3Bpbmlvbikgb24gaG93IHRoaXMgd291bGQgaW50ZXJhY3Qgd2l0aC9iZSBk aXN0aW5jdCBmcm9tIGFueQ0Kb2YgdGhlIFNETlAgKG9yIHdoYXRldmVyIG5hbWUgd2UgZGVjaWRl IHVwb24pIHByb3Bvc2VkIHdvcmsuIElzIHRoaXMNCmR1cGxpY2F0aW9uL3Blb3BsZSBzdHJpa2lu ZyBvdXQgb24gdGhlaXIgb3duIGZyb20gdGhlIG5hc2NlbnQgU0ROUA0KZWZmb3J0LCBhIGNvbXBh bmlvbiBlZmZvcnQgdGhhdCBiZWNhbWUgY2xlYXIgYXMgd2UgaGF2ZSBiZWd1bg0Kc2VnbWVudGlu ZyB0aGUgcHJvYmxlbSBzcGFjZSwgb3Igc29tZXRoaW5nIGVsc2UgZW50aXJlbHk/IFNpbmNlIHRo aXMNCmlzIHRoZSBmaXJzdCBJJ3ZlIGhlYXJkIG9mIHRoZSBsaXN0LCBJJ20gdGhpbmtpbmcgaXQn cyBhIHNlcGFyYXRlDQplZmZvcnQsIGJ1dCBJIGZpZ3VyZWQgSSB3b3VsZCByYWlzZSB0aGUgdG9w aWMgZm9yIGRpc2N1c3Npb24uDQoNClRoYW5rcywNCg0KV2VzIEdlb3JnZQ0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBpZXRmLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmcNCltt YWlsdG86aWV0Zi1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnIDxtYWlsdG86aWV0Zi1hbm5vdW5j ZS1ib3VuY2VzQGlldGYub3JnPiBdIE9uIEJlaGFsZiBPZiBJRVRGDQpTZWNyZXRhcmlhdCBTZW50 OiBUdWVzZGF5LCBGZWJydWFyeSAxNCwgMjAxMiAyOjI1IFBNIFRvOiBJRVRGDQpBbm5vdW5jZW1l bnQgbGlzdCBDYzogc29wQGlldGYub3JnOyBNb25pcXVlIE1vcnJvdyBTdWJqZWN0OiBOZXcNCk5v bi1XRyBNYWlsaW5nIExpc3Q6IHNvcCAtLSBTZXJ2aWNlIE9yY2hlc3RyYXRpb24gYW5kIERlc2Np cHRpb24gZm9yDQpDbG91ZCBTZXJ2aWNlcw0KDQoNCg0KQSBuZXcgSUVURiBub24td29ya2luZyBn cm91cCBlbWFpbCBsaXN0IGhhcyBiZWVuIGNyZWF0ZWQuDQoNCkxpc3QgYWRkcmVzczogc29wQGll dGYub3JnIEFyY2hpdmU6DQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc29w LyA8aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NvcC8+ICBUbyBzdWJzY3Jp YmU6DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvcCA8aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb3A+IA0KDQpQdXJwb3NlOiBDbG91ZCBzZXJ2 aWNlcyBuZWVkIHRvIGludGVyb3BlcmF0ZSBhY3Jvc3MgY2xvdWQgcHJvdmlkZXJzLA0Kc2Vydmlj ZSB2ZW5kb3JzIGFuZCBwcml2YXRlL3B1YmxpYyBkb21haW5zLiBUbyBlbmFibGUgdGhpcw0KaW50 ZXJvcGVyYWJpbGl0eSwgdGhlcmUgaXMgbmVlZCBmb3IgYSBzdGFuZGFyZCB3aXJlLWZvcm1hdCBm b3INCmV4Y2hhbmdpbmcgc2VydmljZSBpbmZvcm1hdGlvbi4gVGhpcyBtYWlsaW5nIGxpc3RzIGlz IGZvciBkaXNjdXNzaW5nDQpwcm90b2NvbHMsIGRhdGEgZm9ybWF0cyBhbmQgc2VydmVyIGRlc2Ny aXB0aW9ucyBmb3JtYXRzIHRoYXQgYWxsb3cNCmNsb3VkIHNlcnZpY2VzIHRvIGJlIGRpc2NvdmVy ZWQgYW5kIHVzZWQgYWNyb3NzIHByaXZhdGUgYW5kIHB1YmxpYw0KZG9tYWlucy4gVXNpbmcgdGhl c2UsIGl0IHdvdWxkIGJlIHBvc3NpYmxlIHRvIGludGVyb3BlcmF0ZSBkaXZlcnNlDQpBUElzIGFu ZCBjbG91ZCBzZXJ2aWNlcyBhY3Jvc3Mgc2VydmljZSBwcm92aWRlcnMsIHNlcnZpY2UgdmVuZG9y cyBhbmQNCnNlcnZpY2UgdXNlcnMuDQoNCkZvciBhZGRpdGlvbmFsIGluZm9ybWF0aW9uLCBwbGVh c2UgY29udGFjdCB0aGUgbGlzdCBhZG1pbmlzdHJhdG9ycy4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fIElFVEYtQW5ub3VuY2UgbWFpbGluZw0KbGlzdCBJ RVRGLUFubm91bmNlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lldGYtYW5ub3VuY2UgPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aWV0Zi1hbm5vdW5jZT4gDQoNClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRz IG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlDQpwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwg d2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvcg0Kc3ViamVjdCB0byBjb3B5cmln aHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcw0KaW50ZW5k ZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGlj aCBpdA0KaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 IG9mIHRoaXMgRS1tYWlsLA0KeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2Vt aW5hdGlvbiwgZGlzdHJpYnV0aW9uLA0KY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0 aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQNCmF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlz IHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZQ0KdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5DQp0aGUgc2VuZGVyIGlt bWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkNCmNv cHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fIFNETlAgbWFpbGluZyBsaXN0DQpTRE5QQGx1Y2lk dmlzaW9uLmNvbSBodHRwOi8vbHVjaWR2aXNpb24uY29tL21haWxtYW4vbGlzdGluZm8vc2RucCA8 aHR0cDovL2x1Y2lkdmlzaW9uLmNvbS9tYWlsbWFuL2xpc3RpbmZvL3NkbnA+IA0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTRE5QIG1haWxpbmcg bGlzdA0KU0ROUEBsdWNpZHZpc2lvbi5jb20NCmh0dHA6Ly9sdWNpZHZpc2lvbi5jb20vbWFpbG1h bi9saXN0aW5mby9zZG5wIDxodHRwOi8vbHVjaWR2aXNpb24uY29tL21haWxtYW4vbGlzdGluZm8v c2RucD4gDQoNCiANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNETlAgbWFpbGluZyBs aXN0DQpTRE5QQGx1Y2lkdmlzaW9uLmNvbQ0KaHR0cDovL2x1Y2lkdmlzaW9uLmNvbS9tYWlsbWFu L2xpc3RpbmZvL3NkbnANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NClNETlAgbWFpbGluZyBsaXN0DQpTRE5QQGx1Y2lkdmlzaW9uLmNvbQ0KaHR0cDov L2x1Y2lkdmlzaW9uLmNvbS9tYWlsbWFuL2xpc3RpbmZvL3NkbnANCg0KIA0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzb3AgbWFpbGluZyBsaXN0 DQpzb3BAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29w DQoNCiANCg0KIA0KDQo= ------_=_NextPart_001_01CCECC5.666D81B5 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9w LWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxp bms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5QaW5nLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ VGhpcyBpc27igJl0IGp1c3QgYWJvdXQgdGhlIG5ldHdvcmsgcmVzb3VyY2VzIGFuZCBTT1AgaXNu 4oCZdCBvbmx5IGFib3V0IHByb3Zpc2lvbmluZyBuZXR3b3JrIHJlc291cmNlcy4gVGhlIHByb3Rv Y29sIGRlZmluaXRpb24gaXMgZ2VuZXJhbGl6ZWQgdG8gc3VwcG9ydCBhbnkga2luZCBvZiBzZXJ2 aWNlIOKAkyBuZXR3b3JrIGluY2x1ZGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VG8geW91ciBwb2lu dCBhYm91dCBjaGFuZ2luZyByb3V0ZXMg4oCTIEkgYWdyZWUgdG8gdGhhdCBjb21wbGV0ZWx5LiBU aGUgZ29hbCBpc27igJl0IHRvIHJlcGxhY2Ugcm91dGluZyBwcm90b2NvbHMhIFNPUCB3aWxsIHVz ZSBuZXR3b3JrIHJvdXRlcy4gQXMgeW91IHNheSwgaXQgY2FuIGJlIHVzZWQgdG8gcHJvdmlzaW9u IOKAnHBvbGljaWVz4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5UaGFua3MsIEFzaGlzaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBQaW5nIFBhbiBbbWFpbHRvOnBpbmdAcGluZ3Bh bi5vcmddIDxicj48Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDE2LCAyMDEyIDk6MjEg UE08YnI+PGI+VG86PC9iPiBBc2hpc2ggRGFsZWxhIChhZGFsZWxhKTxicj48Yj5DYzo8L2I+IFRo b21hcyBOYWRlYXU7IE1vbmlxdWUgTW9ycm93IChtbW9ycm93KTsgc2RucDsgc29wQGlldGYub3Jn OyByb2JlcnRAcmFzenVrLm5ldDxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtzb3BdIFtTZG5wXSBG VzogTmV3IE5vbi1XRyBNYWlsaW5nIExpc3Q6IHNvcCAtLSBTZXJ2aWNlIE9yY2hlc3RyYXRpb24g YW5kIERlc2NpcHRpb24gZm9yIENsb3VkIFNlcnZpY2VzPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+VGhlcmUgYXJlIHRhbGtzIG9uIG1vcmUgY29udHJvbCBmcm9tIGFwcGxpY2F0aW9ucyB0 byB0aGUgbmV0d29ya3MuPG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SU1ITywgdGhp cyBpcyBtb3JlIG9mIGEgbWlzdW5kZXJzdGFuZGluZyB0aGFuIGFueXRoaW5nIGVsc2UuJm5ic3A7 PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Rmlyc3QsIG1hbnkgREMgb3Bl cmF0b3JzIGhhdmUgbGVhc2VkIHRoZSBjaXJjdWl0cyBvciBidWlsdCB0aGUgbmV0d29yay4gVGhl eSBoYXZlIGV2ZXJ5IHJpZ2h0IHRvIGRlY2lkZSB0aGUgcG9saWN5IGF0IGVkZ2UgYW5kIGFnZ3Jl Z2F0ZSB0cmFmZmljIG9udG8gdGhlIG5ldHdvcmsgdGhleSBsZWFzZSBvciBvd24uIFNlY29uZCwg SSB0aGluayB0aGF0IHRoZSBzZXJ2aWNlIHByb3ZpZGVycyB3b3VsZCBoYXZlIG5vIHByb2JsZW0g dG8mbmJzcDtleHBlZGl0ZSZuYnNwO3RoZSBCVyBwcm92aXNpb25pbmcgcHJvY2VzcyB3aGVuIGEg Y3VzdG9tZXIgaXMgYXNraW5nIGZvciBtb3JlLCBidXQgbm8gc2VydmljZSBwcm92aWRlciB0byBt eSBiZXN0IGtub3dsZWRnZSB3b3VsZCBhbGxvdyB0aGUgY3VzdG9tZXJzIHRvIGFsdGVyIHRoZSBy b3V0ZXMgaW5zaWRlIHRoZWlyIG5ldHdvcmtzLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPlNvIGRlZXAtY29udHJvbCB0byBtZSBtZWFucyBhIGNsZWFuZXIsIHNpbXBsZXIg YW5kIGZhc3RlciB3YXkgdG8gcHJvdmlzaW9uaW5nIG5ldHdvcmsgcmVzb3VyY2VzIHRocm91Z2gg YSBjb25zaXN0ZW50IGludGVyZmFjZS48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD5QaW5nPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+T24gVGh1LCBGZWIgMTYs IDIwMTIgYXQgNzozOCBBTSwgQXNoaXNoIERhbGVsYSAoYWRhbGVsYSkgJmx0OzxhIGhyZWY9Im1h aWx0bzphZGFsZWxhQGNpc2NvLmNvbSI+YWRhbGVsYUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5XZWxsLCB5ZXMsIG9uZSBvZiB0aGUgdXNlLWNhc2Ug aXMgdG8gc29sdmUgaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZXMgYmV0d2VlbiBhbmQgYWNyb3NzIGNs b3Vkcy48L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JIGFsc28gaGF2ZSBoZWFyZCBmcm9tIGZvbGtz IHRoZSBuZWVkIGZvciDigJxkZWVwIGNvbnRyb2zigJ0gaW4gd2hpY2ggYSBjdXN0b21lciBvdXRz aWRlIHRoZSBjbG91ZCB3YW50cyB0byB0d2VhayBvciBjb250cm9sIHRoZSBpbmZyYXN0cnVjdHVy ZSBvciBhcHBsaWNhdGlvbiBhdCBhIGxvdyBncmFudWxhcml0eS4gSSB0aGluayB0aGF0IHdvdWxk IGJlIGhhcmQsIGFsdGhvdWdoIG5vdCBpbXBvc3NpYmxlLCBpZiB0aGUgbWVjaGFuaXNtcyBvdXRz aWRlIGFuZCBpbnNpZGUgd2VyZSBkaWZmZXJlbnQg4oCTIGFzIHlvdSB3aWxsIGhhdmUgdG8gY3Jl YXRlIG1hcHBpbmdzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoYXQgaXMgYSB0b3BpYyBxdWl0 ZSBvcGVuIGZvciBkaXNjdXNzaW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoYW5rcywgQXNo aXNoPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxk aXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48Yj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiInPiBQaW5nIFBhbiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpw aW5nQHBpbmdwYW4ub3JnIiB0YXJnZXQ9Il9ibGFuayI+cGluZ0BwaW5ncGFuLm9yZzwvYT5dIDxi cj48Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDE2LCAyMDEyIDg6NTQgUE08YnI+PGI+ VG86PC9iPiBBc2hpc2ggRGFsZWxhIChhZGFsZWxhKTxicj48Yj5DYzo8L2I+IFRob21hcyBOYWRl YXU7IE1vbmlxdWUgTW9ycm93IChtbW9ycm93KTsgc2RucDsgPGEgaHJlZj0ibWFpbHRvOnNvcEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNvcEBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0 bzpyb2JlcnRAcmFzenVrLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnJvYmVydEByYXN6dWsubmV0PC9h Pjxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtzb3BdIFtTZG5wXSBGVzogTmV3IE5vbi1XRyBNYWls aW5nIExpc3Q6IHNvcCAtLSBTZXJ2aWNlIE9yY2hlc3RyYXRpb24gYW5kIERlc2NpcHRpb24gZm9y IENsb3VkIFNlcnZpY2VzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Jz5ZZWFoLCBJIGhhdmUgcmVhZCBhbGwgdGhlIGRyYWZ0cyBkdXJpbmcgdGhlIERDIEJvRiBkaXNj dXNzaW9uLiBJbiBnZW5lcmFsLCB0aGlzIG1ha2VzIHNlbnNlLi4uPG86cD48L286cD48L3A+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPk15IHRoaW5raW5nIGlzIHRoYXQgd2UgbWF5IG5vdCB3YW50IHRv IHN0YW5kYXJkaXplIHRoZSBpbnRlcmlvciBEQyBtYW5hZ2VtZW50LCBhcyBlYWNoIHZlbmRvciBo YXMgb3duIHNvbHV0aW9uLiZuYnNwO0J1dCBhdCB0aGUgc2FtZSB0aW1lLCB3ZSBuZWVkIHRvIGVu YWJsZSBhcHBsaWNhdGlvbnMgYW5kIHNlcnZpY2VzIHRvIHJpZGUgb24gdG9wIG9mIERDIHJlc291 cmNlcy4gSW4gb3RoZXIgd29yZHMsIFNETiBpcyBpbiB0aGUgcG9zaXRpb24gdG8gZW5hYmxlIFZp cnR1YWwmbmJzcDtEQydzLCBhbmQgY3JlYXRlIHRoZSBpbnRlcmZhY2UgdG8gY29tbXVuaWNhdGUg d2l0aCBuZXR3b3JraW5nIHJlc291cmNlcyBhdCZuYnNwO2Fic3RyYWN0aW9uJm5ic3A7bGV2ZWwu IFNETiBzaG91bGQgbm90IGJlIHZpZXdlZCBhcyB0aGUgTk1TIGZvciBEQydzLjxvOnA+PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz5UaGVyZSBhcmUgYSBsb3Qgb2Ygd29yayB0 byBiZSBkb25lIGhlcmUsIGFuZCBtYW55IHBhcnRzIGFyZSBtb3ZpbmcuIExldCdzIHdvcmsgdG9n ZXRoZXIuPG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPlBpbmc8bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwv cD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPk9uIFRodSwgRmViIDE2LCAyMDEyIGF0IDc6MDIg QU0sIEFzaGlzaCBEYWxlbGEgKGFkYWxlbGEpICZsdDs8YSBocmVmPSJtYWlsdG86YWRhbGVsYUBj aXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5hZGFsZWxhQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+ U09QIGhhcyB0aGUgZm9sbG93aW5nIG1haW4gZ29hbHMg4oCTIDwvc3Bhbj48bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+PHAgc3R5bGU9J21hcmdpbi1sZWZ0Oi4yNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz4xLjwvc3Bhbj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QnPiZuYnNwOyA8L3NwYW4+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3 RCc+Rml4IGludGVyb3BlcmFiaWxpdHkgaXNzdWVzIHdpdGggY2xvdWQgc2VydmljZXMgdG9kYXku IE1haW4gZXhhbXBsZXMgYXJlIGludGVyLWNsb3VkLCBoeWJyaWQtY2xvdWQsIGFuZCBtdWx0aS12 ZW5kb3IgY2xvdWQuIEFsbCBjbG91ZCBzZXJ2aWNlcyBhcmUgYmVpbmcgZW5hYmxlZCB0aHJvdWdo IHByb3ByaWV0YXJ5IEFQSXMgdG9kYXksIHdoaWNoIGRvbuKAmXQgaW50ZXJvcGVyYXRlLiBUbyBp bnRlcm9wZXJhdGUgYWNyb3NzIHZlbmRvcnMsIHByb3ZpZGVycyBhbmQgY3VzdG9tZXJzLCB3ZSBu ZWVkIGFuIG9wZW4gc3RhbmRhcmQuIEFiaWxpdHkgdG8gZ28gYWNyb3NzIGFkbWluaXN0cmF0aXZl IGRvbWFpbnMgaXMgYSBiYXNpYyByZXF1aXJlbWVudC48L3NwYW4+PG86cD48L286cD48L3A+PHAg c3R5bGU9J21hcmdpbi1sZWZ0Oi4yNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+PHAgc3R5bGU9J21hcmdpbi1sZWZ0Oi4yNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz4yLjwvc3Bhbj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QnPiZuYnNwOyA8L3NwYW4+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFG NDk3RCc+QSBjbGVhciBzZXBhcmF0aW9uIGJldHdlZW4gc2VydmljZS1pbmRlcGVuZGVudCBhbmQg c2VydmljZS1kZXBlbmRlbnQgcGllY2VzIGluIGNsb3VkIHNlcnZpY2VzLiBTT1AgaXMgYWJvdXQg c2VydmljZS1pbmRlcGVuZGVudCBwaWVjZXMuIFVzaW5nIFNPUCwgYSB2YXJpZXR5IG9mIHNlcnZp Y2VzIGNvdWxkIGJlIGFjY2Vzc2VkIG9yIGFkdmVydGl6ZWQuIFNlcGFyYXRpb24gYmV0d2VlbiBz ZXJ2aWNlLWluZGVwZW5kZW50IGFuZCBzZXJ2aWNlLWRlcGVuZGVudCBwaWVjZXMgbWFrZXMgdGhl IHNjaGVtZSBleHRlbnNpYmxlIHRvIGFueSB0eXBlIG9mIHNlcnZpY2Ug4oCTIGN1cnJlbnQgb3Ig ZnV0dXJlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjI1aW4n PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9y OiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBzdHlsZT0nbWFyZ2luLWxl ZnQ6LjI1aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNv bGFzO2NvbG9yOiMxRjQ5N0QnPjMuPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny4wcHQ7 Y29sb3I6IzFGNDk3RCc+Jm5ic3A7IDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz5DcmVhdGUgYSBjb21tb24gc2No ZW1lIGZvciBzZXJ2aWNlIG9yY2hlc3RyYXRpb24gdGhhdCBjYW4gYmUgdXNlZCBhY3Jvc3MgY29t cHV0ZSwgbmV0d29yaywgc3RvcmFnZSwgc2VjdXJpdHksIGFwcGxpY2F0aW9ucywgZXRjLiBBIGNv bW1vbiBzZXQgb2YgY29uc3RydWN0cyB0aGF0IGNhbiBiZSBhcHBsaWVkIHRvIGFueSBzZXJ2aWNl IHR5cGUgd2hldGhlciBpdCBpcyBpbmZyYXN0cnVjdHVyZSBvciBhcHBsaWNhdGlvbi48L3NwYW4+ PG86cD48L286cD48L3A+PHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OkNvbnNvbGFzJz48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1k YWxlbGEtb3JjaGVzdHJhdGlvbi0wMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWRhbGVsYS1vcmNoZXN0cmF0aW9uLTAwPC9hPjwvc3Bhbj48bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTpDb25zb2xhcyc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzJz5UaGUgYWJvdmUgZHJhZnQgZGVzY3JpYmVzIHRoZSBwcm9ibGVtcyBTT1AgaXMg YWltZWQgdG8gYWRkcmVzcy4gVGhpcyBpcyB0aGUg4oCccmVxdWlyZW1lbnRz4oCdIGRyYWZ0Ljwv c3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcyc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzJz5UaGUgb3RoZXIgZHJhZnRzIGFyZTo8L3NwYW4+PG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTpDb25zb2xhcyc+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZGFs ZWxhLXNvcC1hcmNoaXRlY3R1cmUtMDAiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1kYWxlbGEtc29wLWFyY2hpdGVjdHVyZS0wMDwvYT4gLSBkZXNjcmli ZXMgdGhlIHVzZS1jYXNlcyBhbmQgbmV0d29yayBkZXBsb3ltZW50cyB3aXRoIHRoZSBwcm90b2Nv bDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcyc+PGEgaHJlZj0iaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZGFsZWxhLXNvcC0wMCIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRhbGVsYS1zb3AtMDA8L2E+IC0gZGVzY3Jp YmVzIHRoZSBwcm90b2NvbOKAmXMgbWVzc2FnZXMgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzJz48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kYWxl bGEtc2RmLTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtZGFsZWxhLXNkZi0wMDwvYT4gLSBkZXNjcmliZXMgc2VydmljZSBuYW1pbmcsIHdvcmtmbG93 IGNvbnN0cnVjdGlvbiwgZXRjLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcyc+ PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZGFsZWxhLXNvcC1mbG93 cy0wMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRh bGVsYS1zb3AtZmxvd3MtMDA8L2E+IC0gZGVzY3JpYmVzIHNvbWUgbWVzc2FnZSBmbG93czwvc3Bh bj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcyc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OkNvbnNvbGFzJz5UaGFua3MsIEFzaGlzaDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Jz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvJz48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiIn PiBUaG9tYXMgTmFkZWF1IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnRuYWRlYXVAbHVjaWR2aXNp b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+dG5hZGVhdUBsdWNpZHZpc2lvbi5jb208L2E+XSA8YnI+ PGI+U2VudDo8L2I+IFRodXJzZGF5LCBGZWJydWFyeSAxNiwgMjAxMiA3OjU5IFBNPGJyPjxiPlRv OjwvYj4gTW9uaXF1ZSBNb3Jyb3cgKG1tb3Jyb3cpPGJyPjxiPkNjOjwvYj4gUGluZyBQYW47IDxh IGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnJvYmVydEBy YXN6dWsubmV0PC9hPjsgc2RucDsgPGEgaHJlZj0ibWFpbHRvOnNvcEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPnNvcEBpZXRmLm9yZzwvYT48YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbU2RucF0g Rlc6IE5ldyBOb24tV0cgTWFpbGluZyBMaXN0OiBzb3AgLS0gU2VydmljZSBPcmNoZXN0cmF0aW9u IGFuZCBEZXNjaXB0aW9uIGZvciBDbG91ZCBTZXJ2aWNlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD48 L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286 cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rp dj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2FuIHlvdSBwbGVhc2UgZXhwbGFpbiB3 aGF0IHRoZSBwdXJwb3NlIG9mIFNPUCBpcyBhbmQgd2hhdCBpdHMgZ29hbHMgYXJlPzxvOnA+PC9v OnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+UGVvcGxlIG9uIHRoaXMgbGlzdCBoYXZl IGJlZW4gYWxzbyBhc2tpbmcgaG93IGl0IGRpZmZlcnMgZnJvbSBTRE4ocCksIHNvIGl0PG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz5taWdodCBiZSBoZWxwZnVs IHRvIGluY2x1ZGUgdGhhdCBhcyB3ZWxsLiA4KTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tVG9tPG86cD48L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPk9uIEZlYiAxNiwgMjAxMiwgYXQgOTowOSBBTSwgTW9uaXF1ZSBNb3Jyb3cgd3Jv dGU6PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCc+Jm5ic3A7PG86cD48L286cD48 L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5HdXlzIDxicj48YnI+UGxlYXNlIGpvaW4g dGhlIFNPUCBtYWlsZXIgPGJyPjxicj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMnPjxicj5MaXN0IGFkZHJlc3M6IDx1PjxzcGFuIHN0eWxl PSdjb2xvcjpibHVlJz48YSBocmVmPSJtYWlsdG86c29wQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+c29wQGlldGYub3JnPC9hPjxicj48L3NwYW4+PC91PkFyY2hpdmU6IDx1PjxzcGFuIHN0eWxl PSdjb2xvcjpibHVlJz48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvc29wLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9zb3AvPC9hPjxicj48L3NwYW4+PC91PlRvIHN1YnNjcmliZTogPHU+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsdWUnPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc29wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zb3A8L2E+PGJyPjwvc3Bhbj48L3U+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxicj48YnI+VElBPGJy Pjxicj5Nb25pcXVlPGJyPjxicj48YnI+T24gMi8xNC8xMiAxMDo0NSBQTSwgJnF1b3Q7UGluZyBQ YW4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpwaW5nQHBpbmdwYW4ub3JnIiB0YXJnZXQ9Il9i bGFuayI+cGluZ0BwaW5ncGFuLm9yZzwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdp bi1ib3R0b206MTIuMHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5XaGVyZSBkb2VzIE9wZW5TdGFjayBRdWFudHVtIGZp dD88YnI+PGJyPk9wZW5TdGFjayBRdWFudHVtIGlzIHRvIGhhdmUgYWdlbnRzIGluIGNvbnRyb2xs ZXJzIGFuZCBuZXR3b3JraW5nIGRldmljZXMgZm9yIHRoZSBwdXJwb3NlIG9mIGJldHRlciB0cmFu c3BvcnQuIFRoaXMgaXMgd2VsbCB3aXRoaW4gdGhlIGdvYWwgb2YgU0ROLjxicj48YnI+UGluZzxi cj48YnI+T24gVHVlLCBGZWIgMTQsIDIwMTIgYXQgMTozNyBQTSwgUm9iZXJ0IFJhc3p1ayAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnJvYmVydEByYXN6dWsubmV0IiB0YXJnZXQ9Il9ibGFuayI+cm9iZXJ0 QHJhc3p1ay5uZXQ8L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy LjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIic+PGJyPkFjdHVhbGx5IEkgdGhpbmsgdGhvc2UgYXJlIHF1aXRlIHNlcGFy YXRlIHByb2JsZW0gc3BhY2VzLjxicj48YnI+U09QIGFpbSB0byBhZGRyZXNzIHRoZSByZXF1aXJl bWVudCBvZiBjbG91ZCB0byBjbG91ZCBjb21tdW5pY2F0aW9uIChoeWJyaWQgb3IgbXVsdGktZG9t YWluKS4gVGhlIHdheSBJIHRoaW5rIGFib3V0IHRoaXMgaXMgaG93IHRvIHN0YW5kYXJkaXplIGFu ZCBzeW5jaHJvbml6ZSBPcGVuU3RhY2sgdG8gT3BlblN0YWNrIGluc3RydW1lbnRhdGlvbiBzaWdu YWxpbmcuIFRoZSBuZXh0IHN0ZXAgd291bGQgYmUgdG8gYWN0dWFsbHkgYWxzbyBwcm92aWRlIGNs b3VkIHRvIGNsb3VkIGNvbW11bmljYXRpb24gbGF5ZXIuIFNpbXBsZSBleGFtcGxlOiBIb3cgdG8g bGF1bmNoIE4gVk1zIGluIHZhcmlvdXMgZGF0YSBjZW50ZXJzIHRvIGJlIHBhcnQgb2YgY29tbW9u IHJlc291cmNlcyBmb3IgY3VzdG9tZXIgWC48YnI+PGJyPk9uIHRoZSBjb250cmFyeSBTRE54IHNl ZW1zIHRvIG1lIG9mIHRvdGFsbHkgZGlmZmVyZW50IGNhbGliZXIuIE9uZSB3YXkgdG8gbG9vayBh dCB0aGlzIGlzIHdoYXQgYW5kIGhvdyB3ZSBjb3VsZCB1c2UgQVBJcyBleHBvc2VkIGJ5IGV4aXN0 aW5nIG5ldHdvcmsgY29udHJvbCBwbGFuZXMgdG8gZGVmaW5lIGFuZCBhY2NvbXBsaXNoIG5ldyBu ZXR3b3JrIHNlcnZpY2VzLiBJIHF1aXRlIGRvIG5vdCBzZWUgY3VycmVudCBuZXR3b3JrIGVsZW1l bnQgY29udHJvbCBwbGFuZXMgbm9yIHRoZWlyIEFQSXMgYXMgbXVjaCByZWxldmFudCB0byBjbG91 ZCBzZXJ2aWNlcy48YnI+PGJyPk15IG93biBwZXJzb25hbCB2aWV3IDspPGJyPjxicj5SZWdhcmRz LDxicj5SLjxicj48YnI+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQnPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiInPkknZCBsaWtlIHRvIGdldCBzb21lIGNsYXJpZmljYXRpb24gKGZyb20gYW55b25lIHdobyBt aWdodCBrbm93IG9yPGJyPmhhdmUgYW4gb3Bpbmlvbikgb24gaG93IHRoaXMgd291bGQgaW50ZXJh Y3Qgd2l0aC9iZSBkaXN0aW5jdCBmcm9tIGFueTxicj5vZiB0aGUgU0ROUCAob3Igd2hhdGV2ZXIg bmFtZSB3ZSBkZWNpZGUgdXBvbikgcHJvcG9zZWQgd29yay4gSXMgdGhpczxicj5kdXBsaWNhdGlv bi9wZW9wbGUgc3RyaWtpbmcgb3V0IG9uIHRoZWlyIG93biBmcm9tIHRoZSBuYXNjZW50IFNETlA8 YnI+ZWZmb3J0LCBhIGNvbXBhbmlvbiBlZmZvcnQgdGhhdCBiZWNhbWUgY2xlYXIgYXMgd2UgaGF2 ZSBiZWd1bjxicj5zZWdtZW50aW5nIHRoZSBwcm9ibGVtIHNwYWNlLCBvciBzb21ldGhpbmcgZWxz ZSBlbnRpcmVseT8gU2luY2UgdGhpczxicj5pcyB0aGUgZmlyc3QgSSd2ZSBoZWFyZCBvZiB0aGUg bGlzdCwgSSdtIHRoaW5raW5nIGl0J3MgYSBzZXBhcmF0ZTxicj5lZmZvcnQsIGJ1dCBJIGZpZ3Vy ZWQgSSB3b3VsZCByYWlzZSB0aGUgdG9waWMgZm9yIGRpc2N1c3Npb24uPGJyPjxicj5UaGFua3Ms PGJyPjxicj5XZXMgR2VvcmdlPGJyPjxicj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9t OiA8YSBocmVmPSJtYWlsdG86aWV0Zi1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+aWV0Zi1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnPC9hPjxicj5bPGEgaHJlZj0i bWFpbHRvOmlldGYtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1h aWx0bzppZXRmLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWls dG86aWV0Zi1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRv OmlldGYtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IF0gT24gQmVoYWxmIE9mIElF VEY8YnI+U2VjcmV0YXJpYXQgU2VudDogVHVlc2RheSwgRmVicnVhcnkgMTQsIDIwMTIgMjoyNSBQ TSBUbzogSUVURjxicj5Bbm5vdW5jZW1lbnQgbGlzdCBDYzogPGEgaHJlZj0ibWFpbHRvOnNvcEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNvcEBpZXRmLm9yZzwvYT47IE1vbmlxdWUgTW9ycm93 IFN1YmplY3Q6IE5ldzxicj5Ob24tV0cgTWFpbGluZyBMaXN0OiBzb3AgLS0gU2VydmljZSBPcmNo ZXN0cmF0aW9uIGFuZCBEZXNjaXB0aW9uIGZvcjxicj5DbG91ZCBTZXJ2aWNlczxicj48YnI+PGJy Pjxicj5BIG5ldyBJRVRGIG5vbi13b3JraW5nIGdyb3VwIGVtYWlsIGxpc3QgaGFzIGJlZW4gY3Jl YXRlZC48YnI+PGJyPkxpc3QgYWRkcmVzczogPGEgaHJlZj0ibWFpbHRvOnNvcEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnNvcEBpZXRmLm9yZzwvYT4gQXJjaGl2ZTo8YnI+PGEgaHJlZj0iaHR0 cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NvcC8iIHRhcmdldD0iX2JsYW5rIj5o dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc29wLzwvYT4gJmx0OzxhIGhyZWY9 Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zb3AvIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NvcC88L2E+Jmd0OyAmbmJz cDtUbyBzdWJzY3JpYmU6PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc29wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zb3A8L2E+ICZsdDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NvcCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc29wPC9hPiZndDsgPGJyPjxicj5QdXJwb3NlOiBDbG91ZCBzZXJ2aWNl cyBuZWVkIHRvIGludGVyb3BlcmF0ZSBhY3Jvc3MgY2xvdWQgcHJvdmlkZXJzLDxicj5zZXJ2aWNl IHZlbmRvcnMgYW5kIHByaXZhdGUvcHVibGljIGRvbWFpbnMuIFRvIGVuYWJsZSB0aGlzPGJyPmlu dGVyb3BlcmFiaWxpdHksIHRoZXJlIGlzIG5lZWQgZm9yIGEgc3RhbmRhcmQgd2lyZS1mb3JtYXQg Zm9yPGJyPmV4Y2hhbmdpbmcgc2VydmljZSBpbmZvcm1hdGlvbi4gVGhpcyBtYWlsaW5nIGxpc3Rz IGlzIGZvciBkaXNjdXNzaW5nPGJyPnByb3RvY29scywgZGF0YSBmb3JtYXRzIGFuZCBzZXJ2ZXIg ZGVzY3JpcHRpb25zIGZvcm1hdHMgdGhhdCBhbGxvdzxicj5jbG91ZCBzZXJ2aWNlcyB0byBiZSBk aXNjb3ZlcmVkIGFuZCB1c2VkIGFjcm9zcyBwcml2YXRlIGFuZCBwdWJsaWM8YnI+ZG9tYWlucy4g VXNpbmcgdGhlc2UsIGl0IHdvdWxkIGJlIHBvc3NpYmxlIHRvIGludGVyb3BlcmF0ZSBkaXZlcnNl PGJyPkFQSXMgYW5kIGNsb3VkIHNlcnZpY2VzIGFjcm9zcyBzZXJ2aWNlIHByb3ZpZGVycywgc2Vy dmljZSB2ZW5kb3JzIGFuZDxicj5zZXJ2aWNlIHVzZXJzLjxicj48YnI+Rm9yIGFkZGl0aW9uYWwg aW5mb3JtYXRpb24sIHBsZWFzZSBjb250YWN0IHRoZSBsaXN0IGFkbWluaXN0cmF0b3JzLjxicj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBJRVRGLUFubm91 bmNlIG1haWxpbmc8YnI+bGlzdCA8YSBocmVmPSJtYWlsdG86SUVURi1Bbm5vdW5jZUBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPklFVEYtQW5ub3VuY2VAaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWV0Zi1hbm5vdW5jZSIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWV0Zi1h bm5vdW5jZTwvYT4gJmx0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaWV0Zi1hbm5vdW5jZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaWV0Zi1hbm5vdW5jZTwvYT4mZ3Q7IDxicj48YnI+VGhpcyBFLW1h aWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2Fi bGU8YnI+cHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZp ZGVudGlhbCwgb3I8YnI+c3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2Fy bmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpczxicj5pbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0PGJyPmlzIGFkZHJlc3NlZC4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCw8YnI+ eW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0 aW9uLDxicj5jb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRl bnRzIG9mIGFuZDxicj5hdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9o aWJpdGVkIGFuZCBtYXkgYmU8YnI+dW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg RS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5PGJyPnRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueTxicj5jb3B5IG9mIHRo aXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuPGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fIFNETlAgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0 bzpTRE5QQGx1Y2lkdmlzaW9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPlNETlBAbHVjaWR2aXNpb24u Y29tPC9hPiA8YSBocmVmPSJodHRwOi8vbHVjaWR2aXNpb24uY29tL21haWxtYW4vbGlzdGluZm8v c2RucCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9sdWNpZHZpc2lvbi5jb20vbWFpbG1hbi9saXN0 aW5mby9zZG5wPC9hPiAmbHQ7PGEgaHJlZj0iaHR0cDovL2x1Y2lkdmlzaW9uLmNvbS9tYWlsbWFu L2xpc3RpbmZvL3NkbnAiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbHVjaWR2aXNpb24uY29tL21h aWxtYW4vbGlzdGluZm8vc2RucDwvYT4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiJz48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+U0ROUCBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRv OlNETlBAbHVjaWR2aXNpb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+U0ROUEBsdWNpZHZpc2lvbi5j b208L2E+PGJyPjxhIGhyZWY9Imh0dHA6Ly9sdWNpZHZpc2lvbi5jb20vbWFpbG1hbi9saXN0aW5m by9zZG5wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2x1Y2lkdmlzaW9uLmNvbS9tYWlsbWFuL2xp c3RpbmZvL3NkbnA8L2E+ICZsdDs8YSBocmVmPSJodHRwOi8vbHVjaWR2aXNpb24uY29tL21haWxt YW4vbGlzdGluZm8vc2RucCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9sdWNpZHZpc2lvbi5jb20v bWFpbG1hbi9saXN0aW5mby9zZG5wPC9hPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRv bToxMi4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiInPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48ZGl2IGNsYXNz PU1zb05vcm1hbCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Jz48aHIgc2l6ZT0zIHdpZHRoPSI5NSUiIGFsaWduPWNlbnRlcj48L3NwYW4+PC9kaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 Q29uc29sYXMnPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPlNETlAgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpTRE5QQGx1Y2lkdmlzaW9u LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPlNETlBAbHVjaWR2aXNpb24uY29tPC9hPjxicj48YSBocmVm PSJodHRwOi8vbHVjaWR2aXNpb24uY29tL21haWxtYW4vbGlzdGluZm8vc2RucCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHA6Ly9sdWNpZHZpc2lvbi5jb20vbWFpbG1hbi9saXN0aW5mby9zZG5wPC9hPjwv c3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5TRE5QIG1haWxpbmcgbGlz dDxicj48YSBocmVmPSJtYWlsdG86U0ROUEBsdWNpZHZpc2lvbi5jb20iIHRhcmdldD0iX2JsYW5r Ij5TRE5QQGx1Y2lkdmlzaW9uLmNvbTwvYT48YnI+PGEgaHJlZj0iaHR0cDovL2x1Y2lkdmlzaW9u LmNvbS9tYWlsbWFuL2xpc3RpbmZvL3NkbnAiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbHVjaWR2 aXNpb24uY29tL21haWxtYW4vbGlzdGluZm8vc2RucDwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rp dj48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFs dDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Jz48YnI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+c29wIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJt YWlsdG86c29wQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c29wQGlldGYub3JnPC9hPjxicj48 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvcCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29wPC9hPjxv OnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2JvZHk+PC9o dG1sPg== ------_=_NextPart_001_01CCECC5.666D81B5-- From mphmmr@gmail.com Thu Feb 16 08:11:06 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6740021F8843 for ; Thu, 16 Feb 2012 08:11:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.369 X-Spam-Level: X-Spam-Status: No, score=-3.369 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 QA1d8cHfO2Lz for ; Thu, 16 Feb 2012 08:10:58 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8812B21F8835 for ; Thu, 16 Feb 2012 08:10:44 -0800 (PST) Received: by eekc41 with SMTP id c41so893574eek.31 for ; Thu, 16 Feb 2012 08:10:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H6zDZGGGyhq02Y+hKT/QKQeHBW0bKPuuCUTyF68DsVs=; b=Qs+zDVq3iPpvFVwa4b3pZFYS1C2vXyUOckccvNYnFlV+uwMbMwzsLh21pBcnjhBl1+ p60B/RuYA2ISVK8kZYyeJWor0QyuPsdzA0nOcEHbvV2rQMLwQIJbRVjW1swlOI7XkMLy agciIc8EU9zp1tRDiOrDUD8kIJ31mAewCNLwM= MIME-Version: 1.0 Received: by 10.112.86.106 with SMTP id o10mr1193596lbz.27.1329408641088; Thu, 16 Feb 2012 08:10:41 -0800 (PST) Received: by 10.112.104.70 with HTTP; Thu, 16 Feb 2012 08:10:40 -0800 (PST) In-Reply-To: References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> Date: Thu, 16 Feb 2012 11:10:40 -0500 Message-ID: From: Michael Hammer To: Ping Pan Content-Type: multipart/alternative; boundary=bcaec554e108d03e7204b917114e Cc: Thomas Nadeau , "Monique Morrow \(mmorrow\)" , robert@raszuk.net, "Ashish Dalela \(adalela\)" , sop@ietf.org Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 16:11:06 -0000 --bcaec554e108d03e7204b917114e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ping, (dropped the SDNP list -- let me know if this needs to be on both) I think we are coming at this space from two different directions. We were looking top down, and network focused folks looking bottoms up. Where they meet in the middle could very well be complementary and mutually supporting= . I don't think there is anything in the protocol that confines it to just DC, thought that will often be the basis of cloud services. Agree this is in early stages. Probably several years out to sort out the problem space. What we are looking at with SOP is that the problem space should also consider trade-offs between management and signaling and control protocols (SDNP may be more of the former than the latter, whereas we are looking at SOP to be the latter.), as well as the overall architecture that could included OSS/BSS systems and SBCs through which messages on the wire must transit. We want the cloud to scale as the number of XaaS goes from a handful to thousands of services. That is an issue for any service provider. I just hope that the same wheel doesn't need to be reinvented and the network need retrofitting every time a new service shows up. Make sense? Mike On Thu, Feb 16, 2012 at 10:57 AM, Ping Pan wrote: > Michael, > > I would ask the question somewhat differently: what can we do to enable > more new services and applications to make the best use of the network > resources? ;-) > > We are at the very early stage of cloud networking. We should not limit > ourselves on what we may accomplish with DC's. There is no hurry to jump > onto the solution, while the problem space itself is becoming more > interesting and lucrative at a stunning speed. ;-) > > Make sense? > > Regards, > > Ping > > > On Thu, Feb 16, 2012 at 7:39 AM, Michael Hammer wrote: > >> All, >> >> The question I would ask is how many Cloud services do we think there >> will be long run. >> Then ask, how many times the same methods/commands will need to be >> re-invented: Create, Update, Delete? >> >> Also, ask yourself, if you have to do multiple of those cloud services i= n >> synchronized fashion, would a tool designed for just one of those answer >> the mail? >> Can we abstract out the common elements and cover and integrate componen= t >> parts? >> >> Cloud seems to be in the state the telephone company found itself 100 >> years ago. Everything works fine so long as you do it Edison's way, or >> Tesla's or whomever. We had to go through a monopoly state before figur= ing >> out how to standardize. Looking to skip the monopoly phase this time >> around. >> >> Mike >> >> >> On Thu, Feb 16, 2012 at 10:23 AM, Ping Pan wrote: >> >>> Yeah, I have read all the drafts during the DC BoF discussion. In >>> general, this makes sense... >>> >>> My thinking is that we may not want to standardize the interior DC >>> management, as each vendor has own solution. But at the same time, we n= eed >>> to enable applications and services to ride on top of DC resources. In >>> other words, SDN is in the position to enable Virtual DC's, and create = the >>> interface to communicate with networking resources at abstraction level= . >>> SDN should not be viewed as the NMS for DC's. >>> >>> There are a lot of work to be done here, and many parts are moving. >>> Let's work together. >>> >>> Ping >>> >>> >>> On Thu, Feb 16, 2012 at 7:02 AM, Ashish Dalela (adalela) < >>> adalela@cisco.com> wrote: >>> >>>> ** ** >>>> >>>> SOP has the following main goals =96 **** >>>> >>>> ** ** >>>> >>>> **1. **Fix interoperability issues with cloud services today. Main >>>> examples are inter-cloud, hybrid-cloud, and multi-vendor cloud. All cl= oud >>>> services are being enabled through proprietary APIs today, which don= =92t >>>> interoperate. To interoperate across vendors, providers and customers,= we >>>> need an open standard. Ability to go across administrative domains is = a >>>> basic requirement.**** >>>> >>>> ** ** >>>> >>>> **2. **A clear separation between service-independent and >>>> service-dependent pieces in cloud services. SOP is about >>>> service-independent pieces. Using SOP, a variety of services could be >>>> accessed or advertized. Separation between service-independent and >>>> service-dependent pieces makes the scheme extensible to any type of se= rvice >>>> =96 current or future.**** >>>> >>>> ** ** >>>> >>>> **3. **Create a common scheme for service orchestration that can be >>>> used across compute, network, storage, security, applications, etc. A >>>> common set of constructs that can be applied to any service type wheth= er it >>>> is infrastructure or application.**** >>>> >>>> ** ** >>>> >>>> http://tools.ietf.org/html/draft-dalela-orchestration-00**** >>>> >>>> ** ** >>>> >>>> The above draft describes the problems SOP is aimed to address. This i= s >>>> the =93requirements=94 draft.**** >>>> >>>> ** ** >>>> >>>> The other drafts are:**** >>>> >>>> ** ** >>>> >>>> http://tools.ietf.org/html/draft-dalela-sop-architecture-00 - >>>> describes the use-cases and network deployments with the protocol**** >>>> >>>> http://tools.ietf.org/html/draft-dalela-sop-00 - describes the >>>> protocol=92s messages **** >>>> >>>> http://tools.ietf.org/html/draft-dalela-sdf-00 - describes service >>>> naming, workflow construction, etc.**** >>>> >>>> http://tools.ietf.org/html/draft-dalela-sop-flows-00 - describes some >>>> message flows**** >>>> >>>> ** ** >>>> >>>> Thanks, Ashish**** >>>> >>>> ** ** >>>> >>>> ** ** >>>> >>>> *From:* Thomas Nadeau [mailto:tnadeau@lucidvision.com] >>>> *Sent:* Thursday, February 16, 2012 7:59 PM >>>> *To:* Monique Morrow (mmorrow) >>>> *Cc:* Ping Pan; robert@raszuk.net; sdnp; sop@ietf.org >>>> *Subject:* Re: [Sdnp] FW: New Non-WG Mailing List: sop -- Service >>>> Orchestration and Desciption for Cloud Services**** >>>> >>>> ** ** >>>> >>>> ** ** >>>> >>>> Can you please explain what the purpose of SOP is and what >>>> its goals are?**** >>>> >>>> People on this list have been also asking how it differs from SDN(p), >>>> so it**** >>>> >>>> might be helpful to include that as well. 8)**** >>>> >>>> **** >>>> >>>> --Tom**** >>>> >>>> ** ** >>>> >>>> ** ** >>>> >>>> ** ** >>>> >>>> On Feb 16, 2012, at 9:09 AM, Monique Morrow wrote:**** >>>> >>>> >>>> >>>> **** >>>> >>>> Guys >>>> >>>> Please join the SOP mailer >>>> >>>> >>>> List address: *sop@ietf.org >>>> *Archive: *http://www.ietf.org/mail-archive/web/sop/ >>>> *To subscribe: *https://www.ietf.org/mailman/listinfo/sop >>>> * >>>> >>>> TIA >>>> >>>> Monique >>>> >>>> >>>> On 2/14/12 10:45 PM, "Ping Pan" wrote: >>>> >>>> >>>> **** >>>> >>>> Where does OpenStack Quantum fit? >>>> >>>> OpenStack Quantum is to have agents in controllers and networking >>>> devices for the purpose of better transport. This is well within the g= oal >>>> of SDN. >>>> >>>> Ping >>>> >>>> On Tue, Feb 14, 2012 at 1:37 PM, Robert Raszuk >>>> wrote: >>>> >>>> **** >>>> >>>> >>>> Actually I think those are quite separate problem spaces. >>>> >>>> SOP aim to address the requirement of cloud to cloud communication >>>> (hybrid or multi-domain). The way I think about this is how to standar= dize >>>> and synchronize OpenStack to OpenStack instrumentation signaling. The = next >>>> step would be to actually also provide cloud to cloud communication la= yer. >>>> Simple example: How to launch N VMs in various data centers to be part= of >>>> common resources for customer X. >>>> >>>> On the contrary SDNx seems to me of totally different caliber. One way >>>> to look at this is what and how we could use APIs exposed by existing >>>> network control planes to define and accomplish new network services. = I >>>> quite do not see current network element control planes nor their APIs= as >>>> much relevant to cloud services. >>>> >>>> My own personal view ;) >>>> >>>> Regards, >>>> R. >>>> >>>> >>>> >>>> **** >>>> >>>> I'd like to get some clarification (from anyone who might know or >>>> have an opinion) on how this would interact with/be distinct from any >>>> of the SDNP (or whatever name we decide upon) proposed work. Is this >>>> duplication/people striking out on their own from the nascent SDNP >>>> effort, a companion effort that became clear as we have begun >>>> segmenting the problem space, or something else entirely? Since this >>>> is the first I've heard of the list, I'm thinking it's a separate >>>> effort, but I figured I would raise the topic for discussion. >>>> >>>> Thanks, >>>> >>>> Wes George >>>> >>>> -----Original Message----- From: ietf-announce-bounces@ietf.org >>>> [mailto:ietf-announce-bounces@ietf.org < >>>> mailto:ietf-announce-bounces@ietf.org = > >>>> ] On Behalf Of IETF >>>> Secretariat Sent: Tuesday, February 14, 2012 2:25 PM To: IETF >>>> Announcement list Cc: sop@ietf.org; Monique Morrow Subject: New >>>> Non-WG Mailing List: sop -- Service Orchestration and Desciption for >>>> Cloud Services >>>> >>>> >>>> >>>> A new IETF non-working group email list has been created. >>>> >>>> List address: sop@ietf.org Archive: >>>> http://www.ietf.org/mail-archive/web/sop/ < >>>> http://www.ietf.org/mail-archive/web/sop/> To subscribe: >>>> https://www.ietf.org/mailman/listinfo/sop < >>>> https://www.ietf.org/mailman/listinfo/sop> >>>> >>>> Purpose: Cloud services need to interoperate across cloud providers, >>>> service vendors and private/public domains. To enable this >>>> interoperability, there is need for a standard wire-format for >>>> exchanging service information. This mailing lists is for discussing >>>> protocols, data formats and server descriptions formats that allow >>>> cloud services to be discovered and used across private and public >>>> domains. Using these, it would be possible to interoperate diverse >>>> APIs and cloud services across service providers, service vendors and >>>> service users. >>>> >>>> For additional information, please contact the list administrators. >>>> _______________________________________________ IETF-Announce mailing >>>> list IETF-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf-announce < >>>> https://www.ietf.org/mailman/listinfo/ietf-announce> >>>> >>>> This E-mail and any of its attachments may contain Time Warner Cable >>>> proprietary information, which is privileged, confidential, or >>>> subject to copyright belonging to Time Warner Cable. This E-mail is >>>> intended solely for the use of the individual or entity to which it >>>> is addressed. If you are not the intended recipient of this E-mail, >>>> you are hereby notified that any dissemination, distribution, >>>> copying, or action taken in relation to the contents of and >>>> attachments to this E-mail is strictly prohibited and may be >>>> unlawful. If you have received this E-mail in error, please notify >>>> the sender immediately and permanently delete the original and any >>>> copy of this E-mail and any printout. >>>> _______________________________________________ SDNP mailing list >>>> SDNP@lucidvision.com http://lucidvision.com/mailman/listinfo/sdnp < >>>> http://lucidvision.com/mailman/listinfo/sdnp> >>>> >>>> **** >>>> >>>> >>>> _______________________________________________ >>>> SDNP mailing list >>>> SDNP@lucidvision.com >>>> http://lucidvision.com/mailman/listinfo/sdnp < >>>> http://lucidvision.com/mailman/listinfo/sdnp> **** >>>> >>>> ** ** >>>> ------------------------------ >>>> >>>> _______________________________________________ >>>> SDNP mailing list >>>> SDNP@lucidvision.com >>>> http://lucidvision.com/mailman/listinfo/sdnp**** >>>> >>>> _______________________________________________ >>>> SDNP mailing list >>>> SDNP@lucidvision.com >>>> http://lucidvision.com/mailman/listinfo/sdnp**** >>>> >>>> ** ** >>>> >>>> _______________________________________________ >>>> sop mailing list >>>> sop@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sop >>>> >>>> >>> >>> _______________________________________________ >>> sop mailing list >>> sop@ietf.org >>> https://www.ietf.org/mailman/listinfo/sop >>> >>> >> > --bcaec554e108d03e7204b917114e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ping, (dropped the SDNP list -- let me know if this needs to be on both)
I think we are coming at this space from two different dir= ections. =A0We were looking top down, and network focused folks looking bot= toms up. =A0Where they meet in the middle could very well be complementary = and mutually supporting.

I don't think there is anything in the protocol tha= t confines it to just DC, thought that will often be the basis of cloud ser= vices.

Agree this is in early stages. =A0Probably = several years out to sort out the problem space. =A0What we are looking at = with SOP is that the problem space should also consider trade-offs between = management and signaling and control protocols (SDNP may be more of the for= mer than the latter, whereas we are looking at SOP to be the latter.), as w= ell as the overall architecture that could included OSS/BSS systems and SBC= s through which messages on the wire must transit.

We want the cloud to scale as the number of XaaS goes f= rom a handful to thousands of services. =A0That is an issue for any service= provider.

I just hope that the same wheel doesn&#= 39;t need to be reinvented and the network need retrofitting every time a n= ew service shows up.

Make sense?

Mike


On Thu, Feb 16, 2012 at 10:5= 7 AM, Ping Pan <pi= ng@pingpan.org> wrote:
Michael,

I would ask the = question somewhat differently: what can we do to enable more new services a= nd applications to make the best use of the network resources? ;-)

We are at the very early stage of cloud networking. We = should not limit ourselves on what we may accomplish with DC's. There i= s no hurry to jump onto the solution, while the problem space itself is bec= oming more interesting and lucrative at a stunning speed. ;-)=A0

Make sense?

Regards,

Ping


On Thu, Feb 16, 2012 at 7:39 AM, Michael Hammer <mphmmr@gmail.com>= ; wrote:
All,

The question I would= ask is how many Cloud services do we think there will be long run.
Then ask, how many times the same methods/commands will need to be re-inven= ted: =A0Create, Update, Delete?

Also, ask yourself, if you have to do multiple of those= cloud services in synchronized fashion, would a tool designed for just one= of those answer the mail?
Can we abstract out the common element= s and cover and integrate component parts?

Cloud seems to be in the state the telephone company fo= und itself 100 years ago. =A0Everything works fine so long as you do it Edi= son's way, or Tesla's or whomever. =A0We had to go through a monopo= ly state before figuring out how to standardize. =A0Looking to skip the mon= opoly phase this time around.

Mike


On Thu, Feb 16, 2012 at 10:23 AM, Ping Pan <ping@pingpan.org> wrote:
Yeah, I have read all the drafts during the DC BoF discussion. In general, = this makes sense...

My thinking is that we may not want = to standardize the interior DC management, as each vendor has own solution.= =A0But at the same time, we need to enable applications and services to rid= e on top of DC resources. In other words, SDN is in the position to enable = Virtual=A0DC's, and create the interface to communicate with networking= resources at=A0abstraction=A0level. SDN should not be viewed as the NMS fo= r DC's.

There are a lot of work to be done here, and many parts= are moving. Let's work together.

Ping


On Thu, Feb 16, 2012 at 7:02 = AM, Ashish Dalela (adalela) <adalela@cisco.com> wrote:

= =A0

SOP has the following main goals =96 <= /p>

=A0

1.=A0 Fix interoperability issues wit= h cloud services today. Main examples are inter-cloud, hybrid-cloud, and mu= lti-vendor cloud. All cloud services are being enabled through proprietary = APIs today, which don=92t interoperate. To interoperate across vendors, pro= viders and customers, we need an open standard. Ability to go across admini= strative domains is a basic requirement.

=A0

2.=A0 = A clear separation between service-independent and ser= vice-dependent pieces in cloud services. SOP is about service-independent p= ieces. Using SOP, a variety of services could be accessed or advertized. Se= paration between service-independent and service-dependent pieces makes the= scheme extensible to any type of service =96 current or future.<= /u>

=A0

3.=A0 = Create a common scheme for service orchestration that = can be used across compute, network, storage, security, applications, etc. = A common set of constructs that can be applied to any service type whether = it is infrastructure or application.

<= /u>=A0

http://tools.ietf.org/html/draft-dale= la-orchestration-00

=A0

The above draft describes the problems SOP = is aimed to address. This is the =93requirements=94 draft.

=A0

The other drafts are:<= /p>

=A0

http://tools.ietf.org/html/draft-dalela-sop-archite= cture-00 - describes the use-cases and network deployments with the pro= tocol

http://tools.ietf.org/html/draft-dalela-sop-00 - describes the prot= ocol=92s messages

http://tools.ietf.org/html/draft-dalela-sdf-00 - describes service = naming, workflow construction, etc.

http://tools.ietf.org/html/draft-dalela-sop-flows-00 - desc= ribes some message flows

=A0

Thanks, Ashish

=A0

=A0

From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]
Sent: Thursday, February 16, 2012 7:59 PM
To: Monique Morr= ow (mmorrow)
Cc: Ping Pan; robert@raszuk.net; sdnp; sop@ietf.org
Subject: Re: [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orch= estration and Desciption for Cloud Services

<= /div>

=A0

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Can you please explain what th= e purpose of SOP is and what its goals are?

People on this list have been also asking how it differs fro= m SDN(p), so it

might be helpful to include that as well.= 8)

=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 --Tom

=A0

=A0

=A0

On Feb 16, 2012, at 9:09 A= M, Monique Morrow wrote:



Guys

Please join the SOP mailer


List address: sop@ietf.org
<= /u>Archive: http://www.ietf.org/mail-archive/web= /sop/
To subscribe: https://www.ietf.org/ma= ilman/listinfo/sop


TIA

Monique


On 2/14/12 10:45 PM, "Ping Pan"= <ping@pingpan.org> wrote:


Where does OpenStack Quantum fit?

OpenStack Quantum is to have agents in controllers and networking devic= es for the purpose of better transport. This is well within the goal of SDN= .

Ping

On Tue, Feb 14, 2012 at 1:37 PM, Robert Raszuk <= robert@raszuk.net> wrote:


Actual= ly I think those are quite separate problem spaces.

SOP aim to addre= ss the requirement of cloud to cloud communication (hybrid or multi-domain)= . The way I think about this is how to standardize and synchronize OpenStac= k to OpenStack instrumentation signaling. The next step would be to actuall= y also provide cloud to cloud communication layer. Simple example: How to l= aunch N VMs in various data centers to be part of common resources for cust= omer X.

On the contrary SDNx seems to me of totally different caliber. One way = to look at this is what and how we could use APIs exposed by existing netwo= rk control planes to define and accomplish new network services. I quite do= not see current network element control planes nor their APIs as much rele= vant to cloud services.

My own personal view ;)

Regards,
R.



=

I'd like to get some clarification (from anyone who might know o= r
have an opinion) on how this would interact with/be distinct from any
of= the SDNP (or whatever name we decide upon) proposed work. Is this
dupli= cation/people striking out on their own from the nascent SDNP
effort, a = companion effort that became clear as we have begun
segmenting the problem space, or something else entirely? Since this
is = the first I've heard of the list, I'm thinking it's a separate<= br>effort, but I figured I would raise the topic for discussion.

Thanks,

Wes George

-----Original Message----- From: ietf-a= nnounce-bounces@ietf.org
[mailto:ietf-announce-bounces@ietf.org <mailto:iet= f-announce-bounces@ietf.org> ] On Behalf Of IETF
Secretariat Sent: Tuesday, February 14, 2012 2:25 PM To: IETF
Announceme= nt list Cc: sop@ietf.org; Monique Morrow Subject: New
Non-WG Mail= ing List: sop -- Service Orchestration and Desciption for
Cloud Services=



A new IETF non-working group email list has been created.
List address: sop@ietf.org Archive:
http://www.ietf.org/mail-archi= ve/web/sop/ <http://www.ietf.org/mail-archive/web/sop/> =A0To su= bscribe:
htt= ps://www.ietf.org/mailman/listinfo/sop <https://www.ietf.org/mailman/li= stinfo/sop>

Purpose: Cloud services need to interoperate across cloud providers,service vendors and private/public domains. To enable this
interoperabi= lity, there is need for a standard wire-format for
exchanging service in= formation. This mailing lists is for discussing
protocols, data formats and server descriptions formats that allow
cloud= services to be discovered and used across private and public
domains. U= sing these, it would be possible to interoperate diverse
APIs and cloud = services across service providers, service vendors and
service users.

For additional information, please contact the list a= dministrators.
_______________________________________________ IETF-Anno= unce mailing
list IETF-Announce@ietf.org
https://www.ie= tf.org/mailman/listinfo/ietf-announce <https://www.ietf.org/m= ailman/listinfo/ietf-announce>

This E-mail and any of its attachments may contain Time Warner Cableproprietary information, which is privileged, confidential, or
subject = to copyright belonging to Time Warner Cable. This E-mail is
intended sol= ely for the use of the individual or entity to which it
is addressed. If you are not the intended recipient of this E-mail,
you = are hereby notified that any dissemination, distribution,
copying, or ac= tion taken in relation to the contents of and
attachments to this E-mail= is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify
the s= ender immediately and permanently delete the original and any
copy of th= is E-mail and any printout.
____________________________________________= ___ SDNP mailing list
SDNP@lucidvision.com http://lucidvision.com/mailman/listinfo/sdnp <http://lucidvision.com/mailman/listinfo/sdnp>


______= _________________________________________
SDNP mailing list
SDNP@l= ucidvision.com
= http://lucidvision.com/mailman/listinfo/sdnp <http://lucidvision.com= /mailman/listinfo/sdnp>

= =A0

_= ______________________________________________
SDNP mailing list
SDNP@lucidvision.com
http://lucidvision.com/= mailman/listinfo/sdnp

_______________________________________________
SDNP mailing list
SDNP@lucidvision.com=
http://lucidvision.com/mailman/listinfo/sdnp

=A0

<= /div>
_______________________________________________ sop mailing list
sop@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sop



_______________________________________________
sop mailing list
sop@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sop




--bcaec554e108d03e7204b917114e-- From ping@pingpan.org Thu Feb 16 08:18:21 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322D221F87CD for ; Thu, 16 Feb 2012 08:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 3J08xQIlyeoZ for ; Thu, 16 Feb 2012 08:18:20 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with SMTP id 6633D21F872E for ; Thu, 16 Feb 2012 08:18:20 -0800 (PST) Received: from mail-qw0-f42.google.com ([209.85.216.42]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTz0sSx7NWrKhR8ij0YyDz+uXGFikYISS@postini.com; Thu, 16 Feb 2012 08:18:20 PST Received: by mail-qw0-f42.google.com with SMTP id y23so6666484qad.1 for ; Thu, 16 Feb 2012 08:18:19 -0800 (PST) Received: by 10.229.135.201 with SMTP id o9mr2142338qct.148.1329409099501; Thu, 16 Feb 2012 08:18:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.80.200 with HTTP; Thu, 16 Feb 2012 08:17:38 -0800 (PST) In-Reply-To: <618BE8B40039924EB9AED233D4A09C5103001EA3@XMB-BGL-416.cisco.com> References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C5103001E8E@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C5103001EA3@XMB-BGL-416.cisco.com> From: Ping Pan Date: Thu, 16 Feb 2012 08:17:38 -0800 Message-ID: To: "Ashish Dalela (adalela)" Content-Type: multipart/alternative; boundary=00248c6a862e23117a04b9172d79 X-Gm-Message-State: ALoCoQmx4R94GmUIluyUcL8btbfprE10XPO4Aq6B+NO10393eEEtUNoj5tbKKKuLcv832gz/RztG Cc: sop@ietf.org Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 16:18:21 -0000 --00248c6a862e23117a04b9172d79 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 16, 2012 at 8:09 AM, Ashish Dalela (adalela) wrote: > This isn=E2=80=99t just about the network resources and SOP isn=E2=80=99t= only about > provisioning network resources. The protocol definition is generalized to > support any kind of service =E2=80=93 network included. Be careful. Others have brought up similar proposal before. IETF stands for Internet Engineering TF... Networking is the name of the game. ;-) If not networking, I fear it would be wrong place to do the work. In SDN, our focus is on networking. Further, we are trying to distance ourselves from the actual DC network fabric design (all vendor-specific so far). Regards, Ping --00248c6a862e23117a04b9172d79 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Feb 16, 2012 at 8:09 AM, Ashish Dalela (= adalela) <adalela= @cisco.com> wrote:
This isn=E2=80=99t just about the network resources and SOP isn=E2=80=99t o= nly about provisioning network resources. The protocol definition is genera= lized to support any kind of service =E2=80=93 network included.

Be careful. Others have brought up similar proposal before= . IETF stands for Internet Engineering TF... Networking is the name of the = game. ;-) If not networking, I fear it would be wrong place to do the work.=

In SDN, our focus is on networking. Further, we are try= ing to distance=C2=A0ourselves=C2=A0from the actual DC network fabric desig= n (all vendor-specific so far).

Regards,

Ping
--00248c6a862e23117a04b9172d79-- From ping@pingpan.org Thu Feb 16 08:20:44 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C93D21F881F for ; Thu, 16 Feb 2012 08:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 oCwEXkyzRpEF for ; Thu, 16 Feb 2012 08:20:39 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with SMTP id CE77921F87FA for ; Thu, 16 Feb 2012 08:20:38 -0800 (PST) Received: from mail-qw0-f41.google.com ([209.85.216.41]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTz0s1umEaB13K8g4YI9grzWblTHs0VPH@postini.com; Thu, 16 Feb 2012 08:20:38 PST Received: by qadz32 with SMTP id z32so4522774qad.7 for ; Thu, 16 Feb 2012 08:20:37 -0800 (PST) Received: by 10.229.102.137 with SMTP id g9mr2068851qco.128.1329409237745; Thu, 16 Feb 2012 08:20:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.80.200 with HTTP; Thu, 16 Feb 2012 08:19:56 -0800 (PST) In-Reply-To: References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> From: Ping Pan Date: Thu, 16 Feb 2012 08:19:56 -0800 Message-ID: To: Michael Hammer Content-Type: multipart/alternative; boundary=002354470f7860829d04b9173585 X-Gm-Message-State: ALoCoQn2zG1rlbG+oYAG8Ovso9EAtRUswekJlsnYVJauuY30ZnGs1OkTThwsA3sHwO33tOCcDOTD Cc: Thomas Nadeau , "Monique Morrow \(mmorrow\)" , robert@raszuk.net, "Ashish Dalela \(adalela\)" , sop@ietf.org Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 16:20:44 -0000 --002354470f7860829d04b9173585 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Make sense! Thanks! Ping On Thu, Feb 16, 2012 at 8:10 AM, Michael Hammer wrote: > Ping, (dropped the SDNP list -- let me know if this needs to be on both) > > I think we are coming at this space from two different directions. We > were looking top down, and network focused folks looking bottoms up. Whe= re > they meet in the middle could very well be complementary and mutually > supporting. > > I don't think there is anything in the protocol that confines it to just > DC, thought that will often be the basis of cloud services. > > Agree this is in early stages. Probably several years out to sort out th= e > problem space. What we are looking at with SOP is that the problem space > should also consider trade-offs between management and signaling and > control protocols (SDNP may be more of the former than the latter, wherea= s > we are looking at SOP to be the latter.), as well as the overall > architecture that could included OSS/BSS systems and SBCs through which > messages on the wire must transit. > > We want the cloud to scale as the number of XaaS goes from a handful to > thousands of services. That is an issue for any service provider. > > I just hope that the same wheel doesn't need to be reinvented and the > network need retrofitting every time a new service shows up. > > Make sense? > > Mike > > > > On Thu, Feb 16, 2012 at 10:57 AM, Ping Pan wrote: > >> Michael, >> >> I would ask the question somewhat differently: what can we do to enable >> more new services and applications to make the best use of the network >> resources? ;-) >> >> We are at the very early stage of cloud networking. We should not limit >> ourselves on what we may accomplish with DC's. There is no hurry to jump >> onto the solution, while the problem space itself is becoming more >> interesting and lucrative at a stunning speed. ;-) >> >> Make sense? >> >> Regards, >> >> Ping >> >> >> On Thu, Feb 16, 2012 at 7:39 AM, Michael Hammer wrote= : >> >>> All, >>> >>> The question I would ask is how many Cloud services do we think there >>> will be long run. >>> Then ask, how many times the same methods/commands will need to be >>> re-invented: Create, Update, Delete? >>> >>> Also, ask yourself, if you have to do multiple of those cloud services >>> in synchronized fashion, would a tool designed for just one of those an= swer >>> the mail? >>> Can we abstract out the common elements and cover and integrate >>> component parts? >>> >>> Cloud seems to be in the state the telephone company found itself 100 >>> years ago. Everything works fine so long as you do it Edison's way, or >>> Tesla's or whomever. We had to go through a monopoly state before figu= ring >>> out how to standardize. Looking to skip the monopoly phase this time >>> around. >>> >>> Mike >>> >>> >>> On Thu, Feb 16, 2012 at 10:23 AM, Ping Pan wrote: >>> >>>> Yeah, I have read all the drafts during the DC BoF discussion. In >>>> general, this makes sense... >>>> >>>> My thinking is that we may not want to standardize the interior DC >>>> management, as each vendor has own solution. But at the same time, we = need >>>> to enable applications and services to ride on top of DC resources. In >>>> other words, SDN is in the position to enable Virtual DC's, and create= the >>>> interface to communicate with networking resources at abstraction leve= l. >>>> SDN should not be viewed as the NMS for DC's. >>>> >>>> There are a lot of work to be done here, and many parts are moving. >>>> Let's work together. >>>> >>>> Ping >>>> >>>> >>>> On Thu, Feb 16, 2012 at 7:02 AM, Ashish Dalela (adalela) < >>>> adalela@cisco.com> wrote: >>>> >>>>> ** ** >>>>> >>>>> SOP has the following main goals =E2=80=93 **** >>>>> >>>>> ** ** >>>>> >>>>> **1. **Fix interoperability issues with cloud services today. Main >>>>> examples are inter-cloud, hybrid-cloud, and multi-vendor cloud. All c= loud >>>>> services are being enabled through proprietary APIs today, which don= =E2=80=99t >>>>> interoperate. To interoperate across vendors, providers and customers= , we >>>>> need an open standard. Ability to go across administrative domains is= a >>>>> basic requirement.**** >>>>> >>>>> ** ** >>>>> >>>>> **2. **A clear separation between service-independent and >>>>> service-dependent pieces in cloud services. SOP is about >>>>> service-independent pieces. Using SOP, a variety of services could be >>>>> accessed or advertized. Separation between service-independent and >>>>> service-dependent pieces makes the scheme extensible to any type of s= ervice >>>>> =E2=80=93 current or future.**** >>>>> >>>>> ** ** >>>>> >>>>> **3. **Create a common scheme for service orchestration that can be >>>>> used across compute, network, storage, security, applications, etc. A >>>>> common set of constructs that can be applied to any service type whet= her it >>>>> is infrastructure or application.**** >>>>> >>>>> ** ** >>>>> >>>>> http://tools.ietf.org/html/draft-dalela-orchestration-00**** >>>>> >>>>> ** ** >>>>> >>>>> The above draft describes the problems SOP is aimed to address. This >>>>> is the =E2=80=9Crequirements=E2=80=9D draft.**** >>>>> >>>>> ** ** >>>>> >>>>> The other drafts are:**** >>>>> >>>>> ** ** >>>>> >>>>> http://tools.ietf.org/html/draft-dalela-sop-architecture-00 - >>>>> describes the use-cases and network deployments with the protocol**** >>>>> >>>>> http://tools.ietf.org/html/draft-dalela-sop-00 - describes the >>>>> protocol=E2=80=99s messages **** >>>>> >>>>> http://tools.ietf.org/html/draft-dalela-sdf-00 - describes service >>>>> naming, workflow construction, etc.**** >>>>> >>>>> http://tools.ietf.org/html/draft-dalela-sop-flows-00 - describes some >>>>> message flows**** >>>>> >>>>> ** ** >>>>> >>>>> Thanks, Ashish**** >>>>> >>>>> ** ** >>>>> >>>>> ** ** >>>>> >>>>> *From:* Thomas Nadeau [mailto:tnadeau@lucidvision.com] >>>>> *Sent:* Thursday, February 16, 2012 7:59 PM >>>>> *To:* Monique Morrow (mmorrow) >>>>> *Cc:* Ping Pan; robert@raszuk.net; sdnp; sop@ietf.org >>>>> *Subject:* Re: [Sdnp] FW: New Non-WG Mailing List: sop -- Service >>>>> Orchestration and Desciption for Cloud Services**** >>>>> >>>>> ** ** >>>>> >>>>> ** ** >>>>> >>>>> Can you please explain what the purpose of SOP is and >>>>> what its goals are?**** >>>>> >>>>> People on this list have been also asking how it differs from SDN(p), >>>>> so it**** >>>>> >>>>> might be helpful to include that as well. 8)**** >>>>> >>>>> **** >>>>> >>>>> --Tom**** >>>>> >>>>> ** ** >>>>> >>>>> ** ** >>>>> >>>>> ** ** >>>>> >>>>> On Feb 16, 2012, at 9:09 AM, Monique Morrow wrote:**** >>>>> >>>>> >>>>> >>>>> **** >>>>> >>>>> Guys >>>>> >>>>> Please join the SOP mailer >>>>> >>>>> >>>>> List address: *sop@ietf.org >>>>> *Archive: *http://www.ietf.org/mail-archive/web/sop/ >>>>> *To subscribe: *https://www.ietf.org/mailman/listinfo/sop >>>>> * >>>>> >>>>> TIA >>>>> >>>>> Monique >>>>> >>>>> >>>>> On 2/14/12 10:45 PM, "Ping Pan" wrote: >>>>> >>>>> >>>>> **** >>>>> >>>>> Where does OpenStack Quantum fit? >>>>> >>>>> OpenStack Quantum is to have agents in controllers and networking >>>>> devices for the purpose of better transport. This is well within the = goal >>>>> of SDN. >>>>> >>>>> Ping >>>>> >>>>> On Tue, Feb 14, 2012 at 1:37 PM, Robert Raszuk >>>>> wrote: >>>>> >>>>> **** >>>>> >>>>> >>>>> Actually I think those are quite separate problem spaces. >>>>> >>>>> SOP aim to address the requirement of cloud to cloud communication >>>>> (hybrid or multi-domain). The way I think about this is how to standa= rdize >>>>> and synchronize OpenStack to OpenStack instrumentation signaling. The= next >>>>> step would be to actually also provide cloud to cloud communication l= ayer. >>>>> Simple example: How to launch N VMs in various data centers to be par= t of >>>>> common resources for customer X. >>>>> >>>>> On the contrary SDNx seems to me of totally different caliber. One wa= y >>>>> to look at this is what and how we could use APIs exposed by existing >>>>> network control planes to define and accomplish new network services.= I >>>>> quite do not see current network element control planes nor their API= s as >>>>> much relevant to cloud services. >>>>> >>>>> My own personal view ;) >>>>> >>>>> Regards, >>>>> R. >>>>> >>>>> >>>>> >>>>> **** >>>>> >>>>> I'd like to get some clarification (from anyone who might know or >>>>> have an opinion) on how this would interact with/be distinct from any >>>>> of the SDNP (or whatever name we decide upon) proposed work. Is this >>>>> duplication/people striking out on their own from the nascent SDNP >>>>> effort, a companion effort that became clear as we have begun >>>>> segmenting the problem space, or something else entirely? Since this >>>>> is the first I've heard of the list, I'm thinking it's a separate >>>>> effort, but I figured I would raise the topic for discussion. >>>>> >>>>> Thanks, >>>>> >>>>> Wes George >>>>> >>>>> -----Original Message----- From: ietf-announce-bounces@ietf.org >>>>> [mailto:ietf-announce-bounces@ietf.org< >>>>> mailto:ietf-announce-bounces@ietf.org > >>>>> ] On Behalf Of IETF >>>>> Secretariat Sent: Tuesday, February 14, 2012 2:25 PM To: IETF >>>>> Announcement list Cc: sop@ietf.org; Monique Morrow Subject: New >>>>> Non-WG Mailing List: sop -- Service Orchestration and Desciption for >>>>> Cloud Services >>>>> >>>>> >>>>> >>>>> A new IETF non-working group email list has been created. >>>>> >>>>> List address: sop@ietf.org Archive: >>>>> http://www.ietf.org/mail-archive/web/sop/ < >>>>> http://www.ietf.org/mail-archive/web/sop/> To subscribe: >>>>> https://www.ietf.org/mailman/listinfo/sop < >>>>> https://www.ietf.org/mailman/listinfo/sop> >>>>> >>>>> Purpose: Cloud services need to interoperate across cloud providers, >>>>> service vendors and private/public domains. To enable this >>>>> interoperability, there is need for a standard wire-format for >>>>> exchanging service information. This mailing lists is for discussing >>>>> protocols, data formats and server descriptions formats that allow >>>>> cloud services to be discovered and used across private and public >>>>> domains. Using these, it would be possible to interoperate diverse >>>>> APIs and cloud services across service providers, service vendors and >>>>> service users. >>>>> >>>>> For additional information, please contact the list administrators. >>>>> _______________________________________________ IETF-Announce mailing >>>>> list IETF-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ietf-announce < >>>>> https://www.ietf.org/mailman/listinfo/ietf-announce> >>>>> >>>>> This E-mail and any of its attachments may contain Time Warner Cable >>>>> proprietary information, which is privileged, confidential, or >>>>> subject to copyright belonging to Time Warner Cable. This E-mail is >>>>> intended solely for the use of the individual or entity to which it >>>>> is addressed. If you are not the intended recipient of this E-mail, >>>>> you are hereby notified that any dissemination, distribution, >>>>> copying, or action taken in relation to the contents of and >>>>> attachments to this E-mail is strictly prohibited and may be >>>>> unlawful. If you have received this E-mail in error, please notify >>>>> the sender immediately and permanently delete the original and any >>>>> copy of this E-mail and any printout. >>>>> _______________________________________________ SDNP mailing list >>>>> SDNP@lucidvision.com http://lucidvision.com/mailman/listinfo/sdnp < >>>>> http://lucidvision.com/mailman/listinfo/sdnp> >>>>> >>>>> **** >>>>> >>>>> >>>>> _______________________________________________ >>>>> SDNP mailing list >>>>> SDNP@lucidvision.com >>>>> http://lucidvision.com/mailman/listinfo/sdnp < >>>>> http://lucidvision.com/mailman/listinfo/sdnp> **** >>>>> >>>>> ** ** >>>>> ------------------------------ >>>>> >>>>> _______________________________________________ >>>>> SDNP mailing list >>>>> SDNP@lucidvision.com >>>>> http://lucidvision.com/mailman/listinfo/sdnp**** >>>>> >>>>> _______________________________________________ >>>>> SDNP mailing list >>>>> SDNP@lucidvision.com >>>>> http://lucidvision.com/mailman/listinfo/sdnp**** >>>>> >>>>> ** ** >>>>> >>>>> _______________________________________________ >>>>> sop mailing list >>>>> sop@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sop >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> sop mailing list >>>> sop@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sop >>>> >>>> >>> >> > --002354470f7860829d04b9173585 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Make sense!

Thanks!

Ping

On Thu, Feb 16, 2012 at 8:10 AM, Michael H= ammer <mphmmr@gmai= l.com> wrote:
Ping, (dropped the SDNP list -- let me know = if this needs to be on both)

I think we are coming at th= is space from two different directions. =C2=A0We were looking top down, and= network focused folks looking bottoms up. =C2=A0Where they meet in the mid= dle could very well be complementary and mutually supporting.

I don't think there is anything in the protocol tha= t confines it to just DC, thought that will often be the basis of cloud ser= vices.

Agree this is in early stages. =C2=A0Probab= ly several years out to sort out the problem space. =C2=A0What we are looki= ng at with SOP is that the problem space should also consider trade-offs be= tween management and signaling and control protocols (SDNP may be more of t= he former than the latter, whereas we are looking at SOP to be the latter.)= , as well as the overall architecture that could included OSS/BSS systems a= nd SBCs through which messages on the wire must transit.

We want the cloud to scale as the number of XaaS goes f= rom a handful to thousands of services. =C2=A0That is an issue for any serv= ice provider.

I just hope that the same wheel does= n't need to be reinvented and the network need retrofitting every time = a new service shows up.

Make sense?

Mike



On Thu, Feb 16, 2012 at 10:57 AM, Ping Pan &l= t;ping@pingpan.org> wrote:
Michael,

I would ask the = question somewhat differently: what can we do to enable more new services a= nd applications to make the best use of the network resources? ;-)

We are at the very early stage of cloud networking. We = should not limit ourselves on what we may accomplish with DC's. There i= s no hurry to jump onto the solution, while the problem space itself is bec= oming more interesting and lucrative at a stunning speed. ;-)=C2=A0

Make sense?

Regards,

Ping


On Thu, Fe= b 16, 2012 at 7:39 AM, Michael Hammer <mphmmr@gmail.com> wrot= e:
All,

The question I would= ask is how many Cloud services do we think there will be long run.
Then ask, how many times the same methods/commands will need to be re-inven= ted: =C2=A0Create, Update, Delete?

Also, ask yourself, if you have to do multiple of those= cloud services in synchronized fashion, would a tool designed for just one= of those answer the mail?
Can we abstract out the common element= s and cover and integrate component parts?

Cloud seems to be in the state the telephone company fo= und itself 100 years ago. =C2=A0Everything works fine so long as you do it = Edison's way, or Tesla's or whomever. =C2=A0We had to go through a = monopoly state before figuring out how to standardize. =C2=A0Looking to ski= p the monopoly phase this time around.

Mike


On Thu, Feb 16, 2012 at 10:23 AM, Ping Pan <ping@pingpan.org> wrote:
Yeah, I have read all the drafts during the DC BoF discussion. In general, = this makes sense...

My thinking is that we may not want = to standardize the interior DC management, as each vendor has own solution.= =C2=A0But at the same time, we need to enable applications and services to = ride on top of DC resources. In other words, SDN is in the position to enab= le Virtual=C2=A0DC's, and create the interface to communicate with netw= orking resources at=C2=A0abstraction=C2=A0level. SDN should not be viewed a= s the NMS for DC's.

There are a lot of work to be done here, and many parts= are moving. Let's work together.

Ping


On Thu, Feb 16, 2012 at 7:02 = AM, Ashish Dalela (adalela) <adalela@cisco.com> wrote:

= =C2=A0

SOP has the following main goals =E2=80=93

=C2=A0

1.=C2=A0 Fix interoperability issues = with cloud services today. Main examples are inter-cloud, hybrid-cloud, and= multi-vendor cloud. All cloud services are being enabled through proprieta= ry APIs today, which don=E2=80=99t interoperate. To interoperate across ven= dors, providers and customers, we need an open standard. Ability to go acro= ss administrative domains is a basic requirement.

=C2=A0

2.= =C2=A0 A clear separation between service-independent = and service-dependent pieces in cloud services. SOP is about service-indepe= ndent pieces. Using SOP, a variety of services could be accessed or adverti= zed. Separation between service-independent and service-dependent pieces ma= kes the scheme extensible to any type of service =E2=80=93 current or futur= e.

=C2=A0

3.= =C2=A0 Create a common scheme for service orchestratio= n that can be used across compute, network, storage, security, applications= , etc. A common set of constructs that can be applied to any service type w= hether it is infrastructure or application.

<= /u>=C2=A0

http://tools.ietf.org/html/draft-d= alela-orchestration-00

=C2=A0

The above draft describes the problems S= OP is aimed to address. This is the =E2=80=9Crequirements=E2=80=9D draft.

=C2=A0

The other drafts are:

=C2=A0<= /span>

http://tools.ietf.org/html/draft-dalela-sop-arch= itecture-00 - describes the use-cases and network deployments with the = protocol

http://tools.ietf.org/html/draft-dalela-sop-00 - describes the prot= ocol=E2=80=99s messages

http://tools.ietf.org/html/draft-dalela-sdf-00 - describes service = naming, workflow construction, etc.

http://tools.ietf.org/html/draft-dalela-sop-flows-00 - desc= ribes some message flows

=C2=A0

Thanks, Ashish

<= p class=3D"MsoNormal"> =C2=A0

=C2=A0

From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]
Sent: Thursday, February 16, 2012 7:59 PM
To: Monique Morr= ow (mmorrow)
Cc: Ping Pan; robert@raszuk.net; sdnp; sop@ietf.org
Subject: Re: [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orch= estration and Desciption for Cloud Services

<= /div>

=C2=A0

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <= /span>Can you please explain what the purpose of SOP is and what its goals = are?

People on this list have = been also asking how it differs from SDN(p), so it

might be helpful to include that as well.= 8)

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --Tom

=C2=A0

=C2=A0

= =C2=A0

On Feb 16, 2012, a= t 9:09 AM, Monique Morrow wrote:



Guys

Please join the SOP mailer


List address: sop@ietf.org
<= /u>Archive: http://www.ietf.org/mail-archive/web= /sop/
To subscribe: https://www.ietf.org/ma= ilman/listinfo/sop


TIA

Monique


On 2/14/12 10:45 PM, "Ping Pan"= <ping@pingpan.org> wrote:


Where does OpenStack Quantum fit?

OpenStack Quantum is to have agents in controllers and networking devic= es for the purpose of better transport. This is well within the goal of SDN= .

Ping

On Tue, Feb 14, 2012 at 1:37 PM, Robert Raszuk <= robert@raszuk.net> wrote:


Actual= ly I think those are quite separate problem spaces.

SOP aim to addre= ss the requirement of cloud to cloud communication (hybrid or multi-domain)= . The way I think about this is how to standardize and synchronize OpenStac= k to OpenStack instrumentation signaling. The next step would be to actuall= y also provide cloud to cloud communication layer. Simple example: How to l= aunch N VMs in various data centers to be part of common resources for cust= omer X.

On the contrary SDNx seems to me of totally different caliber. One way = to look at this is what and how we could use APIs exposed by existing netwo= rk control planes to define and accomplish new network services. I quite do= not see current network element control planes nor their APIs as much rele= vant to cloud services.

My own personal view ;)

Regards,
R.



=

I'd like to get some clarification (from anyone who might know o= r
have an opinion) on how this would interact with/be distinct from any
of= the SDNP (or whatever name we decide upon) proposed work. Is this
dupli= cation/people striking out on their own from the nascent SDNP
effort, a = companion effort that became clear as we have begun
segmenting the problem space, or something else entirely? Since this
is = the first I've heard of the list, I'm thinking it's a separate<= br>effort, but I figured I would raise the topic for discussion.

Thanks,

Wes George

-----Original Message----- From: ietf-a= nnounce-bounces@ietf.org
[mailto:ietf-announce-bounces@ietf.org <mailto:iet= f-announce-bounces@ietf.org> ] On Behalf Of IETF
Secretariat Sent: Tuesday, February 14, 2012 2:25 PM To: IETF
Announceme= nt list Cc: sop@ietf.org; Monique Morrow Subject: New
Non-WG Mail= ing List: sop -- Service Orchestration and Desciption for
Cloud Services=



A new IETF non-working group email list has been created.
List address: sop@ietf.org Archive:
http://www.ietf.org/mail-archi= ve/web/sop/ <http://www.ietf.org/mail-archive/web/sop/> =C2=A0To= subscribe:
htt= ps://www.ietf.org/mailman/listinfo/sop <https://www.ietf.org/mailman/li= stinfo/sop>

Purpose: Cloud services need to interoperate across cloud providers,service vendors and private/public domains. To enable this
interoperabi= lity, there is need for a standard wire-format for
exchanging service in= formation. This mailing lists is for discussing
protocols, data formats and server descriptions formats that allow
cloud= services to be discovered and used across private and public
domains. U= sing these, it would be possible to interoperate diverse
APIs and cloud = services across service providers, service vendors and
service users.

For additional information, please contact the list a= dministrators.
_______________________________________________ IETF-Anno= unce mailing
list IETF-Announce@ietf.org
https://www.ie= tf.org/mailman/listinfo/ietf-announce <https://www.ietf.org/m= ailman/listinfo/ietf-announce>

This E-mail and any of its attachments may contain Time Warner Cableproprietary information, which is privileged, confidential, or
subject = to copyright belonging to Time Warner Cable. This E-mail is
intended sol= ely for the use of the individual or entity to which it
is addressed. If you are not the intended recipient of this E-mail,
you = are hereby notified that any dissemination, distribution,
copying, or ac= tion taken in relation to the contents of and
attachments to this E-mail= is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify
the s= ender immediately and permanently delete the original and any
copy of th= is E-mail and any printout.
____________________________________________= ___ SDNP mailing list
SDNP@lucidvision.com http://lucidvision.com/mailman/listinfo/sdnp <http://lucidvision.com/mailman/listinfo/sdnp>


______= _________________________________________
SDNP mailing list
SDNP@l= ucidvision.com
= http://lucidvision.com/mailman/listinfo/sdnp <http://lucidvision.com= /mailman/listinfo/sdnp>

= =C2=A0

_= ______________________________________________
SDNP mailing list
SDNP@lucidvision.com
http://lucidvision.com/= mailman/listinfo/sdnp

_______________________________________________
SDNP mailing list
SDNP@lucidvision.com=
http://lucidvision.com/mailman/listinfo/sdnp

=C2=A0


______________________________________________= _
sop mailing list
sop@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sop



_______________________________________________
sop mailing list
sop@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sop





--002354470f7860829d04b9173585-- From adalela@cisco.com Thu Feb 16 08:28:37 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C95A21F8665 for ; Thu, 16 Feb 2012 08:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.773 X-Spam-Level: X-Spam-Status: No, score=-6.773 tagged_above=-999 required=5 tests=[AWL=3.825, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 isLDMHMKlBNv for ; Thu, 16 Feb 2012 08:28:32 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 05FB621F864C for ; Thu, 16 Feb 2012 08:28:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=13676; q=dns/txt; s=iport; t=1329409711; x=1330619311; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=skFnAzN5g2qXhpQALbyVZ8BoigHnhHr++0apRfup0QU=; b=Y2X32zqEUQPR5eo5LFhBXdoKMAWFI/EE0d2PyPZhcUNUgeVIwFhHyALS eLZvTK0OZXgN7N8ewT85Y1hcRjGmrx0IANpUIJ7mN0yMZ6ZUwL7LoUvXW jL83SfKEuJJAOCUJ1Ad5BvhIJeYp1lGnHoOCg8eS/eXxORHi/Uh/vIJxd 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEALQtPU9Io8UY/2dsb2JhbABEgk2CRKpkgXaBcgEBAQMBEgEJBwoDPgsQAgEGAhEEAQELBhMEAQICAgEBRAgBCAEBBAsICBqHXZo4AYxlkWuLcgQUAUMRC4NjAQkGEQIDAgcSgh8zYwSITJ9b X-IronPort-AV: E=Sophos;i="4.73,430,1325462400"; d="scan'208,217";a="5728486" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 16 Feb 2012 16:28:29 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1GGSTuB027888; Thu, 16 Feb 2012 16:28:29 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Feb 2012 21:58:29 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCECC8.03B8D3D5" Date: Thu, 16 Feb 2012 21:58:27 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C5103001EB6@XMB-BGL-416.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services Thread-Index: Aczsxp3pzIT83E3jSxyeFcJXzkfM5wAAEXOQ References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com><618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com><618BE8B40039924EB9AED233D4A09C5103001E8E@XMB-BGL-416.cisco.com><618BE8B40039924EB9AED233D4A09C5103001EA3@XMB-BGL-416.cisco.com> From: "Ashish Dalela (adalela)" To: "Ping Pan" X-OriginalArrivalTime: 16 Feb 2012 16:28:29.0040 (UTC) FILETIME=[03ED4F00:01CCECC8] Cc: sop@ietf.org Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 16:28:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCECC8.03B8D3D5 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IA0KDQogDQoNCj4+IEJlIGNhcmVmdWwuIE90aGVycyBoYXZlIGJyb3VnaHQgdXAgc2ltaWxhciBw cm9wb3NhbCBiZWZvcmUuIElFVEYgc3RhbmRzIGZvciBJbnRlcm5ldCBFbmdpbmVlcmluZyBURi4u LiBOZXR3b3JraW5nIGlzIHRoZSBuYW1lIG9mIHRoZSBnYW1lLiA7LSkgSWYgbm90IG5ldHdvcmtp bmcsIEkgZmVhciBpdCB3b3VsZCBiZSB3cm9uZyBwbGFjZSB0byBkbyB0aGUgd29yay4NCg0KIA0K DQpUaGF0IEkgZGlzYWdyZWUgd2l0aCBiZWNhdXNlIEhUVFAsIFNJUCwgU01UUCwgU09BUCwgU05N UCBhcmUgYWxsIEw3IHByb3RvY29scy4gSSB3b25kZXIgaG93IG1hbnkgcGVvcGxlIGNhbGwgdGhh dCBuZXR3b3JraW5nIC4uIGJ1dCBpbiBhIHdheSB0aGV5IGFyZSBJbnRlcm5ldC4gQ2VydGFpbiB0 aGluZ3MgbGlrZSBTTk1QIGdvIGJleW9uZCBuZXR3b3Jrcy4gU09BUCBnb2VzIGV2ZW4gYmV5b25k IGluZnJhc3RydWN0dXJlLiBTTVRQIGlzIHRvdGFsbHkgYXBwbGljYXRpb24sIGFuZCBzbyBpcyBT SVAgYW5kIEhUVFAuDQoNCiANCg0KRGlkIHlvdSBzZWUgdGhlIGRyYWZ0cyB5ZXQ/IFRoZSByZXF1 aXJlbWVudCBkcmFmdCBoYXMgYSBzZWN0aW9uICDigJxJcyBDbG91ZCBDb250cm9sIGFuIEludGVy bmV0IFByb2JsZW0/4oCdLiBUaGUgaW50ZW50IG9mIHRoYXQgc2VjdGlvbiBpcyB0byBkZXNjcmli ZSB3aHkgSUVURiBpcyB0aGUgcGxhY2UgdG8gZG8gdGhpcyB3b3JrLg0KDQogDQoNClRoYW5rcywg QXNoaXNoDQoNCiANCg0KRnJvbTogc29wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzb3AtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBpbmcgUGFuDQpTZW50OiBUaHVyc2RheSwgRmVi cnVhcnkgMTYsIDIwMTIgOTo0OCBQTQ0KVG86IEFzaGlzaCBEYWxlbGEgKGFkYWxlbGEpDQpDYzog c29wQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NvcF0gW1NkbnBdIEZXOiBOZXcgTm9uLVdHIE1h aWxpbmcgTGlzdDogc29wIC0tIFNlcnZpY2UgT3JjaGVzdHJhdGlvbiBhbmQgRGVzY2lwdGlvbiBm b3IgQ2xvdWQgU2VydmljZXMNCg0KIA0KDQpPbiBUaHUsIEZlYiAxNiwgMjAxMiBhdCA4OjA5IEFN LCBBc2hpc2ggRGFsZWxhIChhZGFsZWxhKSA8YWRhbGVsYUBjaXNjby5jb20+IHdyb3RlOg0KDQpU aGlzIGlzbuKAmXQganVzdCBhYm91dCB0aGUgbmV0d29yayByZXNvdXJjZXMgYW5kIFNPUCBpc27i gJl0IG9ubHkgYWJvdXQgcHJvdmlzaW9uaW5nIG5ldHdvcmsgcmVzb3VyY2VzLiBUaGUgcHJvdG9j b2wgZGVmaW5pdGlvbiBpcyBnZW5lcmFsaXplZCB0byBzdXBwb3J0IGFueSBraW5kIG9mIHNlcnZp Y2Ug4oCTIG5ldHdvcmsgaW5jbHVkZWQuDQoNCiANCg0KQmUgY2FyZWZ1bC4gT3RoZXJzIGhhdmUg YnJvdWdodCB1cCBzaW1pbGFyIHByb3Bvc2FsIGJlZm9yZS4gSUVURiBzdGFuZHMgZm9yIEludGVy bmV0IEVuZ2luZWVyaW5nIFRGLi4uIE5ldHdvcmtpbmcgaXMgdGhlIG5hbWUgb2YgdGhlIGdhbWUu IDstKSBJZiBub3QgbmV0d29ya2luZywgSSBmZWFyIGl0IHdvdWxkIGJlIHdyb25nIHBsYWNlIHRv IGRvIHRoZSB3b3JrLg0KDQogDQoNCkluIFNETiwgb3VyIGZvY3VzIGlzIG9uIG5ldHdvcmtpbmcu IEZ1cnRoZXIsIHdlIGFyZSB0cnlpbmcgdG8gZGlzdGFuY2Ugb3Vyc2VsdmVzIGZyb20gdGhlIGFj dHVhbCBEQyBuZXR3b3JrIGZhYnJpYyBkZXNpZ24gKGFsbCB2ZW5kb3Itc3BlY2lmaWMgc28gZmFy KS4NCg0KIA0KDQpSZWdhcmRzLA0KDQogDQoNClBpbmcNCg0K ------_=_NextPart_001_01CCECC8.03B8D3D5 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj48aGVhZD48bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlw ZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj48c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAz IDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9 RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPiZndDsmZ3Q7IDwvc3Bhbj5CZSBjYXJlZnVsLiBPdGhlcnMgaGF2ZSBicm91Z2h0IHVw IHNpbWlsYXIgcHJvcG9zYWwgYmVmb3JlLiBJRVRGIHN0YW5kcyBmb3IgSW50ZXJuZXQgRW5naW5l ZXJpbmcgVEYuLi4gTmV0d29ya2luZyBpcyB0aGUgbmFtZSBvZiB0aGUgZ2FtZS4gOy0pIElmIG5v dCBuZXR3b3JraW5nLCBJIGZlYXIgaXQgd291bGQgYmUgd3JvbmcgcGxhY2UgdG8gZG8gdGhlIHdv cmsuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPlRoYXQgSSBkaXNhZ3JlZSB3aXRoIGJlY2F1c2UgSFRUUCwgU0lQLCBT TVRQLCBTT0FQLCBTTk1QIGFyZSBhbGwgTDcgcHJvdG9jb2xzLiBJIHdvbmRlciBob3cgbWFueSBw ZW9wbGUgY2FsbCB0aGF0IG5ldHdvcmtpbmcgLi4gYnV0IGluIGEgd2F5IHRoZXkgYXJlIEludGVy bmV0LiBDZXJ0YWluIHRoaW5ncyBsaWtlIFNOTVAgZ28gYmV5b25kIG5ldHdvcmtzLiBTT0FQIGdv ZXMgZXZlbiBiZXlvbmQgaW5mcmFzdHJ1Y3R1cmUuIFNNVFAgaXMgdG90YWxseSBhcHBsaWNhdGlv biwgYW5kIHNvIGlzIFNJUCBhbmQgSFRUUC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkRpZCB5b3Ugc2Vl IHRoZSBkcmFmdHMgeWV0PyBUaGUgcmVxdWlyZW1lbnQgZHJhZnQgaGFzIGEgc2VjdGlvbiDCoOKA nElzIENsb3VkIENvbnRyb2wgYW4gSW50ZXJuZXQgUHJvYmxlbT/igJ0uIFRoZSBpbnRlbnQgb2Yg dGhhdCBzZWN0aW9uIGlzIHRvIGRlc2NyaWJlIHdoeSBJRVRGIGlzIHRoZSBwbGFjZSB0byBkbyB0 aGlzIHdvcmsuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGFua3MsIEFzaGlzaDxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1z b05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBzb3AtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOnNvcC1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9i PlBpbmcgUGFuPGJyPjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRmVicnVhcnkgMTYsIDIwMTIgOTo0 OCBQTTxicj48Yj5Ubzo8L2I+IEFzaGlzaCBEYWxlbGEgKGFkYWxlbGEpPGJyPjxiPkNjOjwvYj4g c29wQGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW3NvcF0gW1NkbnBdIEZXOiBOZXcg Tm9uLVdHIE1haWxpbmcgTGlzdDogc29wIC0tIFNlcnZpY2UgT3JjaGVzdHJhdGlvbiBhbmQgRGVz Y2lwdGlvbiBmb3IgQ2xvdWQgU2VydmljZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPk9uIFRodSwgRmViIDE2LCAyMDEyIGF0IDg6MDkgQU0sIEFzaGlzaCBEYWxlbGEgKGFkYWxl bGEpICZsdDs8YSBocmVmPSJtYWlsdG86YWRhbGVsYUBjaXNjby5jb20iPmFkYWxlbGFAY2lzY28u Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPlRoaXMg aXNu4oCZdCBqdXN0IGFib3V0IHRoZSBuZXR3b3JrIHJlc291cmNlcyBhbmQgU09QIGlzbuKAmXQg b25seSBhYm91dCBwcm92aXNpb25pbmcgbmV0d29yayByZXNvdXJjZXMuIFRoZSBwcm90b2NvbCBk ZWZpbml0aW9uIGlzIGdlbmVyYWxpemVkIHRvIHN1cHBvcnQgYW55IGtpbmQgb2Ygc2VydmljZSDi gJMgbmV0d29yayBpbmNsdWRlZC48bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+QmUgY2FyZWZ1 bC4gT3RoZXJzIGhhdmUgYnJvdWdodCB1cCBzaW1pbGFyIHByb3Bvc2FsIGJlZm9yZS4gSUVURiBz dGFuZHMgZm9yIEludGVybmV0IEVuZ2luZWVyaW5nIFRGLi4uIE5ldHdvcmtpbmcgaXMgdGhlIG5h bWUgb2YgdGhlIGdhbWUuIDstKSBJZiBub3QgbmV0d29ya2luZywgSSBmZWFyIGl0IHdvdWxkIGJl IHdyb25nIHBsYWNlIHRvIGRvIHRoZSB3b3JrLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPkluIFNETiwgb3VyIGZvY3VzIGlzIG9uIG5ldHdvcmtpbmcuIEZ1cnRoZXIsIHdl IGFyZSB0cnlpbmcgdG8gZGlzdGFuY2UmbmJzcDtvdXJzZWx2ZXMmbmJzcDtmcm9tIHRoZSBhY3R1 YWwgREMgbmV0d29yayBmYWJyaWMgZGVzaWduIChhbGwgdmVuZG9yLXNwZWNpZmljIHNvIGZhciku PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+UmVnYXJkcyw8bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5QaW5nPG86cD48L286cD48L3A+PC9kaXY+PC9k aXY+PC9ib2R5PjwvaHRtbD4= ------_=_NextPart_001_01CCECC8.03B8D3D5-- From robert@raszuk.net Thu Feb 16 08:29:59 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D9F21F86C3 for ; Thu, 16 Feb 2012 08:29:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] 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 pVxyDqi8j76i for ; Thu, 16 Feb 2012 08:29:55 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 5651421F86A0 for ; Thu, 16 Feb 2012 08:29:55 -0800 (PST) Received: (qmail 31341 invoked by uid 399); 16 Feb 2012 16:29:54 -0000 Received: from unknown (HELO ?192.168.1.91?) (pbs:robert@raszuk.net@83.31.217.50) by mail1310.opentransfer.com with ESMTPM; 16 Feb 2012 16:29:54 -0000 X-Originating-IP: 83.31.217.50 Message-ID: <4F3D2F02.3020302@raszuk.net> Date: Thu, 16 Feb 2012 17:29:54 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Michael Hammer References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Nadeau , sdnp , Ping Pan , "Monique Morrow \(mmorrow\)" , sop@ietf.org, "Ashish Dalela \(adalela\)" Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 16:29:59 -0000 Hi Michael, > Cloud seems to be in the state the telephone company found itself 100 > years ago. Everything works fine so long as you do it Edison's way, or > Tesla's or whomever. We had to go through a monopoly state before > figuring out how to standardize. Looking to skip the monopoly phase > this time around. May be an interesting challenge especially since it seems that current cloud "monopoly phase" is an open source one ;) Best, R. From mphmmr@gmail.com Thu Feb 16 08:33:26 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27B621F8721 for ; Thu, 16 Feb 2012 08:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.985 X-Spam-Level: X-Spam-Status: No, score=-2.985 tagged_above=-999 required=5 tests=[AWL=0.613, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 gUYJ662A4DXq for ; Thu, 16 Feb 2012 08:33:26 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 73EE621F85A0 for ; Thu, 16 Feb 2012 08:33:24 -0800 (PST) Received: by lahl5 with SMTP id l5so3039654lah.31 for ; Thu, 16 Feb 2012 08:33:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mY7FROW0klbHmY0f2Pju4I18o8f/RcSxe3X1jmhpTdY=; b=lrsHJxQYTtM6YEQ6F8EmhzbLbkGcOH8Ff+/5B6qmHkdpZBotsOvP519nF3vfM7uBZt DNtD4ynqUOhU9B6kVR8fAej1JRzY5gK8k51TZdhoSC20S3FAuAlGUSMZY/ptzFbSZCzi qRAmY/gRMhvQYZTRD2vMXuTFNThF+7PeGQXts= MIME-Version: 1.0 Received: by 10.152.104.143 with SMTP id ge15mr2501354lab.26.1329410003922; Thu, 16 Feb 2012 08:33:23 -0800 (PST) Received: by 10.112.104.70 with HTTP; Thu, 16 Feb 2012 08:33:23 -0800 (PST) In-Reply-To: <4F3D2F02.3020302@raszuk.net> References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> <4F3D2F02.3020302@raszuk.net> Date: Thu, 16 Feb 2012 11:33:23 -0500 Message-ID: From: Michael Hammer To: robert@raszuk.net Content-Type: multipart/alternative; boundary=f46d040838ff0b6de504b91763c8 Cc: Thomas Nadeau , sdnp , Ping Pan , "Monique Morrow \(mmorrow\)" , sop@ietf.org, "Ashish Dalela \(adalela\)" Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 16:33:27 -0000 --f46d040838ff0b6de504b91763c8 Content-Type: text/plain; charset=ISO-8859-1 Yeah, except open source does not necessarily mean standardized. Whose open source project are we talking about? :) Mike On Thu, Feb 16, 2012 at 11:29 AM, Robert Raszuk wrote: > Hi Michael, > > > Cloud seems to be in the state the telephone company found itself 100 >> years ago. Everything works fine so long as you do it Edison's way, or >> Tesla's or whomever. We had to go through a monopoly state before >> figuring out how to standardize. Looking to skip the monopoly phase >> this time around. >> > > May be an interesting challenge especially since it seems that current > cloud "monopoly phase" is an open source one ;) > > Best, > R. > > --f46d040838ff0b6de504b91763c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yeah, except open source does not necessarily mean standardized.

Whose open source project are we talking about? =A0:)
Mike


On Thu, Feb = 16, 2012 at 11:29 AM, Robert Raszuk <robert@raszuk.net> wrote:
Hi Michael,


Cloud seems to be in the state the telephone company found itself 100
years ago. =A0Everything works fine so long as you do it Edison's way, = or
Tesla's or whomever. =A0We had to go through a monopoly state before figuring out how to standardize. =A0Looking to skip the monopoly phase
this time around.

May be an interesting challenge especially since it seems that current clou= d "monopoly phase" is an open source one ;)

Best,
R.


--f46d040838ff0b6de504b91763c8-- From tnadeau@lucidvision.com Thu Feb 16 08:36:55 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADC021F87D6 for ; Thu, 16 Feb 2012 08:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 SRZBXjxoME1Y for ; Thu, 16 Feb 2012 08:36:51 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id C96AC21F87D7 for ; Thu, 16 Feb 2012 08:36:50 -0800 (PST) Received: from [192.168.1.94] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 42ACF208DF12; Thu, 16 Feb 2012 11:36:50 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_C6BA56C5-1993-444E-947D-5BA2018EC108" From: Thomas Nadeau In-Reply-To: Date: Thu, 16 Feb 2012 11:36:44 -0500 Message-Id: <8BEA2A9F-98D2-4828-BD68-5D980BD81EFE@lucidvision.com> References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C5103001E8E@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C5103001EA3@XMB-BGL-416.cisco.com> To: Ping Pan X-Mailer: Apple Mail (2.1257) Cc: sop@ietf.org, "Ashish Dalela \(adalela\)" Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 16:36:55 -0000 --Apple-Mail=_C6BA56C5-1993-444E-947D-5BA2018EC108 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Good point Ping. That is the question in my mind. Does this = belong somewhere else like where OpenStack is being done, or otherwise? --Tom =09 On Feb 16, 2012, at 11:17 AM, Ping Pan wrote: > On Thu, Feb 16, 2012 at 8:09 AM, Ashish Dalela (adalela) = wrote: > This isn=92t just about the network resources and SOP isn=92t only = about provisioning network resources. The protocol definition is = generalized to support any kind of service =96 network included. >=20 > Be careful. Others have brought up similar proposal before. IETF = stands for Internet Engineering TF... Networking is the name of the = game. ;-) If not networking, I fear it would be wrong place to do the = work. >=20 > In SDN, our focus is on networking. Further, we are trying to distance = ourselves from the actual DC network fabric design (all vendor-specific = so far). >=20 > Regards, >=20 > Ping > _______________________________________________ > sop mailing list > sop@ietf.org > https://www.ietf.org/mailman/listinfo/sop --Apple-Mail=_C6BA56C5-1993-444E-947D-5BA2018EC108 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 = Good point Ping. That is the question in my mind. = Does this belong somewhere else like where OpenStack is being done, or = otherwise?

= --Tom


On Feb = 16, 2012, at 11:17 AM, Ping Pan wrote:

On Thu, Feb 16, 2012 at 8:09 AM, Ashish Dalela = (adalela) <adalela@cisco.com> = wrote:
This isn=92t just about the network resources and SOP isn=92t only about = provisioning network resources. The protocol definition is generalized = to support any kind of service =96 network = included.

Be careful. Others have brought up = similar proposal before. IETF stands for Internet Engineering TF... = Networking is the name of the game. ;-) If not networking, I fear it = would be wrong place to do the work.

In SDN, our focus is on networking. Further, we are = trying to distance ourselves from the actual DC network fabric = design (all vendor-specific so = far).

Regards,

Ping
_______________________________________________
sop mailing = list
sop@ietf.org
https://www.ietf.org/mail= man/listinfo/sop

= --Apple-Mail=_C6BA56C5-1993-444E-947D-5BA2018EC108-- From adalela@cisco.com Thu Feb 16 08:46:40 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D6A21F883A for ; Thu, 16 Feb 2012 08:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.833 X-Spam-Level: X-Spam-Status: No, score=-6.833 tagged_above=-999 required=5 tests=[AWL=3.765, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 pQjYHvlRBkoz for ; Thu, 16 Feb 2012 08:46:35 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7495521F8827 for ; Thu, 16 Feb 2012 08:46:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=10638; q=dns/txt; s=iport; t=1329410793; x=1330620393; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=W/EnkCe4MmzGP+avzS/3TPbUANxpCi3mcP0eKOBimvc=; b=AwjyLwFZAp9R9GhXZ8WQ7g5/n0snv1b9/vGU8UyhDrw6HLrx9nKLE4ZK fnVHiRxwVHUVDenCsgfM8aRLeGC+MEtCMoHJsLa06sdccd7wtnH3p7N46 tavK5Oyk88u5hn5HInXITAq+qi5k8oM467M5u5c6YHCiNGVObPskGem+J w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAGcyPU9Io8UY/2dsb2JhbABEgk2lTwGJTYFyAQEBBAEBAQ8BCREDPgsQAgEIDgMEAQELBhMEAQYBJh8IAQgBAQQBCggIGodmmjUBnk+LcAIEWBEJAoNjAQkGEQIDAgUCBwQFAguCR2MEiEyfWw X-IronPort-AV: E=Sophos;i="4.73,430,1325462400"; d="scan'208,217";a="5729247" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 16 Feb 2012 16:46:31 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1GGkVSS030567; Thu, 16 Feb 2012 16:46:31 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Feb 2012 22:16:31 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCECCA.88F360BF" Date: Thu, 16 Feb 2012 22:16:30 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C5103001ECD@XMB-BGL-416.cisco.com> In-Reply-To: <8BEA2A9F-98D2-4828-BD68-5D980BD81EFE@lucidvision.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services Thread-Index: AczsyTH9hFrlVcJ9RSiG8WV+bdtLpgAAP5SA References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C5103001E8E@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C5103001EA3@XMB-BGL-416.cisco.com> <8BEA2A9F-98D2-4828-BD68-5D980BD81EFE@lucidvision.com> From: "Ashish Dalela (adalela)" To: "Thomas Nadeau" , "Ping Pan" X-OriginalArrivalTime: 16 Feb 2012 16:46:31.0585 (UTC) FILETIME=[892C9110:01CCECCA] Cc: sop@ietf.org Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 16:46:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCECCA.88F360BF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 That point is discussed in the draft - http://tools.ietf.org/html/draft-dalela-orchestration-00#section-5 =20 Thanks, Ashish =20 =20 From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]=20 Sent: Thursday, February 16, 2012 10:07 PM To: Ping Pan Cc: Ashish Dalela (adalela); sop@ietf.org Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services =20 =20 Good point Ping. That is the question in my mind. Does this belong somewhere else like where OpenStack is being done, or otherwise? =20 --Tom =20 =20 =20 On Feb 16, 2012, at 11:17 AM, Ping Pan wrote: On Thu, Feb 16, 2012 at 8:09 AM, Ashish Dalela (adalela) wrote: This isn't just about the network resources and SOP isn't only about provisioning network resources. The protocol definition is generalized to support any kind of service - network included. =20 Be careful. Others have brought up similar proposal before. IETF stands for Internet Engineering TF... Networking is the name of the game. ;-) If not networking, I fear it would be wrong place to do the work. =20 In SDN, our focus is on networking. Further, we are trying to distance ourselves from the actual DC network fabric design (all vendor-specific so far). =20 Regards, =20 Ping _______________________________________________ sop mailing list sop@ietf.org https://www.ietf.org/mailman/listinfo/sop =20 ------_=_NextPart_001_01CCECCA.88F360BF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

That point is discussed in the draft - http://tools.ietf.org/html/draft-dalela-orchestration-00#section-5=

 

Thanks, Ashish

 

 

From:= = Thomas Nadeau [mailto:tnadeau@lucidvision.com]
Sent: = Thursday, February 16, 2012 10:07 PM
To: Ping = Pan
Cc: Ashish Dalela (adalela); = sop@ietf.org
Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing = List: sop -- Service Orchestration and Desciption for Cloud = Services

 

 

        &n= bsp;   Good point Ping. That is the question in my = mind. Does this belong somewhere else like where OpenStack is being = done, or otherwise?

 

        &n= bsp;   --Tom

 

        &n= bsp;  

 

On = Feb 16, 2012, at 11:17 AM, Ping Pan wrote:



On = Thu, Feb 16, 2012 at 8:09 AM, Ashish Dalela (adalela) <adalela@cisco.com> = wrote:

This isn’t just about = the network resources and SOP isn’t only about provisioning = network resources. The protocol definition is generalized to support any = kind of service – network included.

 

Be = careful. Others have brought up similar proposal before. IETF stands for = Internet Engineering TF... Networking is the name of the game. ;-) If = not networking, I fear it would be wrong place to do the = work.

 

In SDN, our focus is on networking. Further, we are = trying to distance ourselves from the actual DC network fabric = design (all vendor-specific so far).

 

Regards,

 

Ping

_______________________________________________
sop = mailing list
sop@ietf.org
https://www.ietf.org/mai= lman/listinfo/sop

 

------_=_NextPart_001_01CCECCA.88F360BF-- From mphmmr@gmail.com Thu Feb 16 08:48:02 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66FD821F841B for ; Thu, 16 Feb 2012 08:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.108 X-Spam-Level: X-Spam-Status: No, score=-3.108 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 YuLsfzgs9+bb for ; Thu, 16 Feb 2012 08:47:58 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D575A21F8565 for ; Thu, 16 Feb 2012 08:47:44 -0800 (PST) Received: by lahl5 with SMTP id l5so3058037lah.31 for ; Thu, 16 Feb 2012 08:47:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IPdXG/rKzBsdhsvW/eqKumf4K9lFCzncBV3b9SF9f2A=; b=aTqHqX7rAvd3KWxCwvJRziZAqJ8nnW3Pdmp1SN0wRsjlM2/mcYUnTy16CuIAktmlPa aVNM7SuNqHI7iFGypuMr9IE9/ZwCAw7YttLLMkqNX8zjAZDu1WpGNqszqNpNiyrV8umw GkqolkYgctIV4t4MmihysOdftk2xXAW8rixWI= MIME-Version: 1.0 Received: by 10.152.104.143 with SMTP id ge15mr2569698lab.26.1329410863725; Thu, 16 Feb 2012 08:47:43 -0800 (PST) Received: by 10.112.104.70 with HTTP; Thu, 16 Feb 2012 08:47:43 -0800 (PST) In-Reply-To: <8BEA2A9F-98D2-4828-BD68-5D980BD81EFE@lucidvision.com> References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C5103001E8E@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C5103001EA3@XMB-BGL-416.cisco.com> <8BEA2A9F-98D2-4828-BD68-5D980BD81EFE@lucidvision.com> Date: Thu, 16 Feb 2012 11:47:43 -0500 Message-ID: From: Michael Hammer To: Thomas Nadeau Content-Type: multipart/alternative; boundary=f46d040838ff4afc0304b91796cc Cc: sop@ietf.org, Ping Pan , "Ashish Dalela \(adalela\)" Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 16:48:02 -0000 --f46d040838ff4afc0304b91796cc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable For interoperability's sake across private and public clouds from different network providers, we are looking for a protocol to be developed. The analogy we are making is that on-demand provisioning of a voice/video network circuit between two points is done with SIP. Without interferring with that effort, and working in parallel, what is the difference with the on-demand provisioning of network/compute/storage over IP? Would you also argue that all the SIP work should not have been done in IETF? Or that SIP should not have been done because there are open-source projects? Mike On Thu, Feb 16, 2012 at 11:36 AM, Thomas Nadeau wr= ote: > > Good point Ping. That is the question in my mind. Does this belong > somewhere else like where OpenStack is being done, or otherwise? > > --Tom > > > On Feb 16, 2012, at 11:17 AM, Ping Pan wrote: > > On Thu, Feb 16, 2012 at 8:09 AM, Ashish Dalela (adalela) < > adalela@cisco.com> wrote: > >> This isn=92t just about the network resources and SOP isn=92t only about >> provisioning network resources. The protocol definition is generalized t= o >> support any kind of service =96 network included. > > > Be careful. Others have brought up similar proposal before. IETF stands > for Internet Engineering TF... Networking is the name of the game. ;-) If > not networking, I fear it would be wrong place to do the work. > > In SDN, our focus is on networking. Further, we are trying to > distance ourselves from the actual DC network fabric design (all > vendor-specific so far). > > Regards, > > Ping > _______________________________________________ > sop mailing list > sop@ietf.org > https://www.ietf.org/mailman/listinfo/sop > > > > _______________________________________________ > sop mailing list > sop@ietf.org > https://www.ietf.org/mailman/listinfo/sop > > --f46d040838ff4afc0304b91796cc Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable For interoperability's sake across private and public clouds from diffe= rent network providers, we are looking for a protocol to be developed.
=
The analogy we are making is that on-demand provisioning of = a voice/video =A0network circuit between two points is done with SIP. =A0Wi= thout interferring with that effort, and working in parallel, what is the d= ifference with the on-demand provisioning of network/compute/storage over I= P?

Would you also argue that all the SIP work should not h= ave been done in IETF?
Or that SIP should not have been done beca= use there are open-source projects?

Mike


On Thu, Feb 16, 2012 at 11:36 AM, T= homas Nadeau <tnadeau@lucidvision.com> wrote:

Good point Ping.=A0That is the question in my mind. Do= es this belong somewhere else like where OpenStack is being done, or otherw= ise?

--Tom

On Feb 16, 2012, at 11:17 AM, Ping Pan wr= ote:

On Thu, Feb 16, 2012 at 8:09 AM, Ashish Dalela (adalela) <= span dir=3D"ltr"><adalela@cisco.com> wrote:
This isn=92t just about the network resources and SOP isn=92t only about pr= ovisioning network resources. The protocol definition is generalized to sup= port any kind of service =96 network included.

B= e careful. Others have brought up similar proposal before. IETF stands for = Internet Engineering TF... Networking is the name of the game. ;-) If not n= etworking, I fear it would be wrong place to do the work.

In SDN, our focus is on networking. Further, we are try= ing to distance=A0ourselves=A0from the actual DC network fabric design (all= vendor-specific so far).

Regards,

Ping
_______________________________________________
sop mailing list
sop@ietf.org
https://ww= w.ietf.org/mailman/listinfo/sop


______________________________= _________________
sop mailing list
sop@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sop


--f46d040838ff4afc0304b91796cc-- From robert@raszuk.net Thu Feb 16 08:48:40 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D668721F87D5 for ; Thu, 16 Feb 2012 08:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] 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 IR34ygAQKSpU for ; Thu, 16 Feb 2012 08:48:35 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4D521F87EC for ; Thu, 16 Feb 2012 08:48:33 -0800 (PST) Received: (qmail 15541 invoked by uid 399); 16 Feb 2012 16:48:33 -0000 Received: from unknown (HELO ?192.168.1.91?) (pbs:robert@raszuk.net@83.31.217.50) by mail1310.opentransfer.com with ESMTPM; 16 Feb 2012 16:48:33 -0000 X-Originating-IP: 83.31.217.50 Message-ID: <4F3D3361.4030802@raszuk.net> Date: Thu, 16 Feb 2012 17:48:33 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Michael Hammer References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> <4F3D2F02.3020302@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Nadeau , sdnp , Ping Pan , "Monique Morrow \(mmorrow\)" , sop@ietf.org, "Ashish Dalela \(adalela\)" Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 16:48:41 -0000 > Yeah, except open source does not necessarily mean standardized. Well history shows that "standardized" usually get's influenced by commercialization very quickly and turns into major vendor's battlefield. Is having two IGPs blessed by IETF as standard a feature or a bug ? Is having N ways to accomplish L2VPNs where major vendors do not interoperate something we would admire as great success of standardization process ? Or IPv6 "progress". I don't know ... > Whose open source project are we talking about? :) http://openstack.org/community/companies/ http://www.eclipse.org/membership/showAllMembers.php Cheers, R. From mphmmr@gmail.com Thu Feb 16 08:58:43 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245C721F887B for ; Thu, 16 Feb 2012 08:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Z+XMc2vbAZTY for ; Thu, 16 Feb 2012 08:58:38 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E0E3721F8845 for ; Thu, 16 Feb 2012 08:58:37 -0800 (PST) Received: by lahl5 with SMTP id l5so3070714lah.31 for ; Thu, 16 Feb 2012 08:58:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ig0gfA4+wsLaIDpeSh7NKuUVl1S3fHM/CMVddxPdA8Q=; b=aU6qupz+5CWd49rqa4CxNvopm1Id+Ud3/ACwshAbM0tsO84GAG+w682q9yp5E0X4dg jzMU8o+gLj2sp3z696kMb+sFsk6uRwTk7QXfSJ4N8h7KHwDxTt1zPCR/ir4yKIw8+uAw 2E9NEalDRypbAQMyZyjRbXkezQRsFHEDBKJJU= MIME-Version: 1.0 Received: by 10.112.100.34 with SMTP id ev2mr1315100lbb.13.1329411516876; Thu, 16 Feb 2012 08:58:36 -0800 (PST) Received: by 10.112.104.70 with HTTP; Thu, 16 Feb 2012 08:58:36 -0800 (PST) In-Reply-To: <4F3D3361.4030802@raszuk.net> References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> <4F3D2F02.3020302@raszuk.net> <4F3D3361.4030802@raszuk.net> Date: Thu, 16 Feb 2012 11:58:36 -0500 Message-ID: From: Michael Hammer To: robert@raszuk.net Content-Type: multipart/alternative; boundary=14dae9d2f3ca3947f704b917bdb0 Cc: Thomas Nadeau , sdnp , Ping Pan , "Monique Morrow \(mmorrow\)" , sop@ietf.org, "Ashish Dalela \(adalela\)" Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 16:58:43 -0000 --14dae9d2f3ca3947f704b917bdb0 Content-Type: text/plain; charset=ISO-8859-1 Robert, And that is the *only* open source project? :) Yeah, having more than one standard is an issue as well. Would hope that we could converge early on one, but the IETF is what it is. But that is not an argument against trying, or you might as well shut down any effort. Mike On Thu, Feb 16, 2012 at 11:48 AM, Robert Raszuk wrote: > > Yeah, except open source does not necessarily mean standardized. >> > > Well history shows that "standardized" usually get's influenced by > commercialization very quickly and turns into major vendor's battlefield. > > Is having two IGPs blessed by IETF as standard a feature or a bug ? Is > having N ways to accomplish L2VPNs where major vendors do not interoperate > something we would admire as great success of standardization process ? Or > IPv6 "progress". I don't know ... > > > Whose open source project are we talking about? :) >> > > http://openstack.org/**community/companies/ > http://www.eclipse.org/**membership/showAllMembers.php > > Cheers, > R. > --14dae9d2f3ca3947f704b917bdb0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Robert,

And that is the *only* open source project? =A0:= )

Yeah, having more than one standard is an issue = as well.
Would hope that we could converge early on one, but the = IETF is what it is.
But that is not an argument against trying, or you might as well shut = down any effort.

Mike


On Thu, Feb 16, 2012 at 11:48 AM, Robert Raszuk <robert@raszuk.net>= wrote:

Yeah, except open source does not necessarily mean standardized.

Well history shows that "standardized" usually get's influenc= ed by commercialization very quickly and turns into major vendor's batt= lefield.

Is having two IGPs blessed by IETF as standard a feature or a bug ? Is havi= ng N ways to accomplish L2VPNs where major vendors do not interoperate some= thing we would admire as great success of standardization process ? Or IPv6= "progress". I don't know ...


Whose open source project are we talking about? =A0:)

http://openstack.org/community/companies/
http://www.eclipse.org/membership/showAllMembers.php

Cheers,
R.

--14dae9d2f3ca3947f704b917bdb0-- From ping@pingpan.org Thu Feb 16 09:03:50 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5803121F8883 for ; Thu, 16 Feb 2012 09:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.676 X-Spam-Level: X-Spam-Status: No, score=-5.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4] 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 Kq23l+p5OwRH for ; Thu, 16 Feb 2012 09:03:46 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with SMTP id B643021F8864 for ; Thu, 16 Feb 2012 09:03:44 -0800 (PST) Received: from mail-tul01m020-f182.google.com ([209.85.214.182]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTz0270h3JSXVvqAnGRgIIgthYfVnuhjl@postini.com; Thu, 16 Feb 2012 09:03:44 PST Received: by obcwo16 with SMTP id wo16so5586262obc.27 for ; Thu, 16 Feb 2012 09:03:43 -0800 (PST) Received: by 10.182.162.40 with SMTP id xx8mr2500415obb.17.1329411823283; Thu, 16 Feb 2012 09:03:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.80.200 with HTTP; Thu, 16 Feb 2012 09:03:02 -0800 (PST) In-Reply-To: References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C5103001E8E@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C5103001EA3@XMB-BGL-416.cisco.com> <8BEA2A9F-98D2-4828-BD68-5D980BD81EFE@lucidvision.com> From: Ping Pan Date: Thu, 16 Feb 2012 09:03:02 -0800 Message-ID: To: Michael Hammer Content-Type: multipart/alternative; boundary=e89a8f6431487cae2e04b917cf4f X-Gm-Message-State: ALoCoQmNxs1+3KNr4S92vMB5ihXAFGE8hudjwWS6YaxyV+fHariujyLY2T9080PelgB/bRJtEiKk Cc: Thomas Nadeau , sop@ietf.org, "Ashish Dalela \(adalela\)" Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 17:03:50 -0000 --e89a8f6431487cae2e04b917cf4f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There are two issues here: 1. Open standard vs.open source code: we can argue all we want, OpenStack/OpenFlow/OpenvSwitch/Hadoop/EC2 are making real impact. IMHO, any standard without tight-coupling to the running implementation is nothing but a waste of time - may that be open or close standard. Standards would help the deployment of the technology, but it's the open source code that has been the front runner in cloud computing. You have mentioned SIP and IETF. During the same period of time Skype was also around. It's not open source code, but free application. At the end of the day, can anyone argue Skype is making less impact on VoIP because there is no proper standardization? My point is, let's not put standard and running code on the opposite side of a scale. Standard can only benefit from the running code. 2. Layering: IP networking runs on many layers. My point was that anything to do with IP networking would be investigated and worked on in IETF. But the non-networking application should not. If we are to support scalable filesystems in data centers, such as HDFS, should that be standardized in IETF? Regards, Ping On Thu, Feb 16, 2012 at 8:47 AM, Michael Hammer wrote: > For interoperability's sake across private and public clouds from > different network providers, we are looking for a protocol to be develope= d. > > The analogy we are making is that on-demand provisioning of a voice/video > network circuit between two points is done with SIP. Without interferri= ng > with that effort, and working in parallel, what is the difference with th= e > on-demand provisioning of network/compute/storage over IP? > > Would you also argue that all the SIP work should not have been done in > IETF? > Or that SIP should not have been done because there are open-source > projects? > > Mike > > > On Thu, Feb 16, 2012 at 11:36 AM, Thomas Nadeau = wrote: > >> >> Good point Ping. That is the question in my mind. Does this belong >> somewhere else like where OpenStack is being done, or otherwise? >> >> --Tom >> >> >> On Feb 16, 2012, at 11:17 AM, Ping Pan wrote: >> >> On Thu, Feb 16, 2012 at 8:09 AM, Ashish Dalela (adalela) < >> adalela@cisco.com> wrote: >> >>> This isn=E2=80=99t just about the network resources and SOP isn=E2=80= =99t only about >>> provisioning network resources. The protocol definition is generalized = to >>> support any kind of service =E2=80=93 network included. >> >> >> Be careful. Others have brought up similar proposal before. IETF stands >> for Internet Engineering TF... Networking is the name of the game. ;-) I= f >> not networking, I fear it would be wrong place to do the work. >> >> In SDN, our focus is on networking. Further, we are trying to >> distance ourselves from the actual DC network fabric design (all >> vendor-specific so far). >> >> Regards, >> >> Ping >> _______________________________________________ >> sop mailing list >> sop@ietf.org >> https://www.ietf.org/mailman/listinfo/sop >> >> >> >> _______________________________________________ >> sop mailing list >> sop@ietf.org >> https://www.ietf.org/mailman/listinfo/sop >> >> > --e89a8f6431487cae2e04b917cf4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There are two issues here:

1. Open standard vs.open sour= ce code: we can argue all we want, OpenStack/OpenFlow/OpenvSwitch/Hadoop/EC= 2 are making real impact. IMHO, any standard without tight-coupling to the = running=C2=A0implementation=C2=A0is nothing but a waste of time - may that = be open or close standard. Standards would help the deployment of the techn= ology, but it's the open source code that has been the front runner in = cloud computing.

You have mentioned SIP and IETF. During the same period= of time Skype was also around. It's not open source code, but free app= lication. At the end of the day, can anyone argue Skype=C2=A0is making less= impact on VoIP because there is no proper standardization? My point is, le= t's not put standard and running code on the opposite side of a scale. = Standard can only benefit from the running code.

2. Layering: IP networking runs on many layers. My poin= t was that anything to do with IP networking would be investigated and work= ed on in IETF. But the non-networking application should not. If we are to = support scalable filesystems in data centers, such as HDFS, should that be = standardized in IETF?

Regards,

Ping


On Thu, Feb 16, 2012 at 8:47 AM, Michael = Hammer <mphmmr@gma= il.com> wrote:
For interoperability's sake across priva= te and public clouds from different network providers, we are looking for a= protocol to be developed.

The analogy we are making is that on-demand provisioning of = a voice/video =C2=A0network circuit between two points is done with SIP. = =C2=A0Without interferring with that effort, and working in parallel, what = is the difference with the on-demand provisioning of network/compute/storag= e over IP?

Would you also argue that all the SIP work should not h= ave been done in IETF?
Or that SIP should not have been done beca= use there are open-source projects?

Mike


On Thu, Feb 16, 2012 at 11:36 AM, T= homas Nadeau <tnadeau@lucidvision.com> wrote:

Good point Ping.=C2=A0That is the question in my mind.= Does this belong somewhere else like where OpenStack is being done, or oth= erwise?

--Tom

On Feb 16, 2012, at 11:17 AM, Ping Pan wrote:

On Thu, Feb 16, 2012 at 8:09 AM, Ashish Dalela (adalela) <adalela@cisc= o.com> wrote:
This isn=E2=80=99t just about the network resources and SOP isn=E2=80=99t o= nly about provisioning network resources. The protocol definition is genera= lized to support any kind of service =E2=80=93 network included.

Be careful. Others have brought up similar proposal before= . IETF stands for Internet Engineering TF... Networking is the name of the = game. ;-) If not networking, I fear it would be wrong place to do the work.=

In SDN, our focus is on networking. Further, we are try= ing to distance=C2=A0ourselves=C2=A0from the actual DC network fabric desig= n (all vendor-specific so far).

Regards,

Ping
_______________________________________________
sop mailing list
sop@ietf.org
https://ww= w.ietf.org/mailman/listinfo/sop


______________________________= _________________
sop mailing list
sop@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sop



--e89a8f6431487cae2e04b917cf4f-- From tnadeau@lucidvision.com Thu Feb 16 09:04:10 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57A021F885F for ; Thu, 16 Feb 2012 09:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 zB+s5IFayz0o for ; Thu, 16 Feb 2012 09:04:06 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id AAF3921F8864 for ; Thu, 16 Feb 2012 09:04:06 -0800 (PST) Received: from [192.168.1.94] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 301C7208E0F0; Thu, 16 Feb 2012 12:04:06 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_BDB191F1-1F98-4F06-8BAD-2111ECAF3FC3" From: Thomas Nadeau In-Reply-To: Date: Thu, 16 Feb 2012 12:04:05 -0500 Message-Id: <6EDB11CC-228B-4C1A-90F8-37E311D31878@lucidvision.com> References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C5103001E8E@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C5103001EA3@XMB-BGL-416.cisco.com> <8BEA2A9F-98D2-4828-BD68-5D980BD81EFE@lucidvision.com> To: Michael Hammer X-Mailer: Apple Mail (2.1257) Cc: sop@ietf.org, Ping Pan , "Ashish Dalela \(adalela\)" Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 17:04:11 -0000 --Apple-Mail=_BDB191F1-1F98-4F06-8BAD-2111ECAF3FC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Feb 16, 2012, at 11:47 AM, Michael Hammer wrote: > For interoperability's sake across private and public clouds from = different network providers, we are looking for a protocol to be = developed. Is this a service provider requirement or one from equipment = vendors? > The analogy we are making is that on-demand provisioning of a = voice/video network circuit between two points is done with SIP. = Without interferring with that effort, and working in parallel, what is = the difference with the on-demand provisioning of = network/compute/storage over IP? >=20 > Would you also argue that all the SIP work should not have been done = in IETF? > Or that SIP should not have been done because there are open-source = projects? I am not arguing either way; I was asking the question to the = wider audience. --Tom >=20 > Mike >=20 >=20 > On Thu, Feb 16, 2012 at 11:36 AM, Thomas Nadeau = wrote: >=20 > Good point Ping. That is the question in my mind. Does this = belong somewhere else like where OpenStack is being done, or otherwise? >=20 > --Tom >=20 > =09 >=20 > On Feb 16, 2012, at 11:17 AM, Ping Pan wrote: >=20 >> On Thu, Feb 16, 2012 at 8:09 AM, Ashish Dalela (adalela) = wrote: >> This isn=92t just about the network resources and SOP isn=92t only = about provisioning network resources. The protocol definition is = generalized to support any kind of service =96 network included. >>=20 >> Be careful. Others have brought up similar proposal before. IETF = stands for Internet Engineering TF... Networking is the name of the = game. ;-) If not networking, I fear it would be wrong place to do the = work. >>=20 >> In SDN, our focus is on networking. Further, we are trying to = distance ourselves from the actual DC network fabric design (all = vendor-specific so far). >>=20 >> Regards, >>=20 >> Ping >> _______________________________________________ >> sop mailing list >> sop@ietf.org >> https://www.ietf.org/mailman/listinfo/sop >=20 >=20 > _______________________________________________ > sop mailing list > sop@ietf.org > https://www.ietf.org/mailman/listinfo/sop >=20 >=20 --Apple-Mail=_BDB191F1-1F98-4F06-8BAD-2111ECAF3FC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
For interoperability's sake across private and public = clouds from different network providers, we are looking for a protocol = to be developed.

Is this a service provider = requirement or one from equipment vendors?

The analogy we are making is that on-demand = provisioning of a voice/video  network circuit between two points = is done with SIP.  Without interferring with that effort, and = working in parallel, what is the difference with the on-demand = provisioning of network/compute/storage over IP?

Would you also argue that all the SIP work should = not have been done in IETF?
Or that SIP should not have been = done because there are open-source = projects?

I am not arguing either way; I = was asking the question to the wider = audience.

= --Tom



Mike


On Thu, Feb 16, 2012 at 11:36 = AM, Thomas Nadeau <tnadeau@lucidvision.com> wrote:

Good point Ping. That is the = question in my mind. Does this belong somewhere else like where = OpenStack is being done, or otherwise?

= --Tom


On Feb 16, 2012, at 11:17 AM, Ping Pan wrote:

On Thu, Feb 16, 2012 at 8:09 AM, Ashish Dalela = (adalela) <adalela@cisco.com> wrote:
This isn=92t just about the network resources and SOP isn=92t only about = provisioning network resources. The protocol definition is generalized = to support any kind of service =96 network = included.

Be careful. Others have brought up = similar proposal before. IETF stands for Internet Engineering TF... = Networking is the name of the game. ;-) If not networking, I fear it = would be wrong place to do the work.

In SDN, our focus is on networking. Further, we are = trying to distance ourselves from the actual DC network fabric = design (all vendor-specific so = far).

Regards,

Ping
_______________________________________________
sop mailing = list
sop@ietf.org
https://www.ietf.org/mailman/listinfo/sop
=


_____________________________= __________________
sop mailing list
sop@ietf.org
https://www.ietf.org/mailman/listinfo/sop



= --Apple-Mail=_BDB191F1-1F98-4F06-8BAD-2111ECAF3FC3-- From adalela@cisco.com Thu Feb 16 09:09:55 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A34221F8891 for ; Thu, 16 Feb 2012 09:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.949 X-Spam-Level: X-Spam-Status: No, score=-6.949 tagged_above=-999 required=5 tests=[AWL=3.649, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 iTdYZjHnHrxo for ; Thu, 16 Feb 2012 09:09:51 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 28D7621F87D4 for ; Thu, 16 Feb 2012 09:09:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=15885; q=dns/txt; s=iport; t=1329412188; x=1330621788; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=5Lc+WC84to0ch0cgsll6KHQs6+kDfWABTVimczyGxVA=; b=Bhg8lD8UjGM6rdlQ90jil7ukHyvr/J/1FSLjIQkgyU1w1+r8SW3Hvtv2 Xr+bau0+EeMDiSxdR4v5meCPq64bIw6bqUvSeS/AKgKOenrzxf3MpfRfg LrGYnvuscF7I+FIzvXHyGVWUqzjcolgdn/9Q5+IFiVlo/9Q3nOQtxyRe6 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFABk3PU9Io8UY/2dsb2JhbABDglGlTwGJTYFyAQEBBAEBAQ8BCREDPgQHEAIBCA4DBAEBCwYTBAEGASYfCAEIAQEEAQoICBqHZp8TAZZoi24CAgQUAQUJNRGDbgEJBhgFAgcEBQILgkdjBIhMn1s X-IronPort-AV: E=Sophos;i="4.73,430,1325462400"; d="scan'208,217";a="5730395" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 16 Feb 2012 17:09:46 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1GH9jKQ006738; Thu, 16 Feb 2012 17:09:45 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Feb 2012 22:39:45 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCECCD.C7FB377D" Date: Thu, 16 Feb 2012 22:39:44 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C5103001EEE@XMB-BGL-416.cisco.com> In-Reply-To: <6EDB11CC-228B-4C1A-90F8-37E311D31878@lucidvision.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- ServiceOrchestration and Desciption for Cloud Services Thread-Index: AczszQUBYlg39lZITcWs/++0DZJXRQAAFZvw References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com><618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com><618BE8B40039924EB9AED233D4A09C5103001E8E@XMB-BGL-416.cisco.com><618BE8B40039924EB9AED233D4A09C5103001EA3@XMB-BGL-416.cisco.com><8BEA2A9F-98D2-4828-BD68-5D980BD81EFE@lucidvision.com> <6EDB11CC-228B-4C1A-90F8-37E311D31878@lucidvision.com> From: "Ashish Dalela (adalela)" To: "Thomas Nadeau" , "Michael Hammer" X-OriginalArrivalTime: 16 Feb 2012 17:09:45.0757 (UTC) FILETIME=[C82A54D0:01CCECCD] Cc: sop@ietf.org, Ping Pan Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- ServiceOrchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 17:09:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCECCD.C7FB377D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tom, =20 I would suggest to read the requirements draft, because number of questions you and Ping are asking here about the goal, IETF-fit, relationship to open-source are anticipated and discussed in that draft. To your point about who needs it - inter-cloud is a service provider need, hybrid-cloud is a provider and customer need, and vendor-interoperability is both provider and customer need. =20 The requirements draft is here - http://tools.ietf.org/html/draft-dalela-orchestration-00 =20 Thanks, Ashish =20 From: sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] On Behalf Of Thomas Nadeau Sent: Thursday, February 16, 2012 10:34 PM To: Michael Hammer Cc: sop@ietf.org; Ping Pan; Ashish Dalela (adalela) Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- ServiceOrchestration and Desciption for Cloud Services =20 =20 On Feb 16, 2012, at 11:47 AM, Michael Hammer wrote: For interoperability's sake across private and public clouds from different network providers, we are looking for a protocol to be developed. =20 Is this a service provider requirement or one from equipment vendors? The analogy we are making is that on-demand provisioning of a voice/video network circuit between two points is done with SIP. Without interferring with that effort, and working in parallel, what is the difference with the on-demand provisioning of network/compute/storage over IP? =20 Would you also argue that all the SIP work should not have been done in IETF? Or that SIP should not have been done because there are open-source projects? =20 I am not arguing either way; I was asking the question to the wider audience. =20 --Tom =20 =20 Mike =20 On Thu, Feb 16, 2012 at 11:36 AM, Thomas Nadeau wrote: =20 Good point Ping. That is the question in my mind. Does this belong somewhere else like where OpenStack is being done, or otherwise? =20 --Tom =20 =20 On Feb 16, 2012, at 11:17 AM, Ping Pan wrote: =20 On Thu, Feb 16, 2012 at 8:09 AM, Ashish Dalela (adalela) wrote: This isn't just about the network resources and SOP isn't only about provisioning network resources. The protocol definition is generalized to support any kind of service - network included. =20 Be careful. Others have brought up similar proposal before. IETF stands for Internet Engineering TF... Networking is the name of the game. ;-) If not networking, I fear it would be wrong place to do the work. =20 In SDN, our focus is on networking. Further, we are trying to distance ourselves from the actual DC network fabric design (all vendor-specific so far). =20 Regards, =20 Ping _______________________________________________ sop mailing list sop@ietf.org https://www.ietf.org/mailman/listinfo/sop =20 _______________________________________________ sop mailing list sop@ietf.org https://www.ietf.org/mailman/listinfo/sop =20 =20 ------_=_NextPart_001_01CCECCD.C7FB377D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tom,

 =

I would = suggest to read the requirements draft, because number of questions you = and Ping are asking here about the goal, IETF-fit, relationship to = open-source are anticipated and discussed in that draft. To your point = about who needs it - inter-cloud is a service provider need, = hybrid-cloud is a provider and customer need, and = vendor-interoperability is both provider and customer = need.

 =

The = requirements draft is here - http://= tools.ietf.org/html/draft-dalela-orchestration-00

 <= /p>

Thanks, = Ashish=

 

From:= = sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] On Behalf Of = Thomas Nadeau
Sent: Thursday, February 16, 2012 10:34 = PM
To: Michael Hammer
Cc: sop@ietf.org; Ping Pan; = Ashish Dalela (adalela)
Subject: Re: [sop] [Sdnp] FW: New = Non-WG Mailing List: sop -- ServiceOrchestration and Desciption for = Cloud Services

 

 

On = Feb 16, 2012, at 11:47 AM, Michael Hammer wrote:



For = interoperability's sake across private and public clouds from different = network providers, we are looking for a protocol to be = developed.

 

        &n= bsp;   Is this a service provider requirement or one = from equipment vendors?



The = analogy we are making is that on-demand provisioning of a voice/video =  network circuit between two points is done with SIP.  Without = interferring with that effort, and working in parallel, what is the = difference with the on-demand provisioning of network/compute/storage = over IP?

 

Would you also argue that all the SIP work should not = have been done in IETF?

Or = that SIP should not have been done because there are open-source = projects?

 

        &n= bsp;   I am not arguing either way; I was asking the = question to the wider audience.

 

        &n= bsp;   --Tom

 



 

Mike

 

On Thu, Feb 16, 2012 at 11:36 AM, Thomas Nadeau <tnadeau@lucidvision.com> = wrote:

 

Good = point Ping. That is the question in my mind. Does this belong = somewhere else like where OpenStack is being done, or = otherwise?

 

--Tom

 

 

On Feb 16, 2012, at 11:17 AM, Ping Pan = wrote:

 

On Thu, Feb 16, 2012 at 8:09 AM, Ashish Dalela = (adalela) <adalela@cisco.com> wrote:

This isn’t just about the network resources and = SOP isn’t only about provisioning network resources. The protocol = definition is generalized to support any kind of service – network = included.

 

Be = careful. Others have brought up similar proposal before. IETF stands for = Internet Engineering TF... Networking is the name of the game. ;-) If = not networking, I fear it would be wrong place to do the = work.

 

In SDN, our focus is on networking. Further, we are = trying to distance ourselves from the actual DC network fabric = design (all vendor-specific so far).

 

Regards,

 

Ping

_______________________________________________
sop = mailing list
sop@ietf.org
https://www.ietf.org/mailman/listinfo/sop

 


______________________________________= _________
sop mailing list
sop@ietf.org
https://www.ietf.org/mailman/listinfo/sop

 

 

------_=_NextPart_001_01CCECCD.C7FB377D-- From mphmmr@gmail.com Thu Feb 16 09:22:52 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C0D21F86A7 for ; Thu, 16 Feb 2012 09:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 aAhLx9Yl-4Cw for ; Thu, 16 Feb 2012 09:22:46 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0200721F84D7 for ; Thu, 16 Feb 2012 09:22:45 -0800 (PST) Received: by lahl5 with SMTP id l5so3098891lah.31 for ; Thu, 16 Feb 2012 09:22:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ce8NL0Jhash2vvIumkIU2mAb+bOZ7WyHSiwRCwV+QgI=; b=wKBtBoZfryRWKpiVfDmgaEa9LL0iY5jZpiRH8BizJ0tSS3RM7dRK5qKoIhSwUrwf9w teF8wcrgqdhUUcUj0otSUodj/56ZjKiZfYE0nfXhasZ/yOoTpPh/owZfZfAbN8sPIHfr S0T5AgrEu39vkichnOesi7uLfhm9M5FGC8BMw= MIME-Version: 1.0 Received: by 10.152.148.230 with SMTP id tv6mr2693070lab.12.1329412964989; Thu, 16 Feb 2012 09:22:44 -0800 (PST) Received: by 10.112.104.70 with HTTP; Thu, 16 Feb 2012 09:22:44 -0800 (PST) In-Reply-To: <618BE8B40039924EB9AED233D4A09C5103001EEE@XMB-BGL-416.cisco.com> References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C5103001E8E@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C5103001EA3@XMB-BGL-416.cisco.com> <8BEA2A9F-98D2-4828-BD68-5D980BD81EFE@lucidvision.com> <6EDB11CC-228B-4C1A-90F8-37E311D31878@lucidvision.com> <618BE8B40039924EB9AED233D4A09C5103001EEE@XMB-BGL-416.cisco.com> Date: Thu, 16 Feb 2012 12:22:44 -0500 Message-ID: From: Michael Hammer To: "Ashish Dalela (adalela)" Content-Type: multipart/alternative; boundary=e89a8f22c33f89ba1804b9181321 Cc: Thomas Nadeau , sop@ietf.org, Ping Pan Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- ServiceOrchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 17:22:53 -0000 --e89a8f22c33f89ba1804b9181321 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ping, One of the ideas here is to separate out the service-dependent and service-independent aspects and hopefully provide a unifying framework to many disparate projects ongoing. So, it is not an either-or situation but how to help unify these efforts. As Ashish notes, we attempt to address some of these questions in those drafts. WRT Skype, this is also another case of lack of interoperability. As you probably saw, the EU had concerns about lack of interop with Cisco vis-a-vis Tandberg in the past, and of course Cisco is bringing this to the EU attention to keep the playing field level with respect to Skype. Whether it is Cisco-Tandberg or Microsoft-Skype, need to apply same rules to both. Architecturally, having to go through gateways everywhere is not a good long-term solution. It just doesn't scale well and leads to many broken or Least Common Denominator results. Not a very rich experience for the user. I should also point out that governments, who are also very big customers, do not want to be locked into just one solution. You don't want to do fork-lifts every time you move from one service provider to another. Mike On Thu, Feb 16, 2012 at 12:09 PM, Ashish Dalela (adalela) wrote: > Tom,**** > > ** ** > > I would suggest to read the requirements draft, because number of > questions you and Ping are asking here about the goal, IETF-fit, > relationship to open-source are anticipated and discussed in that draft. = To > your point about who needs it - inter-cloud is a service provider need, > hybrid-cloud is a provider and customer need, and vendor-interoperability > is both provider and customer need.**** > > ** ** > > The requirements draft is here - > http://tools.ietf.org/html/draft-dalela-orchestration-00**** > > ** ** > > Thanks, Ashish**** > > ** ** > > *From:* sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] *On Behalf Of = *Thomas > Nadeau > *Sent:* Thursday, February 16, 2012 10:34 PM > *To:* Michael Hammer > *Cc:* sop@ietf.org; Ping Pan; Ashish Dalela (adalela) > *Subject:* Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- > ServiceOrchestration and Desciption for Cloud Services**** > > ** ** > > ** ** > > On Feb 16, 2012, at 11:47 AM, Michael Hammer wrote:**** > > > > **** > > For interoperability's sake across private and public clouds from > different network providers, we are looking for a protocol to be develope= d. > **** > > ** ** > > Is this a service provider requirement or one from equipment > vendors?**** > > > > **** > > The analogy we are making is that on-demand provisioning of a voice/video > network circuit between two points is done with SIP. Without interferri= ng > with that effort, and working in parallel, what is the difference with th= e > on-demand provisioning of network/compute/storage over IP?**** > > ** ** > > Would you also argue that all the SIP work should not have been done in > IETF?**** > > Or that SIP should not have been done because there are open-source > projects?**** > > ** ** > > I am not arguing either way; I was asking the question to the > wider audience.**** > > ** ** > > --Tom**** > > ** ** > > > > **** > > ** ** > > Mike**** > > ** ** > > On Thu, Feb 16, 2012 at 11:36 AM, Thomas Nadeau > wrote:**** > > ** ** > > Good point Ping. That is the question in my mind. Does this belong > somewhere else like where OpenStack is being done, or otherwise?**** > > ** ** > > --Tom**** > > ** ** > > ** ** > > On Feb 16, 2012, at 11:17 AM, Ping Pan wrote:**** > > ** ** > > On Thu, Feb 16, 2012 at 8:09 AM, Ashish Dalela (adalela) < > adalela@cisco.com> wrote:**** > > This isn=92t just about the network resources and SOP isn=92t only about > provisioning network resources. The protocol definition is generalized to > support any kind of service =96 network included.**** > > ** ** > > Be careful. Others have brought up similar proposal before. IETF stands > for Internet Engineering TF... Networking is the name of the game. ;-) If > not networking, I fear it would be wrong place to do the work.**** > > ** ** > > In SDN, our focus is on networking. Further, we are trying to > distance ourselves from the actual DC network fabric design (all > vendor-specific so far).**** > > ** ** > > Regards,**** > > ** ** > > Ping**** > > _______________________________________________ > sop mailing list > sop@ietf.org > https://www.ietf.org/mailman/listinfo/sop**** > > ** ** > > > _______________________________________________ > sop mailing list > sop@ietf.org > https://www.ietf.org/mailman/listinfo/sop**** > > ** ** > > ** ** > --e89a8f22c33f89ba1804b9181321 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ping,

One of the ideas here is to separate out the servi= ce-dependent and service-independent aspects and hopefully provide a unifyi= ng framework to many disparate projects ongoing. =A0So, it is not an either= -or situation but how to help unify these efforts.

As Ashish notes, we attempt to address some of these qu= estions in those drafts.

WRT Skype, this is also a= nother case of lack of interoperability. =A0As you probably saw, the EU had= concerns about lack of interop with Cisco vis-a-vis Tandberg in the past, = and of course Cisco is bringing this to the EU attention to keep the playin= g field level with respect to Skype. =A0Whether it is Cisco-Tandberg or Mic= rosoft-Skype, need to apply same rules to both.

Architecturally, having to go through gateways everywhe= re is not a good long-term solution. =A0It just doesn't scale well and = leads to many broken or Least Common Denominator results. =A0Not a very ric= h experience for the user.

I should also point out that governments, who are also = very big customers, do not want to be locked into just one solution. =A0You= don't want to do fork-lifts every time you move from one service provi= der to another.

Mike

On Thu, Feb 16, = 2012 at 12:09 PM, Ashish Dalela (adalela) <adalela@cisco.com> wrote:

Tom,

=A0

I would suggest to read the requirements draft, because num= ber of questions you and Ping are asking here about the goal, IETF-fit, rel= ationship to open-source are anticipated and discussed in that draft. To yo= ur point about who needs it - inter-cloud is a service provider need, hybri= d-cloud is a provider and customer need, and vendor-interoperability is bot= h provider and customer need.

=A0

The requirement= s draft is here - http://tools.ietf.org/html/draft-dalela-orchestration-00

=A0

Thanks, Ashish

=A0<= /p>

From: sop-bounces@ietf.org= [mailto:sop-boun= ces@ietf.org] On Behalf Of Thomas Nadeau
Sent: Thursday, February 16, 2012 10:34 PM
To: Michael Ham= mer
Cc: sop@iet= f.org; Ping Pan; Ashish Dalela (adalela)
Subject: Re: [sop] [= Sdnp] FW: New Non-WG Mailing List: sop -- ServiceOrchestration and Descipti= on for Cloud Services

=A0=

=A0

On Feb 16, 2012, at 11:47 AM, Michael Hammer wrote:

=



For interoperability's= sake across private and public clouds from different network providers, we= are looking for a protocol to be developed.

=A0

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Is this a service provider requirement or one from e= quipment vendors?


The analogy we are making is that on-demand provisio= ning of a voice/video =A0network circuit between two points is done with SI= P. =A0Without interferring with that effort, and working in parallel, what = is the difference with the on-demand provisioning of network/compute/storag= e over IP?

=A0

Would you also argue that all the SIP work should not have b= een done in IETF?

Or tha= t SIP should not have been done because there are open-source projects?<= /u>

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 I am not arguing ei= ther way; I was asking the question to the wider audience.

=A0

=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 --Tom

=A0



<= u>

=A0

Mike

= =A0

On Thu, Feb 16, 2012 at 11:36 AM,= Thomas Nadeau <tnadeau@lucidvision.com> wrote:

=A0

Good point Ping.=A0That is the question in my mind. Does this belon= g somewhere else like where OpenStack is being done, or otherwise?

=A0

--Tom

=A0=

=A0

On Feb 16, 2012, at 11:17 AM, Ping Pan wrote:=

=A0

On Thu, Feb 16, 2012 at 8:09 AM, Ashish Dalela (adalela) <adalela@cisco.com> wrote:

This isn=92t just about the network = resources and SOP isn=92t only about provisioning network resources. The pr= otocol definition is generalized to support any kind of service =96 network= included.

=A0

Be careful. Others have brought up similar proposal before. IETF stands = for Internet Engineering TF... Networking is the name of the game. ;-) If n= ot networking, I fear it would be wrong place to do the work.=

=A0

In SDN, our focus is on networking. Further, we are trying t= o distance=A0ourselves=A0from the actual DC network fabric design (all vend= or-specific so far).

=A0

Regards,

= =A0

Ping

_________________________________________= ______
sop mailing list
sop@ietf.org
https://www.ietf.org/mailman/listinfo/sop<= u>

=A0

=


___________= ____________________________________
sop mailing list
sop@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sop

=A0

<= /u>=A0


--e89a8f22c33f89ba1804b9181321-- From robert@raszuk.net Thu Feb 16 09:24:42 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E70921F87FF for ; Thu, 16 Feb 2012 09:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] 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 atEuJe8+WuUj for ; Thu, 16 Feb 2012 09:24:40 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id CBA4E21F87D3 for ; Thu, 16 Feb 2012 09:24:34 -0800 (PST) Received: (qmail 23787 invoked by uid 399); 16 Feb 2012 17:24:34 -0000 Received: from unknown (HELO ?192.168.1.91?) (pbs:robert@raszuk.net@83.31.217.50) by mail1310.opentransfer.com with ESMTPM; 16 Feb 2012 17:24:34 -0000 X-Originating-IP: 83.31.217.50 Message-ID: <4F3D3BD2.4070102@raszuk.net> Date: Thu, 16 Feb 2012 18:24:34 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Michael Hammer References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> <4F3D2F02.3020302@raszuk.net> <4F3D3361.4030802@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Nadeau , sdnp , Ping Pan , "Monique Morrow \(mmorrow\)" , sop@ietf.org, "Ashish Dalela \(adalela\)" Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 17:24:42 -0000 > Yeah, having more than one standard is an issue as well. > Would hope that we could converge early on one, but the IETF is what it is. > But that is not an argument against trying, or you might as well shut > down any effort. Actually my only observation here is that openstack community seems to be a very health environment where things actually get done well and quick (read like IETF was doing in 1980s and 1990s) so I am just trying to make sure this effort (or whatever it will be end effect of this effort here) will not break it or will be even considered by current openstack community. If someone would ask me I would say that cloud to cloud standardization should belong and be done today in openstack community rather then in IETF. Thx, R. From adalela@cisco.com Thu Feb 16 16:21:39 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1F621E807E for ; Thu, 16 Feb 2012 16:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.005 X-Spam-Level: X-Spam-Status: No, score=-7.005 tagged_above=-999 required=5 tests=[AWL=3.594, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 JlJeoV0v+D4k for ; Thu, 16 Feb 2012 16:21:35 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id F41F421F85B8 for ; Thu, 16 Feb 2012 16:21:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=1775; q=dns/txt; s=iport; t=1329438095; x=1330647695; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=IAsp0v2gyyqZChKya0vJnfOtHoirWr/QOnMzhhbT9cc=; b=SGANyxEtl1yhU/i5hlJcSmpGwS0szOXd00whaX5WWy5312c3TxWg8I40 ZZyjObWyZ+DWS3J1SR83pI+bkT3uq9tKmyF9cMAvzENo4XbaO0qebGsY7 5aeOm8qgRj8vRqSI7jnxPUHNLULkMm0GIc/FHGgBXHyFakXZdHW/AhcNe A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAFadPU9Io8UY/2dsb2JhbABEsXKBcgEBAQMBEgEdCjQLBQcEAgEIEQQBAQsGFwEGAUUJCAEBBAsICAwOh12aWgGeS4tyBCstEQYDAoNjAQkGEQIDAgsmgjpjBIhMn1s X-IronPort-AV: E=Sophos;i="4.73,433,1325462400"; d="scan'208";a="5739908" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 17 Feb 2012 00:21:33 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1H0LX7H003849; Fri, 17 Feb 2012 00:21:33 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Feb 2012 05:51:33 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Feb 2012 05:51:31 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C5103001F5D@XMB-BGL-416.cisco.com> In-Reply-To: <4F3D3BD2.4070102@raszuk.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sop] -- Service Orchestration and Desciption for Cloud Services Thread-Index: Aczsz+J/oJ2HwR+PTwmIGLifya59aQANhe4w References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> <4F3D2F02.3020302@raszuk.net> <4F3D3361.4030802@raszuk.net> <4F3D3BD2.4070102@raszuk.net> From: "Ashish Dalela (adalela)" To: X-OriginalArrivalTime: 17 Feb 2012 00:21:33.0244 (UTC) FILETIME=[1A3B1FC0:01CCED0A] Cc: sop@ietf.org Subject: Re: [sop] -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 00:21:39 -0000 Robert, You need to go past this argument that OpenStack is healthy and by implication IETF is not. Or, what we have proposed here will break OpenStack.=20 This effort is not opposed to any open-source effort, including OpenStack. Its goal is to allow open and closed source to interoperate. Unless you are mandating that every cloud controller on the planet ought to be OpenStack, I don't see how this argument is relevant. The tradeoff should not be between go open source or you can never interoperate. That hasn't worked in the past, and it won't in the case of cloud.=20 Thanks, Ashish -----Original Message----- From: Robert Raszuk [mailto:robert@raszuk.net]=20 Sent: Thursday, February 16, 2012 10:55 PM To: Michael Hammer Cc: Thomas Nadeau; sdnp; Ping Pan; Monique Morrow (mmorrow); sop@ietf.org; Ashish Dalela (adalela) Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services > Yeah, having more than one standard is an issue as well. > Would hope that we could converge early on one, but the IETF is what it is. > But that is not an argument against trying, or you might as well shut > down any effort. Actually my only observation here is that openstack community seems to=20 be a very health environment where things actually get done well and=20 quick (read like IETF was doing in 1980s and 1990s) so I am just trying=20 to make sure this effort (or whatever it will be end effect of this=20 effort here) will not break it or will be even considered by current=20 openstack community. If someone would ask me I would say that cloud to cloud standardization=20 should belong and be done today in openstack community rather then in IETF. Thx, R. From adalela@cisco.com Thu Feb 16 18:32:39 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19DB821E8040; Thu, 16 Feb 2012 18:32:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.058 X-Spam-Level: X-Spam-Status: No, score=-7.058 tagged_above=-999 required=5 tests=[AWL=3.540, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 3GO9AP29he53; Thu, 16 Feb 2012 18:32:34 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9483321E8060; Thu, 16 Feb 2012 18:32:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=18003; q=dns/txt; s=iport; t=1329445946; x=1330655546; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=pa8CrZ59MEtDI/vncnA1p0LZuPkDjWZhbnXsMJYdcvo=; b=bv31MpBBqPj7EXVyqXdQpSiUOjcQvUjsoN+gNQhXlIV46uptL6z1izf5 t91BY0BOnhIKvxskD/rpnCtjC2wREkBiLFMiuOVFdK8unS/5FPu/D3GIq RnPxGeiDur7QozwmM7Pthr+OA5cz2jL+VHd8q9Y2FrrzwU4aAlruDNAUe c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkEAD27PU9Io8UY/2dsb2JhbABDglGlVAGJUoFyAQEBBAEBAQ8BCREDPgsQAgEIDgMBAwEBCwYXAQYBIAYfAwYIAQEECwgIGodmnxkBlm2IXoMNAggIAhACAwaEDCUEBwcGBQOCSGMEiEyXfodd X-IronPort-AV: E=Sophos;i="4.73,433,1325462400"; d="scan'208,217";a="5753579" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 17 Feb 2012 02:32:23 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1H2WNwt000575; Fri, 17 Feb 2012 02:32:23 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Feb 2012 08:02:23 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCED1C.61273991" Date: Fri, 17 Feb 2012 08:02:22 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C5103001F72@XMB-BGL-416.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dc] Service Orchestration Protocol Thread-Index: Aczs7ZfZDYEr3/UNTYaJqjiWS03dvQAKzDzQ References: <618BE8B40039924EB9AED233D4A09C5103001EEA@XMB-BGL-416.cisco.com> From: "Ashish Dalela (adalela)" To: "Bhumip Khasnabish" X-OriginalArrivalTime: 17 Feb 2012 02:32:23.0598 (UTC) FILETIME=[616814E0:01CCED1C] Cc: sop@ietf.org, dc@ietf.org Subject: Re: [sop] [dc] Service Orchestration Protocol X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 02:32:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCED1C.61273991 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bhumip, =20 Thanks, I'm aware of this draft. We should discuss it on the SOP alias as not to clutter everyone's email with a topic that may not be of interest. I'm cross posting this to SOP alias for now. =20 One of things that the first draft describes is limitations of HTTP (and by implication web-services) for doing cloud - HTTP does not have constructs to do service discovery, pub-sub, commit-cancel, transaction forking, interactive prompts, etc. These capabilities are service-independent (applicable to all services) and very important to build complex, multi-tiered, or cross-domain services.=20 =20 So, we did not want to add just a new content-type to HTTP, and layer basic capability into the controller application. The idea here is that if there are service independent capabilities, they should be part of a basic protocol scheme, which can be used by every type of service. But we preserved the text-based nature of well-known L7 protocols - SIP, HTTP, SMTP, etc.=20 =20 To the specific issue of broker, you might want to refer to the architecture draft, where we described different types of brokers (we call them proxies). The functionality in the broker differs depending on where you place the broker - in the service edge, customer edge, provider edge, etc. We expect that different domains (compute, storage, network ..) will have different domain controllers. You still need to find an interoperable scheme to stitch these domain controllers. =20 Thanks, Ashish =20 From: Bhumip Khasnabish [mailto:vumip1@gmail.com]=20 Sent: Friday, February 17, 2012 2:27 AM To: Ashish Dalela (adalela) Cc: dc@ietf.org Subject: Re: [dc] Service Orchestration Protocol =20 Hello Ashish, =20 There is also a Cloud Service Broker draft =20 http://tools.ietf.org/id/draft-shao-opsawg-cloud-service-broker-02.txt=20 Thanks. =20 Best. =20 Bhumip =20 On Thu, Feb 16, 2012 at 12:06 PM, Ashish Dalela (adalela) wrote: Folks, =20 This may not be completely relevant to the DC topic, but thought that some of you might be interested in it. =20 We have a few drafts posted on a "Service Orchestration Protocol", with the intent to enable cloud interoperability. =20 http://tools.ietf.org/html/draft-dalela-orchestration-00 - talks about why we need a protocol, a.k.a. requirements http://tools.ietf.org/html/draft-dalela-sop-architecture-00 - describes the use-cases and network deployments with the protocol http://tools.ietf.org/html/draft-dalela-sop-00 - describes the protocol's messages http://tools.ietf.org/html/draft-dalela-sdf-00 - describes scheme for service naming, workflows, etc. http://tools.ietf.org/html/draft-dalela-sop-flows-00 - describes some message flows =20 A discussion alias https://www.ietf.org/mailman/listinfo/sop is setup for you to participate in case you find it interesting. =20 Thanks and look forward to discussing there. =20 -Ashish =20 _______________________________________________ dc mailing list dc@ietf.org https://www.ietf.org/mailman/listinfo/dc =20 ------_=_NextPart_001_01CCED1C.61273991 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bhumip,

 

Thanks, I’m aware of this draft. We should discuss it on the = SOP alias as not to clutter everyone’s email with a topic that may = not be of interest. I’m cross posting this to SOP alias for = now.

 

One of things that the first draft describes is limitations of HTTP = (and by implication web-services) for doing cloud – HTTP does not = have constructs to do service discovery, pub-sub, commit-cancel, = transaction forking, interactive prompts, etc. These capabilities are = service-independent (applicable to all services) and very important to = build complex, multi-tiered, or cross-domain services. =

 

So, we did not want to add just a new content-type to HTTP, and layer = basic capability into the controller application. The idea here is that = if there are service independent capabilities, they should be part of a = basic protocol scheme, which can be used by every type of service. But = we preserved the text-based nature of well-known L7 protocols – = SIP, HTTP, SMTP, etc.

 

To the specific issue of broker, you might want to refer to the = architecture draft, where we described different types of brokers (we = call them proxies). The functionality in the broker differs depending on = where you place the broker – in the service edge, customer edge, = provider edge, etc. We expect that different domains (compute, storage, = network ..) will have different domain controllers. You still need to = find an interoperable scheme to stitch these domain = controllers.

 

Thanks, Ashish

 

From:= = Bhumip Khasnabish [mailto:vumip1@gmail.com]
Sent: Friday, = February 17, 2012 2:27 AM
To: Ashish Dalela = (adalela)
Cc: dc@ietf.org
Subject: Re: [dc] Service = Orchestration Protocol

 

Hello = Ashish,

 

There is also a Cloud Service Broker = draft

 

Thanks.

 

Best.

 

Bhumip


 

On Thu, Feb 16, 2012 at 12:06 PM, Ashish Dalela = (adalela) <adalela@cisco.com> = wrote:

Folks,<= /p>

 <= /p>

This may not be = completely relevant to the DC topic, but thought that some of you might = be interested in it.

 <= /p>

We have a few drafts = posted on a “Service Orchestration Protocol”, with the = intent to enable cloud interoperability.

 <= /p>

http://tools.ietf.org/html/draft-dalela-orchestration-0= 0 - talks about why we need a protocol, a.k.a. = requirements

http://tools.ietf.org/html/draft-dalela-sop-architectur= e-00 - describes the use-cases and network deployments with the = protocol

http://tools.ietf.org/html/draft-dalela-sop-00 - = describes the protocol’s messages

http://tools.ietf.org/html/draft-dalela-sdf-00 - = describes scheme for service naming, workflows, = etc.

http://tools.ietf.org/html/draft-dalela-sop-flows-00 - describes some message flows

 <= /p>

A discussion alias https://www.ietf.org/mailman/listinfo/sop is setup = for you to participate in case you find it = interesting.

 <= /p>

Thanks and look forward = to discussing there.

 <= /p>

-Ashish

 


______________________________________= _________
dc mailing list
dc@ietf.org
https://www.ietf.org/mailman/listinfo/dc=




  =

------_=_NextPart_001_01CCED1C.61273991-- From vumip1@gmail.com Thu Feb 16 18:45:24 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F36321E8028; Thu, 16 Feb 2012 18:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.026 X-Spam-Level: X-Spam-Status: No, score=-3.026 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] 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 2dQqQAuAkHR1; Thu, 16 Feb 2012 18:45:20 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEDF21E801C; Thu, 16 Feb 2012 18:45:20 -0800 (PST) Received: by iagf6 with SMTP id f6so4467795iag.31 for ; Thu, 16 Feb 2012 18:45:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YUXKDioiZZRJGTxRHWHoCBOoSmpmReOgFZV0X1YX/eQ=; b=qeRy5Z87tmAMPu7V0bZCTiaIDk00AhgWm6cL3xSeohf+SegiYOqTvyoOo9CfuF304H r+9trt5VNy98p6QSIITaipm8rgDzaxGV4I5xapzk5nFKaRdo0JmJB6NSNRmuzwHxwmQh aQa9HJP3NYPjlkc8/RNrdFnAaLlJB4stoALlw= MIME-Version: 1.0 Received: by 10.43.51.135 with SMTP id vi7mr5210181icb.5.1329446719796; Thu, 16 Feb 2012 18:45:19 -0800 (PST) Received: by 10.50.213.68 with HTTP; Thu, 16 Feb 2012 18:45:19 -0800 (PST) In-Reply-To: <618BE8B40039924EB9AED233D4A09C5103001F72@XMB-BGL-416.cisco.com> References: <618BE8B40039924EB9AED233D4A09C5103001EEA@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C5103001F72@XMB-BGL-416.cisco.com> Date: Thu, 16 Feb 2012 21:45:19 -0500 Message-ID: From: Bhumip Khasnabish To: "Ashish Dalela (adalela)" Content-Type: multipart/alternative; boundary=bcaec52e62177b33ee04b91fef18 Cc: shao.weixiang@zte.com.cn, sop@ietf.org, hu.jie@zte.com.cn, dc@ietf.org Subject: Re: [sop] [dc] Service Orchestration Protocol X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 02:45:24 -0000 --bcaec52e62177b33ee04b91fef18 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks for your quick comments Ashish. I am cc:ing my co-authors for reviewing your comments and suggestions, and the SOP drafts for further discussion. Best. Bhumip On Thu, Feb 16, 2012 at 9:32 PM, Ashish Dalela (adalela) wrote: > Bhumip,**** > > ** ** > > Thanks, I=92m aware of this draft. We should discuss it on the SOP alias = as > not to clutter everyone=92s email with a topic that may not be of interes= t. > I=92m cross posting this to SOP alias for now.**** > > ** ** > > One of things that the first draft describes is limitations of HTTP (and > by implication web-services) for doing cloud =96 HTTP does not have > constructs to do service discovery, pub-sub, commit-cancel, transaction > forking, interactive prompts, etc. These capabilities are > service-independent (applicable to all services) and very important to > build complex, multi-tiered, or cross-domain services. **** > > ** ** > > So, we did not want to add just a new content-type to HTTP, and layer > basic capability into the controller application. The idea here is that i= f > there are service independent capabilities, they should be part of a basi= c > protocol scheme, which can be used by every type of service. But we > preserved the text-based nature of well-known L7 protocols =96 SIP, HTTP, > SMTP, etc. **** > > ** ** > > To the specific issue of broker, you might want to refer to the > architecture draft, where we described different types of brokers (we cal= l > them proxies). The functionality in the broker differs depending on where > you place the broker =96 in the service edge, customer edge, provider edg= e, > etc. We expect that different domains (compute, storage, network ..) will > have different domain controllers. You still need to find an interoperabl= e > scheme to stitch these domain controllers.**** > > ** ** > > Thanks, Ashish**** > > ** ** > > *From:* Bhumip Khasnabish [mailto:vumip1@gmail.com] > *Sent:* Friday, February 17, 2012 2:27 AM > *To:* Ashish Dalela (adalela) > *Cc:* dc@ietf.org > *Subject:* Re: [dc] Service Orchestration Protocol**** > > ** ** > > Hello Ashish,**** > > **** > > There is also a Cloud Service Broker draft**** > > **** > > http://tools.ietf.org/id/draft-shao-opsawg-cloud-service-broker-02.txt **= * > * > > Thanks.**** > > **** > > Best.**** > > **** > > Bhumip**** > > > **** > > On Thu, Feb 16, 2012 at 12:06 PM, Ashish Dalela (adalela) < > adalela@cisco.com> wrote:**** > > Folks,**** > > **** > > This may not be completely relevant to the DC topic, but thought that som= e > of you might be interested in it.**** > > **** > > We have a few drafts posted on a =93Service Orchestration Protocol=94, wi= th > the intent to enable cloud interoperability.**** > > **** > > http://tools.ietf.org/html/draft-dalela-orchestration-00 - talks about > why we need a protocol, a.k.a. requirements**** > > http://tools.ietf.org/html/draft-dalela-sop-architecture-00 - describes > the use-cases and network deployments with the protocol**** > > http://tools.ietf.org/html/draft-dalela-sop-00 - describes the protocol= =92s > messages**** > > http://tools.ietf.org/html/draft-dalela-sdf-00 - describes scheme for > service naming, workflows, etc.**** > > http://tools.ietf.org/html/draft-dalela-sop-flows-00 - describes some > message flows**** > > **** > > A discussion alias https://www.ietf.org/mailman/listinfo/sop is setup for > you to participate in case you find it interesting.**** > > **** > > Thanks and look forward to discussing there.**** > > **** > > -Ashish**** > > **** > > > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc**** > > > > > **** > --bcaec52e62177b33ee04b91fef18 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Thanks for your quick comments Ashish. I am cc:ing my co-authors for r= eviewing your comments and suggestions, and the SOP drafts for further disc= ussion.
=A0
Best.
=A0
Bhumip
=A0

=A0
On Thu, Feb 16, 2012 at 9:32 PM, Ashish Dalela (= adalela) <adalela= @cisco.com> wrote:

Bhumip,

=A0

Thanks, I=92m aware of this dra= ft. We should discuss it on the SOP alias as not to clutter everyone=92s em= ail with a topic that may not be of interest. I=92m cross posting this to S= OP alias for now.

=A0

One of things that the first dr= aft describes is limitations of HTTP (and by implication web-services) for = doing cloud =96 HTTP does not have constructs to do service discovery, pub-= sub, commit-cancel, transaction forking, interactive prompts, etc. These ca= pabilities are service-independent (applicable to all services) and very im= portant to build complex, multi-tiered, or cross-domain services.

=A0

So, we did not want to add just= a new content-type to HTTP, and layer basic capability into the controller= application. The idea here is that if there are service independent capabi= lities, they should be part of a basic protocol scheme, which can be used b= y every type of service. But we preserved the text-based nature of well-kno= wn L7 protocols =96 SIP, HTTP, SMTP, etc.

=A0

To the specific issue of broker= , you might want to refer to the architecture draft, where we described dif= ferent types of brokers (we call them proxies). The functionality in the br= oker differs depending on where you place the broker =96 in the service edg= e, customer edge, provider edge, etc. We expect that different domains (com= pute, storage, network ..) will have different domain controllers. You stil= l need to find an interoperable scheme to stitch these domain controllers.<= u>

=A0

Thanks, Ashish

=A0

From: Bhumip Khasnabish [m= ailto:vumip1@gmail.co= m]
Sent: Friday, February 17, 2012 2:27 AM
To: Ashish Dalela = (adalela)
Cc: dc= @ietf.org
Subject: Re: [dc] Service Orchestration Protocol=

=A0

Hello Ashish,

=A0

There is also a Cloud Service Broker draft=

=A0

Thanks.

=A0

Best.

=A0

Bhumip


=A0

On Thu, Feb 16, 2012 at 12:06 PM, Ashish Dalela (ada= lela) <adalela@ci= sco.com> wrote:

Folks,

=A0

This may not be completely relevant to the DC topic, but thought that som= e of you might be interested in it.

=A0

We have a few drafts posted on a =93Service Orchestration Protocol=94, wi= th the intent to enable cloud interoperability.

=A0

http://tools.ietf.org/html/draft-dalela-orchestration-00 = - talks about why we need a protocol, a.k.a. requirements<= /u>

http://tools.ietf.org/html/draft-dalela-sop-architecture-0= 0 - describes the use-cases and network deployments with the protocol

http://tools.ietf.org/html/draft-dalela-sop-00 - describes the prot= ocol=92s messages

http://tools.ietf.org/html/draft-dalela-sdf-00 - describes scheme f= or service naming, workflows, etc.

http://tools.ietf.org/html/draft-dalela-sop-flows-00 - desc= ribes some message flows

=A0

A discussion alias https://www.ietf.org/mailman/listinfo/sop is setup fo= r you to participate in case you find it interesting.<= /p>

=A0

Thanks and look forward to discussing there.

=A0

-Ashish<= /span>

=A0


___________________= ____________________________
dc mailing list
dc@ietf.org
https://www.ietf.org/mailman/listin= fo/dc




=A0



=A0 --bcaec52e62177b33ee04b91fef18-- From robert@raszuk.net Fri Feb 17 00:07:37 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C7C21E801F for ; Fri, 17 Feb 2012 00:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 E5ULZgBjI65J for ; Fri, 17 Feb 2012 00:07:36 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 18B2421E8015 for ; Fri, 17 Feb 2012 00:07:35 -0800 (PST) Received: (qmail 17092 invoked by uid 399); 17 Feb 2012 08:07:34 -0000 Received: from unknown (HELO ?192.168.1.57?) (pbs:m42@mojaklasa.info@83.28.249.110) by mail1310.opentransfer.com with ESMTPM; 17 Feb 2012 08:07:34 -0000 X-Originating-IP: 83.28.249.110 Message-ID: <4F3E0AC6.5040402@raszuk.net> Date: Fri, 17 Feb 2012 09:07:34 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: "Ashish Dalela (adalela)" References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> <4F3D2F02.3020302@raszuk.net> <4F3D3361.4030802@raszuk.net> <4F3D3BD2.4070102@raszuk.net> <618BE8B40039924EB9AED233D4A09C5103001F5D@XMB-BGL-416.cisco.com> In-Reply-To: <618BE8B40039924EB9AED233D4A09C5103001F5D@XMB-BGL-416.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sop@ietf.org Subject: Re: [sop] -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 08:07:37 -0000 Ashish, I don't need to go past as I am not stuck :) I see how OS community progresses and I am also very heavily involved in IETF standardization process and I first hand see how it does not. It is not the question if it would be nice to have a standard cloud to cloud communication. In fact I expressed this already in the first mail as reply to Wes. The questions I see are: - is IETF right place to standardize it - if IETF does eventually publish something would that be accepted by community (in particular open source one) Best, R. > Robert, > > You need to go past this argument that OpenStack is healthy and by > implication IETF is not. Or, what we have proposed here will break > OpenStack. > > This effort is not opposed to any open-source effort, including > OpenStack. Its goal is to allow open and closed source to interoperate. > Unless you are mandating that every cloud controller on the planet ought > to be OpenStack, I don't see how this argument is relevant. > > The tradeoff should not be between go open source or you can never > interoperate. That hasn't worked in the past, and it won't in the case > of cloud. > > Thanks, Ashish > > -----Original Message----- > From: Robert Raszuk [mailto:robert@raszuk.net] > Sent: Thursday, February 16, 2012 10:55 PM > To: Michael Hammer > Cc: Thomas Nadeau; sdnp; Ping Pan; Monique Morrow (mmorrow); > sop@ietf.org; Ashish Dalela (adalela) > Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service > Orchestration and Desciption for Cloud Services > > >> Yeah, having more than one standard is an issue as well. >> Would hope that we could converge early on one, but the IETF is what > it is. >> But that is not an argument against trying, or you might as well shut >> down any effort. > > Actually my only observation here is that openstack community seems to > be a very health environment where things actually get done well and > quick (read like IETF was doing in 1980s and 1990s) so I am just trying > to make sure this effort (or whatever it will be end effect of this > effort here) will not break it or will be even considered by current > openstack community. > > If someone would ask me I would say that cloud to cloud standardization > should belong and be done today in openstack community rather then in > IETF. > > Thx, > R. > _______________________________________________ > sop mailing list > sop@ietf.org > https://www.ietf.org/mailman/listinfo/sop > > From adalela@cisco.com Sat Feb 18 13:57:20 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8E121E8019 for ; Sat, 18 Feb 2012 13:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.111 X-Spam-Level: X-Spam-Status: No, score=-7.111 tagged_above=-999 required=5 tests=[AWL=3.488, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 EwAa51sXJ4Fo for ; Sat, 18 Feb 2012 13:57:19 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0509021E8017 for ; Sat, 18 Feb 2012 13:57:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=3455; q=dns/txt; s=iport; t=1329602239; x=1330811839; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=1n4MEKY6TksAYNh5898zMSsnrDyzeWM1Y37Hdr7gzx4=; b=mfS5Y5VOAgcYe/SecaIiqIat4kdPKFuwaa1tYmfwzeOFdhsbA9R/iBnE 7pX//bqOkur+mR3wtxlayHEw3L8DX9XmdGpMlbm1JFUqrjVka0sD4m5Yx MVozSoJudCIUfmpm9UhYC6sdW2DN98j+KGZMmBHQr+YibAMsmzN6wvbp3 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EABceQE9Io8UY/2dsb2JhbABDszKBcwEBAQMBAQEBDwEdCjQLBQcEAgEIEQQBAQsGFwEGASYfCQgBAQQLCAgMDodeCZ8bAZYlBIlNglMIDAmEAwgFBQwEDgcGCIJJYwSITJ9ggVQ X-IronPort-AV: E=Sophos;i="4.73,443,1325462400"; d="scan'208";a="5873571" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 18 Feb 2012 21:57:16 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1ILvGLm025601; Sat, 18 Feb 2012 21:57:16 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 19 Feb 2012 03:27:16 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 19 Feb 2012 03:27:13 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C51030022CC@XMB-BGL-416.cisco.com> In-Reply-To: <4F3E0AC6.5040402@raszuk.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sop] -- Service Orchestration and Desciption for Cloud Services Thread-Index: AcztSzgyF6hVmIz6QnGBzxCf59wIFgBMrvFg References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> <4F3D2F02.3020302@raszuk.net> <4F3D3361.4030802@raszuk.net> <4F3D3BD2.4070102@raszuk.net> <618BE8B40039924EB9AED233D4A09C5103001F5D@XMB-BGL-416.cisco.com> <4F3E0AC6.5040402@raszuk.net> From: "Ashish Dalela (adalela)" To: X-OriginalArrivalTime: 18 Feb 2012 21:57:16.0360 (UTC) FILETIME=[4726F480:01CCEE88] Cc: sop@ietf.org Subject: Re: [sop] -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 21:57:20 -0000 Robert, >> - is IETF right place to standardize it This specific question is discussed in section 6 of the requirements draft. Most cloud services use HTTP (web-services) today. Limitations of HTTP for cloud services are described in section 8. =09 >> - if IETF does eventually publish something would that be accepted by community (in particular open source one) Let's not forget that providers need to differentiate their services from one another. How will provider services be differentiated if everyone uses the same open-source software stack? Add proprietary extensions not published back to open-source? =09 Thanks, Ashish -----Original Message----- From: Robert Raszuk [mailto:robert@raszuk.net]=20 Sent: Friday, February 17, 2012 1:38 PM To: Ashish Dalela (adalela) Cc: sop@ietf.org Subject: Re: [sop] -- Service Orchestration and Desciption for Cloud Services Ashish, I don't need to go past as I am not stuck :) I see how OS community=20 progresses and I am also very heavily involved in IETF standardization=20 process and I first hand see how it does not. It is not the question if it would be nice to have a standard cloud to=20 cloud communication. In fact I expressed this already in the first mail=20 as reply to Wes. The questions I see are: - is IETF right place to standardize it - if IETF does eventually publish something would that be accepted by=20 community (in particular open source one) Best, R. > Robert, > > You need to go past this argument that OpenStack is healthy and by > implication IETF is not. Or, what we have proposed here will break > OpenStack. > > This effort is not opposed to any open-source effort, including > OpenStack. Its goal is to allow open and closed source to interoperate. > Unless you are mandating that every cloud controller on the planet ought > to be OpenStack, I don't see how this argument is relevant. > > The tradeoff should not be between go open source or you can never > interoperate. That hasn't worked in the past, and it won't in the case > of cloud. > > Thanks, Ashish > > -----Original Message----- > From: Robert Raszuk [mailto:robert@raszuk.net] > Sent: Thursday, February 16, 2012 10:55 PM > To: Michael Hammer > Cc: Thomas Nadeau; sdnp; Ping Pan; Monique Morrow (mmorrow); > sop@ietf.org; Ashish Dalela (adalela) > Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service > Orchestration and Desciption for Cloud Services > > >> Yeah, having more than one standard is an issue as well. >> Would hope that we could converge early on one, but the IETF is what > it is. >> But that is not an argument against trying, or you might as well shut >> down any effort. > > Actually my only observation here is that openstack community seems to > be a very health environment where things actually get done well and > quick (read like IETF was doing in 1980s and 1990s) so I am just trying > to make sure this effort (or whatever it will be end effect of this > effort here) will not break it or will be even considered by current > openstack community. > > If someone would ask me I would say that cloud to cloud standardization > should belong and be done today in openstack community rather then in > IETF. > > Thx, > R. > _______________________________________________ > sop mailing list > sop@ietf.org > https://www.ietf.org/mailman/listinfo/sop > > From robert@raszuk.net Sat Feb 18 14:16:56 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F4E21F8517 for ; Sat, 18 Feb 2012 14:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599] 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 j9iTwEJFSxjz for ; Sat, 18 Feb 2012 14:16:56 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id C967521F8508 for ; Sat, 18 Feb 2012 14:16:55 -0800 (PST) Received: (qmail 22786 invoked by uid 399); 18 Feb 2012 22:16:55 -0000 Received: from unknown (HELO ?192.168.1.57?) (pbs:robert@raszuk.net@83.31.184.197) by mail1310.opentransfer.com with ESMTPM; 18 Feb 2012 22:16:55 -0000 X-Originating-IP: 83.31.184.197 Message-ID: <4F402358.2070802@raszuk.net> Date: Sat, 18 Feb 2012 23:16:56 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Ashish Dalela (adalela)" References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> <4F3D2F02.3020302@raszuk.net> <4F3D3361.4030802@raszuk.net> <4F3D3BD2.4070102@raszuk.net> <618BE8B40039924EB9AED233D4A09C5103001F5D@XMB-BGL-416.cisco.com> <4F3E0AC6.5040402@raszuk.net> <618BE8B40039924EB9AED233D4A09C51030022CC@XMB-BGL-416.cisco.com> In-Reply-To: <618BE8B40039924EB9AED233D4A09C51030022CC@XMB-BGL-416.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sop@ietf.org Subject: Re: [sop] -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 22:16:56 -0000 > Let's not forget that providers need to differentiate their services > from one another. You are telling me that ? You - were it takes cisco on average 2 years to get any enhancement in then such enhancement is immediately available to all service providers as clearly you can not scale with per customer development branch. Amazing stuff ! > How will provider services be differentiated if > everyone uses the same open-source software stack? Add proprietary > extensions not published back to open-source? If such open source license permits it (example apache) .. why not ? Thx, R. From adalela@cisco.com Sun Feb 19 21:57:46 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7CE221F8672 for ; Sun, 19 Feb 2012 21:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.161 X-Spam-Level: X-Spam-Status: No, score=-7.161 tagged_above=-999 required=5 tests=[AWL=3.437, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 KmNem00lpk73 for ; Sun, 19 Feb 2012 21:57:45 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB1221F851A for ; Sun, 19 Feb 2012 21:57:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=8274; q=dns/txt; s=iport; t=1329717464; x=1330927064; h=mime-version:subject:date:message-id:from:to; bh=mG7Lnedkj6fL7h9TLbvb+QgEy0u0peqde0B91SE3lHI=; b=I14MOmfTJIl3hTqIWisMYbTY1EELrGnNMpq8ScLGAvx+eAAhlXM5NSET 8f3r7Gjzcgt+UGx3vM1z0wc0yFU0GKIBywXqWt1+bgiwCsLaNxOJCgdtV eeEAcLPTmMXpqPoY6GIxMjdFLy7p0sZZ8WsNRR4TqK8d/4U0QOR4hpXDr 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAEzgQU9Io8UY/2dsb2JhbABDglGwZYF1AQQSAQkRA1sBKgYYB1cBBAsQGqYjgScBlhaMC2MCg18CWYI7YwSITJ9g X-IronPort-AV: E=Sophos;i="4.73,449,1325462400"; d="scan'208,217";a="5932572" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 20 Feb 2012 05:57:42 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1K5vgAM022667 for ; Mon, 20 Feb 2012 05:57:42 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Feb 2012 11:27:42 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCEF94.8F478A65" Date: Mon, 20 Feb 2012 11:27:42 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C510300237A@XMB-BGL-416.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: two architectures - which one do you prefer? Thread-Index: AczvlI8F0BsazY9mR8mC1OIvBBxXLQ== From: "Ashish Dalela (adalela)" To: X-OriginalArrivalTime: 20 Feb 2012 05:57:42.0745 (UTC) FILETIME=[8F6DFC90:01CCEF94] Subject: [sop] two architectures - which one do you prefer? X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 05:57:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCEF94.8F478A65 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, =20 There are two dominant architectures being pushed for cloud in the industry today. =20 1. Application is the God of the datacenter. All infrastructure is food supplied to the application to continue its operation, and additional infrastructure is provisioned if an application asks for it. The "management" of the infrastructure is in the application, because the infrastructure really exists for the purposes of the application. You obviously have to often re-write or re-design or at the least enhance your applications to be able to orchestrate the infrastructure.=20 =20 2. A new God is created for both infrastructure and application. In this model, some new controller monitors both application and infrastructure, holds the policies for which application / user can have which resources, how much a user has to be billed for a type of service, etc. You don't have to re-write your applications but you have to create an additional control layer on top of infrastructure and application. You want this additional layer to be as flat as possible, but allow sufficient abstractions for easy control. =20 These obviously entail different architectures, from an application control standpoint. In the first model, the application controls itself and the infrastructure. In the second model, the application is also a resource along with infrastructure, managed by some external controller. =20 Any discussion or comments on these two models? =20 Thanks, Ashish ------_=_NextPart_001_01CCEF94.8F478A65 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,<= /p>

 <= /p>

There are two dominant = architectures being pushed for cloud in the industry = today.

    &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;  

1.  Application is the God = of the datacenter. All infrastructure is food supplied to the = application to continue its operation, and additional infrastructure is = provisioned if an application asks for it. The “management” = of the infrastructure is in the application, because the infrastructure = really exists for the purposes of the application. You obviously have to = often re-write or re-design or at the least enhance your applications to = be able to orchestrate the infrastructure.

 <= /p>

2.  A new God is created for = both infrastructure and application. In this model, some new controller = monitors both application and infrastructure, holds the policies for = which application / user can have which resources, how much a user has = to be billed for a type of service, etc. You don’t have to = re-write your applications but you have to create an additional control = layer on top of infrastructure and application. You want this additional = layer to be as flat as possible, but allow sufficient abstractions for = easy control.

 <= /p>

These obviously entail = different architectures, from an application control standpoint. In the = first model, the application controls itself and the infrastructure. In = the second model, the application is also a resource along with = infrastructure, managed by some external = controller.

 <= /p>

Any discussion or = comments on these two models?

 <= /p>

Thanks, = Ashish

------_=_NextPart_001_01CCEF94.8F478A65-- From adalela@cisco.com Mon Feb 20 01:32:29 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE5921F871B for ; Mon, 20 Feb 2012 01:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.21 X-Spam-Level: X-Spam-Status: No, score=-7.21 tagged_above=-999 required=5 tests=[AWL=3.388, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 CVHzvjeB45Jq for ; Mon, 20 Feb 2012 01:32:25 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2691C21F8726 for ; Mon, 20 Feb 2012 01:32:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=11403; q=dns/txt; s=iport; t=1329730345; x=1330939945; h=mime-version:subject:date:message-id:from:to; bh=rbTlN7rkCBO7ddMlgNOdYkz0mdiA871u7XElEzhmu1Q=; b=jxbt/B+yeM702WG6FpVa8Gd3X2waAFLVXe+wyZhbWXwhTd7D2kZt42J/ VbVZExuBvp0S1jOmKdugB/rQomM2cTjYc9kXLh8onqGPqn4K1bGHAzR7s HpH5Vg1k5g19x2xY1XQVVw5R/jX0BihiCO9eeHNld50hst/J1DNhUaxrj A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALMSQk9Io8UR/2dsb2JhbABEgk2vaIEHgXMBAQEEEgEJEQNbAQgRBAEBCwYYB04JAQQLCAgaoWWBJwGeIot/DA5XhnVjBIhMn2A X-IronPort-AV: E=Sophos;i="4.73,450,1325462400"; d="scan'208,217";a="31294878" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by mtv-iport-2.cisco.com with ESMTP; 20 Feb 2012 09:32:22 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1K9WLck023055 for ; Mon, 20 Feb 2012 09:32:21 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Feb 2012 15:02:21 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCEFB2.8BD03799" Date: Mon, 20 Feb 2012 15:02:21 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C510300242D@XMB-BGL-416.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: two architectures - which one do you prefer? Thread-Index: AczvlI8F0BsazY9mR8mC1OIvBBxXLQAHWZHw From: "Ashish Dalela (adalela)" To: X-OriginalArrivalTime: 20 Feb 2012 09:32:21.0923 (UTC) FILETIME=[8C049730:01CCEFB2] Subject: Re: [sop] two architectures - which one do you prefer? X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 09:32:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCEFB2.8BD03799 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 BTW, these may not be the only architectures out there. So, if anyone believes there are more architectures, it would be great to have that in the discussion. I'm just familiar with two of them, so hope to hear if there are more. I realize that "God" may be a strong word for some people (J), but we could replace this with the word "controller" without loss of meaning. =20 Thanks, Ashish =20 From: Ashish Dalela (adalela)=20 Sent: Monday, February 20, 2012 11:28 AM To: sop@ietf.org Subject: two architectures - which one do you prefer? =20 Folks, =20 There are two dominant architectures being pushed for cloud in the industry today. =20 1. Application is the God of the datacenter. All infrastructure is food supplied to the application to continue its operation, and additional infrastructure is provisioned if an application asks for it. The "management" of the infrastructure is in the application, because the infrastructure really exists for the purposes of the application. You obviously have to often re-write or re-design or at the least enhance your applications to be able to orchestrate the infrastructure.=20 =20 2. A new God is created for both infrastructure and application. In this model, some new controller monitors both application and infrastructure, holds the policies for which application / user can have which resources, how much a user has to be billed for a type of service, etc. You don't have to re-write your applications but you have to create an additional control layer on top of infrastructure and application. You want this additional layer to be as flat as possible, but allow sufficient abstractions for easy control. =20 These obviously entail different architectures, from an application control standpoint. In the first model, the application controls itself and the infrastructure. In the second model, the application is also a resource along with infrastructure, managed by some external controller. =20 Any discussion or comments on these two models? =20 Thanks, Ashish ------_=_NextPart_001_01CCEFB2.8BD03799 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

BTW, these may not be = the only architectures out there. So, if anyone believes there are more = architectures, it would be great to have that in the discussion. = I’m just familiar with two of them, so hope to hear if there are = more. I realize that “God” may be a strong word for some = people (J), but we could replace this with the word = “controller” without loss of = meaning.

 

Thanks, = Ashish

 

From:= = Ashish Dalela (adalela)
Sent: Monday, February 20, 2012 11:28 = AM
To: sop@ietf.org
Subject: two architectures - = which one do you prefer?

 

Folks,<= /p>

 <= /p>

There are two dominant = architectures being pushed for cloud in the industry = today.

    &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;  

1.  Application is the God = of the datacenter. All infrastructure is food supplied to the = application to continue its operation, and additional infrastructure is = provisioned if an application asks for it. The “management” = of the infrastructure is in the application, because the infrastructure = really exists for the purposes of the application. You obviously have to = often re-write or re-design or at the least enhance your applications to = be able to orchestrate the infrastructure.

 <= /p>

2.  A new God is created for = both infrastructure and application. In this model, some new controller = monitors both application and infrastructure, holds the policies for = which application / user can have which resources, how much a user has = to be billed for a type of service, etc. You don’t have to = re-write your applications but you have to create an additional control = layer on top of infrastructure and application. You want this additional = layer to be as flat as possible, but allow sufficient abstractions for = easy control.

 <= /p>

These obviously entail = different architectures, from an application control standpoint. In the = first model, the application controls itself and the infrastructure. In = the second model, the application is also a resource along with = infrastructure, managed by some external = controller.

 <= /p>

Any discussion or = comments on these two models?

 <= /p>

Thanks, = Ashish

------_=_NextPart_001_01CCEFB2.8BD03799-- From agreenha@cisco.com Mon Feb 20 02:01:29 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9631221F8701 for ; Mon, 20 Feb 2012 02:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 rmtY1sASWIID for ; Mon, 20 Feb 2012 02:01:25 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id E5A8121F86FA for ; Mon, 20 Feb 2012 02:01:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=agreenha@cisco.com; l=2786; q=dns/txt; s=iport; t=1329732085; x=1330941685; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=gwp5vG0aAogp/HuIKUPH/atyktYApU4d05PcGb2ntWI=; b=CCqDvC+Sw9HH4BEj5j4s6A6AP6RBEOhKwXfNYafgWc2jFw0iaT0cCV9b agQSDwuRCQpdIiHJoz0GUjWWXG+7c81MrxL+vYaur/gd2RlS5r8Hogkx6 6OFoq8i7jIAAKmBtkD4dUNmjBvkwwd+JEQFLWHvtXnLztWIsaIpv910dP s=; X-IronPort-AV: E=Sophos;i="4.73,450,1325462400"; d="scan'208";a="129911270" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 20 Feb 2012 10:01:23 +0000 Received: from [64.103.94.23] ([64.103.94.23]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1KA1N8r015549; Mon, 20 Feb 2012 10:01:23 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Adam Greenhalgh In-Reply-To: <618BE8B40039924EB9AED233D4A09C510300242D@XMB-BGL-416.cisco.com> Date: Mon, 20 Feb 2012 10:02:56 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <618BE8B40039924EB9AED233D4A09C510300242D@XMB-BGL-416.cisco.com> To: sop@ietf.org X-Mailer: Apple Mail (2.1084) Cc: "Ashish Dalela \(adalela\)" Subject: Re: [sop] two architectures - which one do you prefer? X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 10:01:29 -0000 I suspect that in fact the model that might come to the fore is a hybrid = of these two, where the application is the "God" of a zone of the data = centre and a "Greater God" oversees the bigger picture for the whole = datacenter. The complexity is going to come from the interaction between = these "Gods".=20 Adam On 20 Feb 2012, at 09:32, Ashish Dalela (adalela) wrote: > =20 > BTW, these may not be the only architectures out there. So, if anyone = believes there are more architectures, it would be great to have that in = the discussion. I=92m just familiar with two of them, so hope to hear if = there are more. I realize that =93God=94 may be a strong word for some = people (J), but we could replace this with the word =93controller=94 = without loss of meaning. > =20 > Thanks, Ashish > =20 > From: Ashish Dalela (adalela)=20 > Sent: Monday, February 20, 2012 11:28 AM > To: sop@ietf.org > Subject: two architectures - which one do you prefer? > =20 > Folks, > =20 > There are two dominant architectures being pushed for cloud in the = industry today. > = =20 > 1. Application is the God of the datacenter. All infrastructure is = food supplied to the application to continue its operation, and = additional infrastructure is provisioned if an application asks for it. = The =93management=94 of the infrastructure is in the application, = because the infrastructure really exists for the purposes of the = application. You obviously have to often re-write or re-design or at the = least enhance your applications to be able to orchestrate the = infrastructure. > =20 > 2. A new God is created for both infrastructure and application. In = this model, some new controller monitors both application and = infrastructure, holds the policies for which application / user can have = which resources, how much a user has to be billed for a type of service, = etc. You don=92t have to re-write your applications but you have to = create an additional control layer on top of infrastructure and = application. You want this additional layer to be as flat as possible, = but allow sufficient abstractions for easy control. > =20 > These obviously entail different architectures, from an application = control standpoint. In the first model, the application controls itself = and the infrastructure. In the second model, the application is also a = resource along with infrastructure, managed by some external controller. > =20 > Any discussion or comments on these two models? > =20 > Thanks, Ashish > _______________________________________________ > sop mailing list > sop@ietf.org > https://www.ietf.org/mailman/listinfo/sop From adalela@cisco.com Mon Feb 20 02:21:18 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DBDF21F871A for ; Mon, 20 Feb 2012 02:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.258 X-Spam-Level: X-Spam-Status: No, score=-7.258 tagged_above=-999 required=5 tests=[AWL=3.341, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 NF0oIXOZgz5r for ; Mon, 20 Feb 2012 02:21:14 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id CBB6221F8710 for ; Mon, 20 Feb 2012 02:21:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=3134; q=dns/txt; s=iport; t=1329733274; x=1330942874; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=BAtvFXJtUyYOsNkE/tH75iKCmg97EnwG9XvZWTIwPDs=; b=lJMJBxguD978vjJFk4ehHW6FJQ4wf34Tpp+1g/wILdZdYXEOjjxNGP63 ai/OgxkMUtHHMdW6tfCBKY6+2XqmEIlSt4TO7Tu84Pb99qNM5yefpZ2b2 gIiJ/vEnHZ8cnm77xz0hLJJXEMtCwmfZQHcCMm7+aEI3zMCeZTyVXvkG0 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEAdQk+rRDoJ/2dsb2JhbABEskaBB4FzAQEBAwEBAQEPAR0KNBAHBAIBCBEEAQELBhgGASYoCAEBBAEKCAgah14JmyIBni4Ei38MDhVChAwPCoJQYwSITJ9g X-IronPort-AV: E=Sophos;i="4.73,450,1325462400"; d="scan'208";a="31300661" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 20 Feb 2012 10:21:13 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1KAKd6I028128 for ; Mon, 20 Feb 2012 10:21:13 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Feb 2012 15:51:08 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Feb 2012 15:51:07 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C510300246C@XMB-BGL-416.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sop] two architectures - which one do you prefer? Thread-Index: AczvtpvyZvkXZ/kRSbqYnEEmWjlmNwAAdx9Q References: <618BE8B40039924EB9AED233D4A09C510300242D@XMB-BGL-416.cisco.com> From: "Ashish Dalela (adalela)" To: "Adam Greenhalgh (agreenha)" , X-OriginalArrivalTime: 20 Feb 2012 10:21:08.0726 (UTC) FILETIME=[5C874960:01CCEFB9] Subject: Re: [sop] two architectures - which one do you prefer? X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 10:21:18 -0000 Yes, and a related model is that a zone (POD) has one type of application and that is controlled by a separate domain specific controller. So, you could tier the controllers. I guess I'm still wondering how "deep" the application wants to control the infrastructure.=20 Thanks, Ashish -----Original Message----- From: Adam Greenhalgh (agreenha)=20 Sent: Monday, February 20, 2012 3:33 PM To: sop@ietf.org Cc: Ashish Dalela (adalela) Subject: Re: [sop] two architectures - which one do you prefer? I suspect that in fact the model that might come to the fore is a hybrid of these two, where the application is the "God" of a zone of the data centre and a "Greater God" oversees the bigger picture for the whole datacenter. The complexity is going to come from the interaction between these "Gods".=20 Adam On 20 Feb 2012, at 09:32, Ashish Dalela (adalela) wrote: > =20 > BTW, these may not be the only architectures out there. So, if anyone believes there are more architectures, it would be great to have that in the discussion. I'm just familiar with two of them, so hope to hear if there are more. I realize that "God" may be a strong word for some people (J), but we could replace this with the word "controller" without loss of meaning. > =20 > Thanks, Ashish > =20 > From: Ashish Dalela (adalela)=20 > Sent: Monday, February 20, 2012 11:28 AM > To: sop@ietf.org > Subject: two architectures - which one do you prefer? > =20 > Folks, > =20 > There are two dominant architectures being pushed for cloud in the industry today. > > 1. Application is the God of the datacenter. All infrastructure is food supplied to the application to continue its operation, and additional infrastructure is provisioned if an application asks for it. The "management" of the infrastructure is in the application, because the infrastructure really exists for the purposes of the application. You obviously have to often re-write or re-design or at the least enhance your applications to be able to orchestrate the infrastructure. > =20 > 2. A new God is created for both infrastructure and application. In this model, some new controller monitors both application and infrastructure, holds the policies for which application / user can have which resources, how much a user has to be billed for a type of service, etc. You don't have to re-write your applications but you have to create an additional control layer on top of infrastructure and application. You want this additional layer to be as flat as possible, but allow sufficient abstractions for easy control. > =20 > These obviously entail different architectures, from an application control standpoint. In the first model, the application controls itself and the infrastructure. In the second model, the application is also a resource along with infrastructure, managed by some external controller. > =20 > Any discussion or comments on these two models? > =20 > Thanks, Ashish > _______________________________________________ > sop mailing list > sop@ietf.org > https://www.ietf.org/mailman/listinfo/sop From mphmmr@gmail.com Mon Feb 20 09:33:04 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47F621F87B3 for ; Mon, 20 Feb 2012 09:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.292 X-Spam-Level: X-Spam-Status: No, score=-3.292 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 55UL3-rxJiil for ; Mon, 20 Feb 2012 09:32:59 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9A121F858A for ; Mon, 20 Feb 2012 09:32:58 -0800 (PST) Received: by lahl5 with SMTP id l5so7602496lah.31 for ; Mon, 20 Feb 2012 09:32:58 -0800 (PST) Received-SPF: pass (google.com: domain of mphmmr@gmail.com designates 10.112.100.34 as permitted sender) client-ip=10.112.100.34; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mphmmr@gmail.com designates 10.112.100.34 as permitted sender) smtp.mail=mphmmr@gmail.com; dkim=pass header.i=mphmmr@gmail.com Received: from mr.google.com ([10.112.100.34]) by 10.112.100.34 with SMTP id ev2mr8301737lbb.13.1329759178051 (num_hops = 1); Mon, 20 Feb 2012 09:32:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DtmkjZm1gw+4W5/h4AFqWVZD6WxhIVkvUGoocWL+Bg8=; b=nIILWdUKfh7A6jDBMrkqkukNmu80jBN77LftdjH6Ojs/aEbVF7e4UhumLfWnEzct7j mMN1Ks/11ygHDjd6fYageDc+/UEhDUqb17APwp0CgSGTYV47k0H44uYxCB1FiwaJiXxW XUK7B0QgMrQasH/Qz4NiTGKCstxb07FD9F6WI= MIME-Version: 1.0 Received: by 10.112.100.34 with SMTP id ev2mr6904964lbb.13.1329759177895; Mon, 20 Feb 2012 09:32:57 -0800 (PST) Received: by 10.112.104.70 with HTTP; Mon, 20 Feb 2012 09:32:57 -0800 (PST) In-Reply-To: <618BE8B40039924EB9AED233D4A09C510300246C@XMB-BGL-416.cisco.com> References: <618BE8B40039924EB9AED233D4A09C510300242D@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C510300246C@XMB-BGL-416.cisco.com> Date: Mon, 20 Feb 2012 12:32:57 -0500 Message-ID: From: Michael Hammer To: "Ashish Dalela (adalela)" Content-Type: multipart/alternative; boundary=14dae9d2f3ca6f6eab04b968afc4 Cc: sop@ietf.org, "Adam Greenhalgh \(agreenha\)" Subject: Re: [sop] two architectures - which one do you prefer? X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 17:33:04 -0000 --14dae9d2f3ca6f6eab04b968afc4 Content-Type: text/plain; charset=ISO-8859-1 If you treat the "cloud" like a computer, then an OS needs to ensure that each application plays in its own sandbox and had minimal interactions with other applications. The only interaction being the sharing of computer, memory, and network resources. If you abdicate responsibility to the applications, then you have no security. That would not be good. I don't see how you would get around this. The fathers of the Internet confess that trusting the end-users to behave correctly because they were trust-worthy was a mistake. We should not make that mistake once again. Mike On Mon, Feb 20, 2012 at 5:21 AM, Ashish Dalela (adalela) wrote: > Yes, and a related model is that a zone (POD) has one type of > application and that is controlled by a separate domain specific > controller. So, you could tier the controllers. I guess I'm still > wondering how "deep" the application wants to control the > infrastructure. > > Thanks, Ashish > > -----Original Message----- > From: Adam Greenhalgh (agreenha) > Sent: Monday, February 20, 2012 3:33 PM > To: sop@ietf.org > Cc: Ashish Dalela (adalela) > Subject: Re: [sop] two architectures - which one do you prefer? > > I suspect that in fact the model that might come to the fore is a hybrid > of these two, where the application is the "God" of a zone of the data > centre and a "Greater God" oversees the bigger picture for the whole > datacenter. The complexity is going to come from the interaction between > these "Gods". > > Adam > > On 20 Feb 2012, at 09:32, Ashish Dalela (adalela) wrote: > > > > > BTW, these may not be the only architectures out there. So, if anyone > believes there are more architectures, it would be great to have that in > the discussion. I'm just familiar with two of them, so hope to hear if > there are more. I realize that "God" may be a strong word for some > people (J), but we could replace this with the word "controller" without > loss of meaning. > > > > Thanks, Ashish > > > > From: Ashish Dalela (adalela) > > Sent: Monday, February 20, 2012 11:28 AM > > To: sop@ietf.org > > Subject: two architectures - which one do you prefer? > > > > Folks, > > > > There are two dominant architectures being pushed for cloud in the > industry today. > > > > > 1. Application is the God of the datacenter. All infrastructure is > food supplied to the application to continue its operation, and > additional infrastructure is provisioned if an application asks for it. > The "management" of the infrastructure is in the application, because > the infrastructure really exists for the purposes of the application. > You obviously have to often re-write or re-design or at the least > enhance your applications to be able to orchestrate the infrastructure. > > > > 2. A new God is created for both infrastructure and application. In > this model, some new controller monitors both application and > infrastructure, holds the policies for which application / user can have > which resources, how much a user has to be billed for a type of service, > etc. You don't have to re-write your applications but you have to create > an additional control layer on top of infrastructure and application. > You want this additional layer to be as flat as possible, but allow > sufficient abstractions for easy control. > > > > These obviously entail different architectures, from an application > control standpoint. In the first model, the application controls itself > and the infrastructure. In the second model, the application is also a > resource along with infrastructure, managed by some external controller. > > > > Any discussion or comments on these two models? > > > > Thanks, Ashish > > _______________________________________________ > > sop mailing list > > sop@ietf.org > > https://www.ietf.org/mailman/listinfo/sop > > _______________________________________________ > sop mailing list > sop@ietf.org > https://www.ietf.org/mailman/listinfo/sop > --14dae9d2f3ca6f6eab04b968afc4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If you treat the "cloud" like a computer, then an OS needs to ens= ure that each application plays in its own sandbox and had minimal interact= ions with other applications. =A0The only interaction being the sharing of = computer, memory, and network resources.

If you abdicate responsibility to the applications, then you= have no security. =A0That would not be good.
I don't see how= you would get around this. =A0The fathers of the Internet confess that tru= sting the end-users to behave correctly because they were trust-worthy was = a =A0mistake. =A0We should not make that mistake once again.

Mike


On Mon, Feb 20, 2012 at 5:21 AM, Ashish Dalela (adalela) <adalela@cisco.com> wrote:
Yes, and a related model is that a zone (POD= ) has one type of
application and that is controlled by a separate domain specific
controller. So, you could tier the controllers. I guess I'm still
wondering how "deep" the application wants to control the
infrastructure.

Thanks, Ashish

-----Original Message-----
From: Adam Greenhalgh (agreenha)
Sent: Monday, February 20, 2012 3:33 PM
To: sop@ietf.org
Cc: Ashish Dalela (adalela)
Subject: Re: [sop] two architectures - which one do you prefer?

I suspect that in fact the model that might come to the fore is a hybrid of these two, where the application is the "God" of a zone of the= data
centre and a "Greater God" oversees the bigger picture for the wh= ole
datacenter. The complexity is going to come from the interaction between these "Gods".

Adam

On 20 Feb 2012, at 09:32, Ashish Dalela (adalela) wrote:

>
> BTW, these may not be the only architectures out there. So, if anyone<= br> believes there are more architectures, it would be great to have that in the discussion. I'm just familiar with two of them, so hope to hear if<= br> there are more. I realize that "God" may be a strong word for som= e
people (J), but we could replace this with the word "controller" = without
loss of meaning.
>
> Thanks, Ashish
>
> From: Ashish Dalela (adalela)
> Sent: Monday, February 20, 2012 11:28 AM
> To: sop@ietf.org
> Subject: two architectures - which one do you prefer?
>
> Folks,
>
> There are two dominant architectures being pushed for cloud in the
industry today.
>

> 1. =A0Application is the God of the datacenter. All infrastructure is<= br> food supplied to the application to continue its operation, and
additional infrastructure is provisioned if an application asks for it.
The "management" of the infrastructure is in the application, bec= ause
the infrastructure really exists for the purposes of the application.
You obviously have to often re-write or re-design or at the least
enhance your applications to be able to orchestrate the infrastructure.
>
> 2. =A0A new God is created for both infrastructure and application. In=
this model, some new controller monitors both application and
infrastructure, holds the policies for which application / user can have which resources, how much a user has to be billed for a type of service, etc. You don't have to re-write your applications but you have to creat= e
an additional control layer on top of infrastructure and application.
You want this additional layer to be as flat as possible, but allow
sufficient abstractions for easy control.
>
> These obviously entail different architectures, from an application control standpoint. In the first model, the application controls itself
and the infrastructure. In the second model, the application is also a
resource along with infrastructure, managed by some external controller. >
> Any discussion or comments on these two models?
>
> Thanks, Ashish
> _______________________________________________
> sop mailing list
> sop@ietf.org
> https://www.ietf.org/mailman/listinfo/sop

_______________________________________________
sop mailing list
sop@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sop

--14dae9d2f3ca6f6eab04b968afc4-- From vishwas.ietf@gmail.com Mon Feb 20 15:02:39 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9A921E801A for ; Mon, 20 Feb 2012 15:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.656 X-Spam-Level: X-Spam-Status: No, score=-3.656 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Ov8NOyP3slNa for ; Mon, 20 Feb 2012 15:02:38 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B487521E801B for ; Mon, 20 Feb 2012 15:02:33 -0800 (PST) Received: by obbwd15 with SMTP id wd15so8964121obb.31 for ; Mon, 20 Feb 2012 15:02:33 -0800 (PST) Received-SPF: pass (google.com: domain of vishwas.ietf@gmail.com designates 10.182.51.73 as permitted sender) client-ip=10.182.51.73; Authentication-Results: mr.google.com; spf=pass (google.com: domain of vishwas.ietf@gmail.com designates 10.182.51.73 as permitted sender) smtp.mail=vishwas.ietf@gmail.com; dkim=pass header.i=vishwas.ietf@gmail.com Received: from mr.google.com ([10.182.51.73]) by 10.182.51.73 with SMTP id i9mr6952587obo.17.1329778953417 (num_hops = 1); Mon, 20 Feb 2012 15:02:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=bIeh1Swurc4HdMeTMiYGCvJvoAd4d6D/FsICFeD5bzI=; b=p/wCKzmaEnlVeJUl8AuA6jrB+nno7XFALo6BcUPjezMB/NC1OpXlWhO+FbyA3j7RVw yfWuqGJY+bSU3LXw3+ic0hXoUgnnHUmCDjvAFriZxtnZOLC8s4lW+j9xdnGw40Wziaf5 FFd9Zi4IxMlJgoXgknIIm5UgBIiwUmdtm9I0g= MIME-Version: 1.0 Received: by 10.182.51.73 with SMTP id i9mr5951359obo.17.1329778953354; Mon, 20 Feb 2012 15:02:33 -0800 (PST) Received: by 10.182.165.1 with HTTP; Mon, 20 Feb 2012 15:02:33 -0800 (PST) Date: Mon, 20 Feb 2012 15:02:33 -0800 Message-ID: From: Vishwas Manral To: sop@ietf.org Content-Type: multipart/alternative; boundary=f46d044470db24fdc504b96d4ab7 Subject: [sop] SOP Requirements X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 23:02:39 -0000 --f46d044470db24fdc504b96d4ab7 Content-Type: text/plain; charset=ISO-8859-1 Hi authors, I did a first level pass through the SOP requirements document and my comments on the same are: 1. Do we really see incompatibilities in the API's soar for say IaaS? The AWS API's seem to be the default standard adopted by most providers. From the little I know OpenStack based API's may be the alternative way and companies have built bridging layers to inter-operate between the same. 2. Instead of the term customer/ user can we instead use the term "consumer". Something like "cloud subscriber" etc could be used. All I am saying is can we use standard terms here. 3. Is orchestration about creating services (from the cloud providers perspective), or an instance of a service (for a particular user)? I think it is the latter, but doesn't sound so from the definition. 4. How is Service Domain Name different from a URI? Aren't they the same? 5. Is Scenario -1 talking about all providers should provide the same services? I guess not. I think the idea should be the same set of services should be accessible from a cloud provider the same way. It however does not mean that all providers need to provide the same services, as it seems from the requirement. 6. It seems for most purposes you are talking about users, but as such a user in an enterprise should be unaware of where the service is coming from. It is the role of the customer to actually provide clear demarcation so a user is unaware of the same. Interoperability with virtual provider is how companies achieve the same. 7. I don't think you should mention providers should inter-operate with each other. That is a business decision. I think what you mean here is that providers should have a clear interoperable means should they wish to inter-operate. 8. Is it really a requirement for the Orchestration to allow inter-operation for all models? I would have thought we are focusing on the IaaS alone. 9. S-5 and S-3 sound like similar services to me. How are they different - vendor versus provider? 10. I think one of the key requirements for SOP, is the ability to work across only a sub-set of the base services and allow for extensible services on top. There could be so many variants of the SaaS or even PaaS I am not sure how you would make every service inter-operate. 11. I think when a VM is moved the biggest issue is the ability to move the storage along with it. All other state is minor and minimal. 12. Section 6 seems to be relevent within a cloud too and not just between clouds. 13. Doesn't CDN provide the ability to separate address and ability already? 14. For Service discovery. management we wrote something quite a while back https://datatracker.ietf.org/doc/draft-yokota-opsawg-virtnw-service-management/ . Thanks, Vishwas --f46d044470db24fdc504b96d4ab7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi authors,

I did a first level pass through the SOP requirements do= cument and my comments on the same are:

1. Do we really see incompat= ibilities in the API's soar for say IaaS? The AWS API's seem to be = the default standard adopted by most providers. From the little I know Open= Stack based API's may be the alternative way and companies have built b= ridging layers to inter-operate between the same.
2. Instead of the term customer/ user can we instead use the term "con= sumer". Something like "cloud subscriber" etc could be used.= All I am saying is can we use standard terms here.
3. Is orchestration = about creating services (from the cloud providers perspective), or an insta= nce of a service (for a particular user)? I think it is the latter, but doe= sn't sound so from the definition.
4. How is Service Domain Name different from a URI? Aren't they the sam= e?
5. Is Scenario -1 talking about all providers should provide the same= services? I guess not. I think the idea should be the same set of services= should be accessible from a cloud provider the same way. It however does n= ot mean that all providers need to provide the same services, as it seems f= rom the requirement.
6. It seems for most purposes you are talking about users, but as such a us= er in an enterprise should be unaware of where the service is coming from. = It is the role of the customer to actually provide clear demarcation so a u= ser is unaware of the same. Interoperability with virtual provider is how c= ompanies achieve the same.
7. I don't think you should mention providers should inter-operate with= each other. That is a business decision. I think what you mean here is tha= t providers should have a clear interoperable means should they wish to int= er-operate.
8. Is it really a requirement for the Orchestration to allow inter-operatio= n for all models? I would have thought we are focusing on the IaaS alone.9. S-5 and S-3 sound like similar services to me. How are they different = - vendor versus provider?
10. I think one of the key requirements for SOP, is the ability to work acr= oss only a sub-set of the base services and allow for extensible services o= n top. There could be so many variants of the SaaS or even PaaS I am not su= re how you would make every service inter-operate.
11. I think when a VM is moved the biggest issue is the ability to move the= storage along with it. All other state is minor and minimal.
12. Sectio= n 6 seems to be relevent within a cloud too and not just between clouds. 13. Doesn't CDN provide the ability to separate address and ability alr= eady?
14. For Service discovery. management we wrote something quite a w= hile back https://datatracker.ietf.org/doc/draft-yokota-op= sawg-virtnw-service-management/.

Thanks,
Vishwas
--f46d044470db24fdc504b96d4ab7-- From mphmmr@gmail.com Mon Feb 20 21:47:03 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8AAF21F848B for ; Mon, 20 Feb 2012 21:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 O5-L82vcUghs for ; Mon, 20 Feb 2012 21:47:01 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B883121F848A for ; Mon, 20 Feb 2012 21:47:00 -0800 (PST) Received: by lahl5 with SMTP id l5so587843lah.31 for ; Mon, 20 Feb 2012 21:46:59 -0800 (PST) Received-SPF: pass (google.com: domain of mphmmr@gmail.com designates 10.112.98.36 as permitted sender) client-ip=10.112.98.36; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mphmmr@gmail.com designates 10.112.98.36 as permitted sender) smtp.mail=mphmmr@gmail.com; dkim=pass header.i=mphmmr@gmail.com Received: from mr.google.com ([10.112.98.36]) by 10.112.98.36 with SMTP id ef4mr9013266lbb.55.1329803219604 (num_hops = 1); Mon, 20 Feb 2012 21:46:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L/dqD/UIrfohMf0eZQvf0ehG6/EEdirbH1I5YTkcyoI=; b=bRpWO4M6wQ2PWxOsV8lMjBS8ZQy2wXd8WZW65d567Zv0hfaYwLr62oFOM/sQcswRAL Jb1WN6zr9XIzyW+SDQZ2bG1Mr7HXjLBaH1moZ3Sjw63cwL00kRj6/rEKMRW+/LXoBrlQ qrpmYy9OfGP/O0GxvwrawMEMBS+YahrdaDzTE= MIME-Version: 1.0 Received: by 10.112.98.36 with SMTP id ef4mr7521089lbb.55.1329803219495; Mon, 20 Feb 2012 21:46:59 -0800 (PST) Received: by 10.112.104.70 with HTTP; Mon, 20 Feb 2012 21:46:59 -0800 (PST) In-Reply-To: References: Date: Tue, 21 Feb 2012 00:46:59 -0500 Message-ID: From: Michael Hammer To: Vishwas Manral Content-Type: multipart/alternative; boundary=bcaec554d66484ec5604b972f005 Cc: sop@ietf.org Subject: Re: [sop] SOP Requirements X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 05:47:03 -0000 --bcaec554d66484ec5604b972f005 Content-Type: text/plain; charset=ISO-8859-1 Vishwas, Thanks for reviewing. Inline... Mike On Mon, Feb 20, 2012 at 6:02 PM, Vishwas Manral wrote: > Hi authors, > > I did a first level pass through the SOP requirements document and my > comments on the same are: > > 1. Do we really see incompatibilities in the API's soar for say IaaS? The > AWS API's seem to be the default standard adopted by most providers. From > the little I know OpenStack based API's may be the alternative way and > companies have built bridging layers to inter-operate between the same. > Seem? May be? Bridging layers? I think you are making the case for us. :) I'm sure Ashish will have more to say about APIs, but I would prefer there be a de jure than a default, which in the long run is likely to change at the whim of a single company, and perhaps not in a direction that everyone would like. > 2. Instead of the term customer/ user can we instead use the term > "consumer". Something like "cloud subscriber" etc could be used. All I am > saying is can we use standard terms here. > We can settle on specific terms to use, just so long as we keep the distinction between the entity (enterprise?) that provisions the software in the cloud, and the user of that software, which could be an employee or a user in the general public. Using a SIP Proxy as a Service, the operator of the Proxy provisions it with a CREATE, but the user is the one sending INVITEs through it. Make sense? > 3. Is orchestration about creating services (from the cloud providers > perspective), or an instance of a service (for a particular user)? I think > it is the latter, but doesn't sound so from the definition. > Orchestration is about the on-demand provisioning of the compute/storage/network/XaaS in the cloud by the subscriber/customer. Once provisioned, the service can provide services to the intended user. We are trying to be general here. Need to keep provisioning and operations distinct. "Service" is occurring in levels. > 4. How is Service Domain Name different from a URI? Aren't they the same? > There is a distinction here between a class of services and running instantiations of those services. Either may be hierarchically named. > 5. Is Scenario -1 talking about all providers should provide the same > services? I guess not. I think the idea should be the same set of services > should be accessible from a cloud provider the same way. It however does > not mean that all providers need to provide the same services, as it seems > from the requirement. > Agree. All providers may not provide the same set of services. But, if two providers offer the same service, it should not require a new customer protocol stack to do so. And users should not know that they may be going to one provider or the other when using the same service. > 6. It seems for most purposes you are talking about users, but as such a > user in an enterprise should be unaware of where the service is coming > from. It is the role of the customer to actually provide clear demarcation > so a user is unaware of the same. Interoperability with virtual provider is > how companies achieve the same. > Agree, and we would like that to be true for multi-provider cases as well. I would go further to say that even a user not in the enterprise should be unaware where the service is coming from. > 7. I don't think you should mention providers should inter-operate with > each other. That is a business decision. I think what you mean here is that > providers should have a clear interoperable means should they wish to > inter-operate. > Yes. We want them to be able to inter-operate. Whether they want to is a business decision. > 8. Is it really a requirement for the Orchestration to allow > inter-operation for all models? I would have thought we are focusing on the > IaaS alone. > We don't see a reason to limit it to just IaaS. We are looking several years down the road here. > 9. S-5 and S-3 sound like similar services to me. How are they different - > vendor versus provider? > We were considering cases where multiple companies are involved in providing all the capabilities needed. One involved coordination within an administrative domain, while the other involves independent administrative domains. We didn't want to limit this to single company operations. Large global providers may involve many companies. > 10. I think one of the key requirements for SOP, is the ability to work > across only a sub-set of the base services and allow for extensible > services on top. There could be so many variants of the SaaS or even PaaS I > am not sure how you would make every service inter-operate. > There needs to be several layers of standards involved. This is an onion not a single layer orange-peel. Here we are trying to provide structure that allows easy extension, substitution, and innovation at the more service-specific granular levels. > 11. I think when a VM is moved the biggest issue is the ability to move > the storage along with it. All other state is minor and minimal. > I would say the networking is the biggest issue, but that is my bias. :0 > 12. Section 6 seems to be relevent within a cloud too and not just between > clouds. > Agree. Internal to a cloud and from the customer to the cloud are the simple cases. We emphasize the inter-cloud cases to test the architecture for the worst cases. > 13. Doesn't CDN provide the ability to separate address and ability > already? > Probably needs more discussion. I see content as a specific scenario. There you don't care which copy of data is accessed so long as you reach it. In other types of services, a lot more control over who accesses what is needed. > 14. For Service discovery. management we wrote something quite a while > back > https://datatracker.ietf.org/doc/draft-yokota-opsawg-virtnw-service-management/ > . > > Will take a look. Thanks. Mike > Thanks, > Vishwas > > _______________________________________________ > sop mailing list > sop@ietf.org > https://www.ietf.org/mailman/listinfo/sop > > --bcaec554d66484ec5604b972f005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Vishwas,

Thanks for reviewing. =A0Inline...
Mike

On Mon, Feb 20, 2012 at= 6:02 PM, Vishwas Manral <vishwas.ietf@gmail.com> wrote:
Hi authors,

I did a first level pass = through the SOP requirements document and my comments on the same are:
<= br> 1. Do we really see incompatibilities in the API's soar for say IaaS? T= he AWS API's seem to be the default standard adopted by most providers.= From the little I know OpenStack based API's may be the alternative wa= y and companies have built bridging layers to inter-operate between the sam= e.

Seem? =A0May be? =A0Bridging layers? =A0I = think you are making the case for us. :)
I'm sure Ashish will= have more to say about APIs, but I would prefer there be a de jure than a = default, which in the long run is likely to change at the whim of a single = company, and perhaps not in a direction that everyone would like.
=A0
2. Instead of the term customer/ user can we instead use the term "con= sumer". Something like "cloud subscriber" etc could be used.= All I am saying is can we use standard terms here.

We can settle on specific terms to use, just so long as we k= eep the distinction between the entity (enterprise?) that provisions the so= ftware in the cloud, and the user of that software, which could be an emplo= yee or a user in the general public. =A0Using a SIP Proxy as a Service, the= operator of the Proxy provisions it with a CREATE, but the user is the one= sending INVITEs through it. =A0Make sense?
=A0
3. Is orchestration about crea= ting services (from the cloud providers perspective), or an instance of a s= ervice (for a particular user)? I think it is the latter, but doesn't s= ound so from the definition.

Orchestration is about the on-demand provi= sioning of the compute/storage/network/XaaS in the cloud by the subscriber/= customer. =A0Once provisioned, the service can provide services to the inte= nded user. =A0We are trying to be general here. =A0Need to keep provisionin= g and operations distinct. =A0"Service" is occurring in levels.
=A0
4. How is Service Domain Name different from a URI? Aren't they the sam= e?

There is a distinction here between = a class of services and running instantiations of those services. =A0Either= may be hierarchically named.
=A0
5. Is Scenario -1 talking abou= t all providers should provide the same services? I guess not. I think the = idea should be the same set of services should be accessible from a cloud p= rovider the same way. It however does not mean that all providers need to p= rovide the same services, as it seems from the requirement.

Agree. =A0All providers may not provide th= e same set of services. =A0
But, if two providers offer the same = service, it should not require a new customer protocol stack to do so.
And users should not know that they may be going to one provider or th= e other when using the same service.
=A0
6. It seems for most purposes you are talking about users, but as such a us= er in an enterprise should be unaware of where the service is coming from. = It is the role of the customer to actually provide clear demarcation so a u= ser is unaware of the same. Interoperability with virtual provider is how c= ompanies achieve the same.

Agree, and we would like that to be true f= or multi-provider cases as well.
I would go further to say that e= ven a user not in the enterprise should be unaware where the service is com= ing from.
=A0
7. I don't think you should mention providers should inter-operate with= each other. That is a business decision. I think what you mean here is tha= t providers should have a clear interoperable means should they wish to int= er-operate.

Yes. =A0We want them to be able to inter-o= perate. =A0Whether they want to is a business decision.
=A0
=
8. Is it really a requirement for the Orchestration to allow inter-operatio= n for all models? I would have thought we are focusing on the IaaS alone.

We don't see a reason to limit it to= just IaaS. =A0We are looking several years down the road here.
=A0
9. S-5 and S-3 sound like simi= lar services to me. How are they different - vendor versus provider?

We were considering cases where multiple companies are = involved in providing all the capabilities needed. =A0One involved coordina= tion within an administrative domain, while the other involves independent = administrative domains. =A0We didn't want to limit this to single compa= ny operations. =A0Large global providers may involve many companies.
=A0
10. I think one of the key requirements for SOP, is the ability to work acr= oss only a sub-set of the base services and allow for extensible services o= n top. There could be so many variants of the SaaS or even PaaS I am not su= re how you would make every service inter-operate.

There needs to be several layers of standa= rds involved. =A0This is an onion not a single layer orange-peel.
Here we are trying to provide structure that allows easy extension, substi= tution, and innovation at the more service-specific granular levels.
=A0
11. I think when a VM is moved the biggest issue is the ability to move the= storage along with it. All other state is minor and minimal.

I would say the networking is the biggest issue, but= that is my bias. =A0:0
=A0
12. Section 6 seems to be rele= vent within a cloud too and not just between clouds.
<= br>
Agree. =A0Internal to a cloud and from the customer to the cloud= are the simple cases. =A0
We emphasize the inter-cloud cases to = test the architecture for the worst cases.
=A0
13. Doesn't CDN provide the ability to separate address and ability alr= eady?

Probably needs more discussion. = =A0I see content as a specific scenario. =A0There you don't care which = copy of data is accessed so long as you reach it. =A0In other types of serv= ices, a lot more control over who accesses what is needed.
=A0
14. For Service discovery. man= agement we wrote something quite a while back https://datatracker.ietf.org/doc/draft-yokota-opsawg-virtnw-service-m= anagement/.

Will take a look. =A0Thanks. =A0Mike
=A0
Thanks,
Vishwas

_______________________________________________
sop mailing list
sop@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sop


--bcaec554d66484ec5604b972f005-- From mphmmr@gmail.com Thu Feb 23 08:57:21 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9367821F871D for ; Thu, 23 Feb 2012 08:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.353 X-Spam-Level: X-Spam-Status: No, score=-3.353 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 6+b4RqVSjYgG for ; Thu, 23 Feb 2012 08:57:20 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 147E721F8712 for ; Thu, 23 Feb 2012 08:57:19 -0800 (PST) Received: by lahl5 with SMTP id l5so2013395lah.31 for ; Thu, 23 Feb 2012 08:57:19 -0800 (PST) Received-SPF: pass (google.com: domain of mphmmr@gmail.com designates 10.152.123.68 as permitted sender) client-ip=10.152.123.68; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mphmmr@gmail.com designates 10.152.123.68 as permitted sender) smtp.mail=mphmmr@gmail.com; dkim=pass header.i=mphmmr@gmail.com Received: from mr.google.com ([10.152.123.68]) by 10.152.123.68 with SMTP id ly4mr1874505lab.13.1330016239062 (num_hops = 1); Thu, 23 Feb 2012 08:57:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=G6DsqIV3yyDoiENsMuXdwN1eZtzXqabelCXjZ2QqwXM=; b=N0IMt1AtUtw4jUV5mBuUF/m608C7x7fk6maiF6GrH/AG3rxVAq4hB2Q8kVEgP8gl+J YXy8EV2cQaGclRwyvjP/76tGxun8HelL/Qo/xRv7eMy5v2V05YBka4nVmKw1EkB8tG5A hwkJ5sp4+nnOxNOA3+ORBeWDqQj6upqMXoxqw= MIME-Version: 1.0 Received: by 10.152.123.68 with SMTP id ly4mr1577469lab.13.1330016238943; Thu, 23 Feb 2012 08:57:18 -0800 (PST) Received: by 10.112.104.70 with HTTP; Thu, 23 Feb 2012 08:57:18 -0800 (PST) Date: Thu, 23 Feb 2012 11:57:18 -0500 Message-ID: From: Michael Hammer To: sop@ietf.org Content-Type: multipart/alternative; boundary=f46d044268e077be4704b9a48985 Subject: [sop] SOP and SDN Question X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 16:57:21 -0000 --f46d044268e077be4704b9a48985 Content-Type: text/plain; charset=ISO-8859-1 All, I saw some questions asking what is the difference between SOP and SDN/OF. So, I did a quick review of the SDN BOF presentations. Here is some food for thought: 1) The SDN Problem Statement is more narrowly focused on network and doesn't address other important cloud elements of compute and storage, nor the additional layers that make up PaaS and SaaS. So, I am thinking that difference is really in the scope of perspective. SOP is about how to specify what cloud consumer needs the cloud to do, while SDN is in the weeds on how to do the network portion. What does SDN do for compute and storage? Nothing. SOP provides a means to reference and stitch together those disparate pieces. One presentation shows a lack of coordination by hypervisor with the underlying network, but then just moves the "solution" to the network layer, without showing how coordination between the IT and C (network) is sync'd. Now imagine if those IT resources are split across multiple clouds/DCs. Isolation of network from the IT side could lead to disconnect amongst unified ITC service components. We believe SOP enables a coordinated solution. 2) Some quotes from the BOF presentations: "OpenFlow does not configure, boot, or maintain a box". "Enabling programmatic automation of configuration, management, monitoring, data mining, ... is largely orthogonal to OF/SDN" Well, SOP is there to boot, configure, and maintain the various layers of those boxes. It is about replacing slow-time-scale management etc. with on-demand signaling and control. Cloud is about provisioning on-demand, in other words configuring and booting resources in the Cloud/DC. So, something missing here. I get the feeling that OpenFlow is more like assembly-language level execution of a macro-command. With SOP we are focused on the macro-command level, within which an admin domain might get implemented by low-level openflow execution. 3) SDN seems to focus on replacing current generation static network management configuration versus focusing on the dynamic on-demand external customer aspects. Would love to see security implications on SDN. I could see an inter-domain SOP request fanning out to IT (host) and network (SDN) control signaling components, where the SDN replaces some existing management controls. We are trying to address the cloud-bursting scenarios that cross admin domains. The last slide of the operator's perspective gives insight to what we want SOP to address. 4) Perhaps the best way of explaining this is by analogy. The essence of SDN/OF appears to be the separation of the control plane from the data (forwarding) plane. So, where have I heard that before? Those working in the VoIP space are probably very familiar with the separation between the Media Gateway Controller and the Media Gateways using either MGCP or H.248. Or how about the Media Resource Control Protocol? Those are examples of vertical control protocols, where a master controller manages multiple slave components within a single admin domain. Now contrast that with a signaling and control protocol such as SIP or H.323 that interoperate horizontally between admin domains. Just as SIP and MGCP perform complementary roles for VoIP, we see SOP and SDN/OF performing complementary roles in the cloud space. Finally, imagine what cloud services means in terms of delivery of hardware and software by vendors to both customer (enterprise) and cloud SP (e.g. carrier) domains. If the blade, disk, bridge, and router hardware can, like a chameleon, take on a different character depending on the firmware and software layered on top, then there needs to be a way to remotely provision and configure those IaaS, PaaS, SaaS software layers, be it colored Cisco, Juniper, Dell, HP, IBM, Microsoft, Linux, or whatever. The nature of communications is that it works best when both ends are fully interoperable. So, while a private enterprise cloud will need to push an on-demand service request to one or more public clouds, both those clouds may need to "rent" various layers of cloud software either prior to or following that cloudburst from multiple players in the vendor community. A standardized protocol for service orchestration for all those cloud layers enables that. We are already seeing such on-demand ecosystems becoming reality in the Unified Communications space with the movement of IP-PBXs onto DCs as well as IMS components. If those can be provided on-demand to meet the capacity needs of the customer/carrier, then what stops any other type of cloud software from doing the same? Mike --f46d044268e077be4704b9a48985 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All,

I saw some questions asking what is the difference = between SOP and SDN/OF. =A0
So, I did a quick review of the SDN B= OF presentations.
Here is some food for thought:

1) The=A0SDN Problem Statement is more narrowly focused on network and= doesn't address=A0
other important cloud elements of compute= and storage, nor the additional layers that make=A0
up PaaS and = SaaS. =A0So, I am thinking that difference is really in the scope of perspe= ctive. =A0
SOP is about how to specify what cloud consumer needs the cloud t= o do,=A0while SDN is in=A0
the weeds on how to do the network por= tion. =A0What does SDN do for compute and storage?
Nothing. =A0SO= P provides a means to reference and stitch together those disparate pieces.=

One presentation shows a la= ck of coordination by hypervisor with the underlying network,=A0
but then just moves the "solution" to the network layer, wi= thout showing how coordination
between the IT and C (network) is sync'd. =A0Now imagine if = those IT resources are split=A0
across multiple clouds/DCs.= =A0Isolation of network from the IT side could lead to disconnect=A0
=
amongst unified ITC service components. =A0We believe SOP enables a coordin= ated solution.

2) =A0= Some quotes from the BOF presentations:
=A0 =A0=A0"OpenFlow = does not configure, boot, or maintain a box".
=A0 =A0 "Enabling=A0programmatic=A0automation=A0o= f=A0configuration,=A0management,=A0
=A0 =A0 =A0monitoring,=A0data= =A0mining, ...=A0is=A0largely=A0orthogonal=A0to=A0OF/SDN" =A0
Well, SOP is there to boot, configure, and maintain the vario= us layers of those boxes.
It is about replacing slow-time-scale management etc. with on-de= mand signaling and control.
Cloud is about provisioning on-= demand, in other words configuring and booting resources=A0
in th= e Cloud/DC. =A0So, something missing here. =A0I get the feeling that OpenFl= ow is more like=A0
assembly-language level execution of a macro-command. =A0With SOP we a= re focused on the=A0
macro-command level,=A0within=A0which an adm= in domain might get=A0implemented by low-level=A0
openflow execut= ion.

3) =A0SDN seems to focus on replacing current generatio= n static network management configuration=A0
versus focusing on t= he dynamic on-demand external customer aspects. =A0Would love to see securi= ty=A0
implications on SDN. =A0I could see an inter-domain SOP request fannin= g out to IT (host) and network (SDN)=A0
control signaling compone= nts, where the SDN replaces some existing management controls.
We= are trying to address the cloud-bursting scenarios that cross admin domain= s.
The last slide of the operator's perspective gives insight to what= we want SOP to address.

4) =A0Perhaps = the best way of explaining this is by analogy. =A0The essence of SDN/OF app= ears to be
the separation of the control plane from the data (forward= ing) plane. =A0So, where have I heard that before?
Those wo= rking in the VoIP space are probably very familiar with the separation betw= een the
Media Gateway Controller and the Media Gateways using either MGC= P or H.248. =A0
Or how about the=A0Media Resource Control P= rotocol? =A0Those are examples of vertical control protocols,=A0
where a master controller manages multiple=A0slave components within a sing= le admin domain. =A0
Now contrast that with a signaling and= control=A0protocol such as SIP or H.323 that interoperate=A0
horizontally between admin domains. =A0Just as=A0SIP and MGCP perform co= mplementary roles for VoIP,=A0
we see SOP and SDN/OF=A0performing complementary roles in the cl= oud space.

Finally, imagine what cloud= services means in terms of delivery of hardware and software by vendors
to both customer (enterprise) and cloud SP (e.g. carrier) domain= s. =A0If the blade, disk, bridge, and router hardware
can, = like a chameleon, take on a different character depending on the firmware a= nd software layered on top,
then there needs to be a way to remotely provision and configure= those IaaS, PaaS, SaaS software layers,=A0
be it colored= =A0Cisco, Juniper, Dell, HP, IBM, Microsoft, Linux, or whatever. =A0
<= div style> The nature of communications is that it works=A0best when both ends are ful= ly interoperable. =A0

So, while a priv= ate enterprise cloud will need to push an=A0on-demand=A0service request =A0= to one or more public clouds,
both those clouds may need to "rent" various layers of= cloud software either prior to or following that cloudburst
from multiple players in the vendor community. =A0
A stan= dardized protocol for service orchestration for all those cloud layers enab= les that.

We are already seeing such on-demand ecosys= tems becoming reality in the Unified Communications space
w= ith the movement of IP-PBXs onto DCs as well as IMS components. =A0

If those can be provided on-demand=A0to mee= t the capacity needs of the customer/carrier,=A0
then what = stops any other type of cloud software from doing the same?

Mike

--f46d044268e077be4704b9a48985-- From mphmmr@gmail.com Fri Feb 24 07:02:13 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F90521F86E8 for ; Fri, 24 Feb 2012 07:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.435 X-Spam-Level: X-Spam-Status: No, score=-3.435 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 eVhG7p0fm-pa for ; Fri, 24 Feb 2012 07:02:12 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id DC82021F86E3 for ; Fri, 24 Feb 2012 07:02:03 -0800 (PST) Received: by lahl5 with SMTP id l5so3430599lah.31 for ; Fri, 24 Feb 2012 07:02:02 -0800 (PST) Received-SPF: pass (google.com: domain of mphmmr@gmail.com designates 10.152.125.20 as permitted sender) client-ip=10.152.125.20; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mphmmr@gmail.com designates 10.152.125.20 as permitted sender) smtp.mail=mphmmr@gmail.com; dkim=pass header.i=mphmmr@gmail.com Received: from mr.google.com ([10.152.125.20]) by 10.152.125.20 with SMTP id mm20mr2135280lab.6.1330095722933 (num_hops = 1); Fri, 24 Feb 2012 07:02:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=f7lx8wdf8/wrTMCqi08/N66KTE4CVNAdWhYVsuizvdA=; b=kkt8bjQMjyJiXjhUrANg7Rr1IlrhXFQOEnJWABJm7WlcZB7kM5bEiOM5zE++jnlj01 l5RWSWhhH3ytQrwYq8CNpKGjrxL4uZTo9+RB4ArzU8uPqLKTd3eQScXKVnC3FkaDJkFS XWCK2uC/7gR6AtpFAcUlnyB+1Hv2Ws5XaJ9Dc= MIME-Version: 1.0 Received: by 10.152.125.20 with SMTP id mm20mr1775064lab.6.1330095722826; Fri, 24 Feb 2012 07:02:02 -0800 (PST) Received: by 10.112.104.70 with HTTP; Fri, 24 Feb 2012 07:02:02 -0800 (PST) In-Reply-To: References: Date: Fri, 24 Feb 2012 10:02:02 -0500 Message-ID: From: Michael Hammer To: sop@ietf.org Content-Type: multipart/alternative; boundary=f46d04374589138bc804b9b70bc7 Subject: [sop] Fwd: SOP and SDN Question X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 15:02:13 -0000 --f46d04374589138bc804b9b70bc7 Content-Type: text/plain; charset=ISO-8859-1 Resending. ---------- Forwarded message ---------- From: Michael Hammer Date: Thu, Feb 23, 2012 at 11:57 AM Subject: SOP and SDN Question To: sop@ietf.org All, I saw some questions asking what is the difference between SOP and SDN/OF. So, I did a quick review of the SDN BOF presentations. Here is some food for thought: 1) The SDN Problem Statement is more narrowly focused on network and doesn't address other important cloud elements of compute and storage, nor the additional layers that make up PaaS and SaaS. So, I am thinking that difference is really in the scope of perspective. SOP is about how to specify what cloud consumer needs the cloud to do, while SDN is in the weeds on how to do the network portion. What does SDN do for compute and storage? Nothing. SOP provides a means to reference and stitch together those disparate pieces. One presentation shows a lack of coordination by hypervisor with the underlying network, but then just moves the "solution" to the network layer, without showing how coordination between the IT and C (network) is sync'd. Now imagine if those IT resources are split across multiple clouds/DCs. Isolation of network from the IT side could lead to disconnect amongst unified ITC service components. We believe SOP enables a coordinated solution. 2) Some quotes from the BOF presentations: "OpenFlow does not configure, boot, or maintain a box". "Enabling programmatic automation of configuration, management, monitoring, data mining, ... is largely orthogonal to OF/SDN" Well, SOP is there to boot, configure, and maintain the various layers of those boxes. It is about replacing slow-time-scale management etc. with on-demand signaling and control. Cloud is about provisioning on-demand, in other words configuring and booting resources in the Cloud/DC. So, something missing here. I get the feeling that OpenFlow is more like assembly-language level execution of a macro-command. With SOP we are focused on the macro-command level, within which an admin domain might get implemented by low-level openflow execution. 3) SDN seems to focus on replacing current generation static network management configuration versus focusing on the dynamic on-demand external customer aspects. Would love to see security implications on SDN. I could see an inter-domain SOP request fanning out to IT (host) and network (SDN) control signaling components, where the SDN replaces some existing management controls. We are trying to address the cloud-bursting scenarios that cross admin domains. The last slide of the operator's perspective gives insight to what we want SOP to address. 4) Perhaps the best way of explaining this is by analogy. The essence of SDN/OF appears to be the separation of the control plane from the data (forwarding) plane. So, where have I heard that before? Those working in the VoIP space are probably very familiar with the separation between the Media Gateway Controller and the Media Gateways using either MGCP or H.248. Or how about the Media Resource Control Protocol? Those are examples of vertical control protocols, where a master controller manages multiple slave components within a single admin domain. Now contrast that with a signaling and control protocol such as SIP or H.323 that interoperate horizontally between admin domains. Just as SIP and MGCP perform complementary roles for VoIP, we see SOP and SDN/OF performing complementary roles in the cloud space. Finally, imagine what cloud services means in terms of delivery of hardware and software by vendors to both customer (enterprise) and cloud SP (e.g. carrier) domains. If the blade, disk, bridge, and router hardware can, like a chameleon, take on a different character depending on the firmware and software layered on top, then there needs to be a way to remotely provision and configure those IaaS, PaaS, SaaS software layers, be it colored Cisco, Juniper, Dell, HP, IBM, Microsoft, Linux, or whatever. The nature of communications is that it works best when both ends are fully interoperable. So, while a private enterprise cloud will need to push an on-demand service request to one or more public clouds, both those clouds may need to "rent" various layers of cloud software either prior to or following that cloudburst from multiple players in the vendor community. A standardized protocol for service orchestration for all those cloud layers enables that. We are already seeing such on-demand ecosystems becoming reality in the Unified Communications space with the movement of IP-PBXs onto DCs as well as IMS components. If those can be provided on-demand to meet the capacity needs of the customer/carrier, then what stops any other type of cloud software from doing the same? Mike --f46d04374589138bc804b9b70bc7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Resending.

---------- Forwarded message -= ---------
From: Michael Hammer <mphmmr@gmail.com>=
Date: Thu, Feb 23, 2012 at 11:57 AM
Subject: SOP and SDN Question
To:= sop@ietf.org


All,

<= /div>
I saw some questions asking what is the difference between SOP an= d SDN/OF. =A0
So, I did a quick review of the SDN BOF presentations.
Here = is some food for thought:

1) The=A0SDN Problem Statement is more narrowly focused on network and= doesn't address=A0
other important cloud elements of compute= and storage, nor the additional layers that make=A0
up PaaS and = SaaS. =A0So, I am thinking that difference is really in the scope of perspe= ctive. =A0
SOP is about how to specify what cloud consumer needs the cloud t= o do,=A0while SDN is in=A0
the weeds on how to do the network por= tion. =A0What does SDN do for compute and storage?
Nothing. =A0SO= P provides a means to reference and stitch together those disparate pieces.=

One presentation shows a lack of coordi= nation by hypervisor with the underlying network,=A0
but then jus= t moves the "solution" to the network layer, without showing how = coordination
between the IT and C (network) is sync'd. =A0Now imagine if those = IT resources are split=A0
across multiple clouds/DCs. =A0Isolatio= n of network from the IT side could lead to disconnect=A0
amongst unified ITC service components. =A0We believe SOP enables a coordin= ated solution.

2) =A0Some q= uotes from the BOF presentations:
=A0 =A0=A0"OpenFlow does n= ot configure, boot, or maintain a box".
=A0 =A0 "Enabling=A0programmatic=A0automation=A0of=A0co= nfiguration,=A0management,=A0
=A0 =A0 =A0monitoring,=A0data=A0min= ing, ...=A0is=A0largely=A0orthogonal=A0to=A0OF/SDN" =A0
Well, SOP is there to boot, configure, and maintain the various layers of= those boxes.
It is about replacing slow-time-scale management etc. with on-demand s= ignaling and control.
Cloud is about provisioning on-demand= , in other words configuring and booting resources=A0
in the Clou= d/DC. =A0So, something missing here. =A0I get the feeling that OpenFlow is = more like=A0
assembly-language level execution of a macro-command. =A0With SOP we a= re focused on the=A0
macro-command level,=A0within=A0which an adm= in domain might get=A0implemented by low-level=A0
openflow execut= ion.

3) =A0SDN seems to focus on replacing current generatio= n static network management configuration=A0
versus focusing on t= he dynamic on-demand external customer aspects. =A0Would love to see securi= ty=A0
implications on SDN. =A0I could see an inter-domain SOP request fannin= g out to IT (host) and network (SDN)=A0
control signaling compone= nts, where the SDN replaces some existing management controls.
We= are trying to address the cloud-bursting scenarios that cross admin domain= s.
The last slide of the operator's perspective gives insight to what= we want SOP to address.

4) =A0Perhaps the be= st way of explaining this is by analogy. =A0The essence of SDN/OF appears t= o be
the separation of the control plane from the data (forwarding) p= lane. =A0So, where have I heard that before?
Those working in the= VoIP space are probably very familiar with the separation between the
Media Gateway Controller and the Media Gateways using either MGCP or H= .248. =A0
Or how about the=A0Media Resource Control Protocol? =A0= Those are examples of vertical control protocols,=A0
where a master controller manages multiple=A0slave components within a sing= le admin domain. =A0
Now contrast that with a signaling and contr= ol=A0protocol such as SIP or H.323 that interoperate=A0
horizonta= lly between admin domains. =A0Just as=A0SIP and MGCP perform complementary = roles for VoIP,=A0
we see SOP and SDN/OF=A0performing complementary roles in the cloud sp= ace.

Finally, imagine what cloud services means in= terms of delivery of hardware and software by vendors
to both customer (enterprise) and cloud SP (e.g. carrier) domains. =A0= If the blade, disk, bridge, and router hardware
can, like a chame= leon, take on a different character depending on the firmware and software = layered on top,
then there needs to be a way to remotely provision and configure those= IaaS, PaaS, SaaS software layers,=A0
be it colored=A0Cisco, Juni= per, Dell, HP, IBM, Microsoft, Linux, or whatever. =A0
The nature of communications is that it works=A0best when both ends are ful= ly interoperable. =A0

So, while a private enterpri= se cloud will need to push an=A0on-demand=A0service request =A0to one or mo= re public clouds,
both those clouds may need to "rent" various layers of cloud= software either prior to or following that cloudburst
from multi= ple players in the vendor community. =A0
A standardized protocol = for service orchestration for all those cloud layers enables that.

We are already seeing such on-demand ecosystems becomin= g reality in the Unified Communications space
with the movement o= f IP-PBXs onto DCs as well as IMS components. =A0

If those can be provided on-demand=A0to meet the capaci= ty needs of the customer/carrier,=A0
then what stops any other ty= pe of cloud software from doing the same?

Mike


--f46d04374589138bc804b9b70bc7-- From tnadeau@lucidvision.com Fri Feb 24 07:12:33 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD2E21F882F for ; Fri, 24 Feb 2012 07:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 amXr6VZrgV6I for ; Fri, 24 Feb 2012 07:12:30 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 16A0421F8813 for ; Fri, 24 Feb 2012 07:12:30 -0800 (PST) Received: from [10.100.68.228] (unknown [141.202.11.155]) by lucidvision.com (Postfix) with ESMTP id 0F2FC142262; Fri, 24 Feb 2012 10:12:29 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_AF3778ED-7572-4CD6-8BA0-05F7B82B4822" From: Thomas Nadeau In-Reply-To: Date: Fri, 24 Feb 2012 10:12:31 -0500 Message-Id: <353D9CCB-2576-4A88-AAFC-DCE82FAF1101@lucidvision.com> References: To: Michael Hammer X-Mailer: Apple Mail (2.1257) Cc: sdnp@lucidvision.com, sop@ietf.org Subject: Re: [sop] Fwd: SOP and SDN Question X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 15:12:33 -0000 --Apple-Mail=_AF3778ED-7572-4CD6-8BA0-05F7B82B4822 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Feb 24, 2012, at 10:02 AM, Michael Hammer wrote: > Resending. >=20 > ---------- Forwarded message ---------- > From: Michael Hammer > Date: Thu, Feb 23, 2012 at 11:57 AM > Subject: SOP and SDN Question > To: sop@ietf.org >=20 >=20 > All, >=20 > I saw some questions asking what is the difference between SOP and = SDN/OF. =20 > So, I did a quick review of the SDN BOF presentations. > Here is some food for thought: >=20 > 1) The SDN Problem Statement is more narrowly focused on network and = doesn't address=20 > other important cloud elements of compute and storage, nor the = additional layers that make=20 > up PaaS and SaaS. So, I am thinking that difference is really in the = scope of perspective. =20 > SOP is about how to specify what cloud consumer needs the cloud to do, = while SDN is in=20 > the weeds on how to do the network portion. What does SDN do for = compute and storage? > Nothing. SOP provides a means to reference and stitch together those = disparate pieces. I guess my question is (and I think Ping asked this too) is = how/why does SOP differ from OpenStack, or where does it fit into that model. You can imagine = using OpenStack to do=20 just what you are describing. Basically at a high level, you are = specifying service management - which handles most of the XaaS cases I think. > One presentation shows a lack of coordination by hypervisor with the = underlying network,=20 > but then just moves the "solution" to the network layer, without = showing how coordination > between the IT and C (network) is sync'd. Now imagine if those IT = resources are split=20 > across multiple clouds/DCs. Isolation of network from the IT side = could lead to disconnect=20 > amongst unified ITC service components. We believe SOP enables a = coordinated solution. Fair point, but again why and how does this differ from what = OpenStack gives you today? > 2) Some quotes from the BOF presentations: > "OpenFlow does not configure, boot, or maintain a box". > "Enabling programmatic automation of configuration, management,=20 > monitoring, data mining, ... is largely orthogonal to OF/SDN" =20 > Well, SOP is there to boot, configure, and maintain the various layers = of those boxes. > It is about replacing slow-time-scale management etc. with on-demand = signaling and control. > Cloud is about provisioning on-demand, in other words configuring and = booting resources=20 > in the Cloud/DC. So, something missing here. I get the feeling that = OpenFlow is more like=20 > assembly-language level execution of a macro-command. With SOP we are = focused on the=20 > macro-command level, within which an admin domain might get = implemented by low-level=20 > openflow execution. >=20 > 3) SDN seems to focus on replacing current generation static network = management configuration=20 > versus focusing on the dynamic on-demand external customer aspects. = Would love to see security=20 > implications on SDN. I could see an inter-domain SOP request fanning = out to IT (host) and network (SDN)=20 > control signaling components, where the SDN replaces some existing = management controls. > We are trying to address the cloud-bursting scenarios that cross admin = domains. > The last slide of the operator's perspective gives insight to what we = want SOP to address. I would characterize Software Driven Networks (SDrN) as you = describe, but Software Defined Networks (SDfN) (or what we have been working on in the SDNp effort) is not quite that. = Its about manipulation and interaction with network "entities" which include virtual or real = devices, but also network services. BTW, I'd ask that as the thread goes forward, that you clearly = state what the "D" in SDN you=20 are referring to is as it can mean quite different things.=20 > 4) Perhaps the best way of explaining this is by analogy. The = essence of SDN/OF appears to be > the separation of the control plane from the data (forwarding) plane. = So, where have I heard that before? > Those working in the VoIP space are probably very familiar with the = separation between the > Media Gateway Controller and the Media Gateways using either MGCP or = H.248. =20 > Or how about the Media Resource Control Protocol? Those are examples = of vertical control protocols,=20 > where a master controller manages multiple slave components within a = single admin domain. =20 > Now contrast that with a signaling and control protocol such as SIP or = H.323 that interoperate=20 > horizontally between admin domains. Just as SIP and MGCP perform = complementary roles for VoIP,=20 > we see SOP and SDN/OF performing complementary roles in the cloud = space. It is certainly possible that SOP compliments SDrivenNetworks = too because they are a superset case of Software Defined Networks. The question is how. There = has already been discussion=20 of inter-domain SDN orchestrators, which seems to overlap with the = intent of SOP. Have you=20 considered this? --Tom > Finally, imagine what cloud services means in terms of delivery of = hardware and software by vendors > to both customer (enterprise) and cloud SP (e.g. carrier) domains. If = the blade, disk, bridge, and router hardware > can, like a chameleon, take on a different character depending on the = firmware and software layered on top, > then there needs to be a way to remotely provision and configure those = IaaS, PaaS, SaaS software layers,=20 > be it colored Cisco, Juniper, Dell, HP, IBM, Microsoft, Linux, or = whatever. =20 > The nature of communications is that it works best when both ends are = fully interoperable. =20 >=20 > So, while a private enterprise cloud will need to push an on-demand = service request to one or more public clouds, > both those clouds may need to "rent" various layers of cloud software = either prior to or following that cloudburst > from multiple players in the vendor community. =20 > A standardized protocol for service orchestration for all those cloud = layers enables that. >=20 > We are already seeing such on-demand ecosystems becoming reality in = the Unified Communications space > with the movement of IP-PBXs onto DCs as well as IMS components. =20 >=20 > If those can be provided on-demand to meet the capacity needs of the = customer/carrier,=20 > then what stops any other type of cloud software from doing the same? >=20 > Mike >=20 >=20 > _______________________________________________ > sop mailing list > sop@ietf.org > https://www.ietf.org/mailman/listinfo/sop --Apple-Mail=_AF3778ED-7572-4CD6-8BA0-05F7B82B4822 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Resending.

---------- = Forwarded message ----------
From: Michael Hammer <mphmmr@gmail.com>
Date: Thu, Feb 23, 2012 at 11:57 AM
Subject: SOP and SDN = Question
To: sop@ietf.org


All,

I saw some questions asking what is the difference between SOP = and SDN/OF.  
So, I did a quick review of the SDN BOF = presentations.
Here is some food for = thought:

1) The SDN Problem Statement is more narrowly focused on = network and doesn't address 
other important cloud = elements of compute and storage, nor the additional layers that = make 
up PaaS and SaaS.  So, I am thinking that = difference is really in the scope of perspective.  
SOP is about how to specify what cloud consumer needs the = cloud to do, while SDN is in 
the weeds on how to do = the network portion.  What does SDN do for compute and = storage?
Nothing.  SOP provides a means to reference and = stitch together those disparate = pieces.

I guess = my question is (and I think Ping asked this too) is how/why does SOP = differ
from OpenStack, or where does it fit into that model. = You can imagine using OpenStack to do 
just what you are = describing.  Basically at a high level, you are specifying service = management -
which handles most of the XaaS cases I = think.

=
One presentation shows a lack of coordination by = hypervisor with the underlying network, 
but then just = moves the "solution" to the network layer, without showing how = coordination
between the IT and C (network) is sync'd.  Now imagine if = those IT resources are split 
across multiple clouds/DCs. =  Isolation of network from the IT side could lead to = disconnect 
amongst unified ITC service components.  We believe SOP enables a = coordinated = solution.

Fair = point, but again why and how does this differ from what OpenStack gives = you today?

2)  Some quotes from the BOF = presentations:
    "OpenFlow does not = configure, boot, or maintain a box".
    = "Enabling programmatic automation of configuration,&nb= sp;management, 
    =  monitoring, data mining, = ... is largely orthogonal to OF/SDN" =  
Well, SOP is there to boot, configure, and = maintain the various layers of those boxes.
It is about replacing slow-time-scale management etc. with = on-demand signaling and control.
Cloud is about = provisioning on-demand, in other words configuring and booting = resources 
in the Cloud/DC.  So, something missing = here.  I get the feeling that OpenFlow is more like 
assembly-language level execution of a macro-command.  With = SOP we are focused on the 
macro-command = level, within which an admin domain might get implemented = by low-level 
openflow execution.

3)  SDN seems to focus on replacing current = generation static network management = configuration 
versus focusing on the dynamic on-demand = external customer aspects.  Would love to see security 
implications on SDN.  I could see an inter-domain SOP request = fanning out to IT (host) and network (SDN) 
control = signaling components, where the SDN replaces some existing management = controls.
We are trying to address the cloud-bursting = scenarios that cross admin domains.
The last slide of the operator's perspective gives insight to what = we want SOP to address.

I would = characterize Software Driven Networks (SDrN) as you describe, but = Software Defined Networks (SDfN)
(or what we have been working = on in the SDNp effort) is not quite that.  Its about manipulation = and
interaction with network "entities" which include virtual = or real devices, but also network = services.

BTW, I'd ask that as the thread = goes forward, that  you clearly state what the "D" in SDN = you 
are referring to is as it can mean quite different = things. 

4)  Perhaps the best way of explaining = this is by analogy.  The essence of SDN/OF appears to = be
the separation of the control plane from the data = (forwarding) plane.  So, where have I heard that = before?
Those working in the VoIP space are probably very = familiar with the separation between the
Media Gateway Controller and the Media Gateways using either MGCP = or H.248.  
Or how about the Media Resource Control = Protocol?  Those are examples of vertical control = protocols, 
where a master controller manages multiple slave components within = a single admin domain.  
Now contrast that with a = signaling and control protocol such as SIP or H.323 that = interoperate 
horizontally between admin domains. =  Just as SIP and MGCP perform complementary roles for = VoIP, 
we see SOP and SDN/OF performing complementary roles in the = cloud space.

It is = certainly possible that SOP compliments SDrivenNetworks too because they = are a
 superset case of Software Defined Networks. =  The question is how. There has already been = discussion 
of inter-domain SDN orchestrators, which = seems to overlap with the intent of SOP. Have = you 
considered this?

= --Tom


Finally, imagine what cloud services means in = terms of delivery of hardware and software by vendors
to both customer (enterprise) and cloud SP (e.g. carrier) domains. =  If the blade, disk, bridge, and router hardware
can, = like a chameleon, take on a different character depending on the = firmware and software layered on top,
then there needs to be a way to remotely provision and configure = those IaaS, PaaS, SaaS software layers, 
be it = colored Cisco, Juniper, Dell, HP, IBM, Microsoft, Linux, or = whatever.  
The nature of communications is that it works best when both ends = are fully interoperable.  

So, while a = private enterprise cloud will need to push = an on-demand service request  to one or more public = clouds,
both those clouds may need to "rent" various layers of cloud = software either prior to or following that cloudburst
from = multiple players in the vendor community.  
A = standardized protocol for service orchestration for all those cloud = layers enables that.

We are already seeing such on-demand ecosystems = becoming reality in the Unified Communications space
with the = movement of IP-PBXs onto DCs as well as IMS components.  

If those can be provided on-demand to meet the = capacity needs of the customer/carrier, 
then what stops = any other type of cloud software from doing the same?

Mike


_______________________________________________
sop mailing = list
sop@ietf.org
https://www.ietf.org/mail= man/listinfo/sop

= --Apple-Mail=_AF3778ED-7572-4CD6-8BA0-05F7B82B4822-- From mphmmr@gmail.com Fri Feb 24 07:28:49 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B0421F8800 for ; Fri, 24 Feb 2012 07:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.445 X-Spam-Level: X-Spam-Status: No, score=-3.445 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 xmjjyzLk5S4t for ; Fri, 24 Feb 2012 07:28:48 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB8121F87EB for ; Fri, 24 Feb 2012 07:28:47 -0800 (PST) Received: by lahl5 with SMTP id l5so3463000lah.31 for ; Fri, 24 Feb 2012 07:28:46 -0800 (PST) Received-SPF: pass (google.com: domain of mphmmr@gmail.com designates 10.112.40.72 as permitted sender) client-ip=10.112.40.72; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mphmmr@gmail.com designates 10.112.40.72 as permitted sender) smtp.mail=mphmmr@gmail.com; dkim=pass header.i=mphmmr@gmail.com Received: from mr.google.com ([10.112.40.72]) by 10.112.40.72 with SMTP id v8mr1135960lbk.49.1330097326490 (num_hops = 1); Fri, 24 Feb 2012 07:28:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DRCQvGOv+MsSwRkwvI5ciPqSCZepihPWyd4kRHYg9uw=; b=UaebCA4g2QBpKK6/JXNlBC/PLvekOQcCNOZlCno7BsF2kSHhLJH8n5/DDUXVzp42Nm rXR/ib1HLtxUHA/IJg0B//BLFBqcoprQrWTPqQM5opyj/pS5x1HmUre3LA1LQ1J9NOql tnwS0qut1j85n4x/O+jyJuSiS7jWM6glSgDMM= MIME-Version: 1.0 Received: by 10.112.40.72 with SMTP id v8mr942007lbk.49.1330097326375; Fri, 24 Feb 2012 07:28:46 -0800 (PST) Received: by 10.112.104.70 with HTTP; Fri, 24 Feb 2012 07:28:46 -0800 (PST) In-Reply-To: <353D9CCB-2576-4A88-AAFC-DCE82FAF1101@lucidvision.com> References: <353D9CCB-2576-4A88-AAFC-DCE82FAF1101@lucidvision.com> Date: Fri, 24 Feb 2012 10:28:46 -0500 Message-ID: From: Michael Hammer To: Thomas Nadeau Content-Type: multipart/alternative; boundary=e0cb4efe2d58a7c4da04b9b76a91 Cc: sdnp@lucidvision.com, sop@ietf.org Subject: Re: [sop] Fwd: SOP and SDN Question X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 15:28:49 -0000 --e0cb4efe2d58a7c4da04b9b76a91 Content-Type: text/plain; charset=ISO-8859-1 Tom, You seem to suggest that Open Flow can be expanded to include services besides networking. But, the key question is this: Does OF clearly separate out the service-dependent information from the service-independent methods such that it can easily be extensible to any service? Mike On Fri, Feb 24, 2012 at 10:12 AM, Thomas Nadeau wrote: > > On Feb 24, 2012, at 10:02 AM, Michael Hammer wrote: > > Resending. > > ---------- Forwarded message ---------- > From: Michael Hammer > Date: Thu, Feb 23, 2012 at 11:57 AM > Subject: SOP and SDN Question > To: sop@ietf.org > > > All, > > I saw some questions asking what is the difference between SOP and SDN/OF. > > So, I did a quick review of the SDN BOF presentations. > Here is some food for thought: > > 1) The SDN Problem Statement is more narrowly focused on network and > doesn't address > other important cloud elements of compute and storage, nor the additional > layers that make > up PaaS and SaaS. So, I am thinking that difference is really in the > scope of perspective. > SOP is about how to specify what cloud consumer needs the cloud to > do, while SDN is in > the weeds on how to do the network portion. What does SDN do for compute > and storage? > Nothing. SOP provides a means to reference and stitch together those > disparate pieces. > > > I guess my question is (and I think Ping asked this too) is how/why does > SOP differ > from OpenStack, or where does it fit into that model. You can imagine > using OpenStack to do > just what you are describing. Basically at a high level, you are > specifying service management - > which handles most of the XaaS cases I think. > > One presentation shows a lack of coordination by hypervisor with the > underlying network, > but then just moves the "solution" to the network layer, without showing > how coordination > between the IT and C (network) is sync'd. Now imagine if those IT > resources are split > across multiple clouds/DCs. Isolation of network from the IT side could > lead to disconnect > amongst unified ITC service components. We believe SOP enables a > coordinated solution. > > > Fair point, but again why and how does this differ from what OpenStack > gives you today? > > 2) Some quotes from the BOF presentations: > "OpenFlow does not configure, boot, or maintain a box". > "Enabling programmatic automation of configuration, management, > monitoring, data mining, ... is largely orthogonal to OF/SDN" > Well, SOP is there to boot, configure, and maintain the various layers of > those boxes. > It is about replacing slow-time-scale management etc. with on-demand > signaling and control. > Cloud is about provisioning on-demand, in other words configuring and > booting resources > in the Cloud/DC. So, something missing here. I get the feeling that > OpenFlow is more like > assembly-language level execution of a macro-command. With SOP we are > focused on the > macro-command level, within which an admin domain might get implemented by > low-level > openflow execution. > > 3) SDN seems to focus on replacing current generation static network > management configuration > versus focusing on the dynamic on-demand external customer aspects. Would > love to see security > implications on SDN. I could see an inter-domain SOP request fanning out > to IT (host) and network (SDN) > control signaling components, where the SDN replaces some existing > management controls. > We are trying to address the cloud-bursting scenarios that cross admin > domains. > The last slide of the operator's perspective gives insight to what we want > SOP to address. > > > I would characterize Software Driven Networks (SDrN) as you describe, but > Software Defined Networks (SDfN) > (or what we have been working on in the SDNp effort) is not quite that. > Its about manipulation and > interaction with network "entities" which include virtual or real devices, > but also network services. > > BTW, I'd ask that as the thread goes forward, that you clearly state what > the "D" in SDN you > are referring to is as it can mean quite different things. > > 4) Perhaps the best way of explaining this is by analogy. The essence of > SDN/OF appears to be > the separation of the control plane from the data (forwarding) plane. So, > where have I heard that before? > Those working in the VoIP space are probably very familiar with the > separation between the > Media Gateway Controller and the Media Gateways using either MGCP or > H.248. > Or how about the Media Resource Control Protocol? Those are examples of > vertical control protocols, > where a master controller manages multiple slave components within a > single admin domain. > Now contrast that with a signaling and control protocol such as SIP or > H.323 that interoperate > horizontally between admin domains. Just as SIP and MGCP perform > complementary roles for VoIP, > we see SOP and SDN/OF performing complementary roles in the cloud space. > > > It is certainly possible that SOP compliments SDrivenNetworks too because > they are a > superset case of Software Defined Networks. The question is how. There > has already been discussion > of inter-domain SDN orchestrators, which seems to overlap with the intent > of SOP. Have you > considered this? > > --Tom > > > Finally, imagine what cloud services means in terms of delivery of > hardware and software by vendors > to both customer (enterprise) and cloud SP (e.g. carrier) domains. If the > blade, disk, bridge, and router hardware > can, like a chameleon, take on a different character depending on the > firmware and software layered on top, > then there needs to be a way to remotely provision and configure those > IaaS, PaaS, SaaS software layers, > be it colored Cisco, Juniper, Dell, HP, IBM, Microsoft, Linux, or > whatever. > The nature of communications is that it works best when both ends are > fully interoperable. > > So, while a private enterprise cloud will need to push > an on-demand service request to one or more public clouds, > both those clouds may need to "rent" various layers of cloud software > either prior to or following that cloudburst > from multiple players in the vendor community. > A standardized protocol for service orchestration for all those cloud > layers enables that. > > We are already seeing such on-demand ecosystems becoming reality in the > Unified Communications space > with the movement of IP-PBXs onto DCs as well as IMS components. > > If those can be provided on-demand to meet the capacity needs of the > customer/carrier, > then what stops any other type of cloud software from doing the same? > > Mike > > > _______________________________________________ > sop mailing list > sop@ietf.org > https://www.ietf.org/mailman/listinfo/sop > > > --e0cb4efe2d58a7c4da04b9b76a91 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Tom,

You seem to suggest that Open Flow can be expanded = to include services besides networking.

But, the k= ey question is this: =A0
Does OF clearly separate out the service= -dependent information from the=A0service-independent methods=A0
such that it can easily be extensible to any service?

Mike


On Fri, Feb 24, = 2012 at 10:12 AM, Thomas Nadeau <tnadeau@lucidvision.com> wrote:

On Feb 24, 2012, at 10:02 AM, Michael Hammer wrote:=

Resending.

= ---------- Forwarded message ----------
From: Michael Hammer <mphmmr@gmail.com>
Date: Thu, Feb 23, 2012 at 11:57 AM
Subject: SOP and SDN Question
To:= sop@ietf.org

=
All,

I saw some questions asking what is the differe= nce between SOP and SDN/OF. =A0
So, I did a quick review of the SDN BOF presentations.
Here = is some food for thought:

1) The=A0SDN Problem Statement is more narrowly focused on network and= doesn't address=A0
other important cloud elements of compute= and storage, nor the additional layers that make=A0
up PaaS and = SaaS. =A0So, I am thinking that difference is really in the scope of perspe= ctive. =A0
SOP is about how to specify what cloud consumer needs the cloud t= o do,=A0while SDN is in=A0
the weeds on how to do the network por= tion. =A0What does SDN do for compute and storage?
Nothing. =A0SO= P provides a means to reference and stitch together those disparate pieces.=

I guess my question is (and I think Ping asked this to= o) is how/why does SOP differ
from OpenStack, or where does it fi= t into that model. You can imagine using OpenStack to do=A0
just what you are describing. =A0Basically at a high level, you are sp= ecifying service management -
which handles most of the XaaS case= s I think.

One presentation shows a lack of coordination by hyper= visor with the underlying network,=A0
but then just moves the &qu= ot;solution" to the network layer, without showing how coordination
between the IT and C (network) is sync'd. =A0Now imagine if those = IT resources are split=A0
across multiple clouds/DCs. =A0Isolatio= n of network from the IT side could lead to disconnect=A0
amongst unified ITC service components. =A0We believe SOP enables a coordin= ated solution.

Fair point, but again why an= d how does this differ from what OpenStack gives you today?

=
2) =A0Some quotes from the BOF presentations:
=A0= =A0=A0"OpenFlow does not configure, boot, or maintain a box".
=A0 =A0 "Enabling=A0programmatic=A0automation=A0of=A0co= nfiguration,=A0management,=A0
=A0 =A0 =A0monitoring,=A0data=A0min= ing, ...=A0is=A0largely=A0orthogonal=A0to=A0OF/SDN" =A0
Well, SOP is there to boot, configure, and maintain the various layers of= those boxes.
It is about replacing slow-time-scale management etc. with on-demand s= ignaling and control.
Cloud is about provisioning on-demand= , in other words configuring and booting resources=A0
in the Clou= d/DC. =A0So, something missing here. =A0I get the feeling that OpenFlow is = more like=A0
assembly-language level execution of a macro-command. =A0With SOP we a= re focused on the=A0
macro-command level,=A0within=A0which an adm= in domain might get=A0implemented by low-level=A0
openflow execut= ion.

3) =A0SDN seems to focus on replacing current generatio= n static network management configuration=A0
versus focusing on t= he dynamic on-demand external customer aspects. =A0Would love to see securi= ty=A0
implications on SDN. =A0I could see an inter-domain SOP request fannin= g out to IT (host) and network (SDN)=A0
control signaling compone= nts, where the SDN replaces some existing management controls.
We= are trying to address the cloud-bursting scenarios that cross admin domain= s.
The last slide of the operator's perspective gives insight to what= we want SOP to address.

I would characterize Software Drive= n Networks (SDrN) as you describe, but Software Defined Networks (SDfN)
(or what we have been working on in the SDNp effort) is not quite that= . =A0Its about manipulation and
interaction with network "en= tities" which include virtual or real devices, but also network servic= es.

BTW, I'= ;d ask that as the thread goes forward, that =A0you clearly state what the = "D" in SDN you=A0
are referring to is as it can mean qu= ite different things.=A0

4) =A0Perhaps the best way of explaining this is by analogy. =A0T= he essence of SDN/OF appears to be
the separation of the control = plane from the data (forwarding) plane. =A0So, where have I heard that befo= re?
Those working in the VoIP space are probably very familiar with the se= paration between the
Media Gateway Controller and the Media Gateways using either MGCP or H= .248. =A0
Or how about the=A0Media Resource Control Protocol? =A0= Those are examples of vertical control protocols,=A0
where a master controller manages multiple=A0slave components within a sing= le admin domain. =A0
Now contrast that with a signaling and contr= ol=A0protocol such as SIP or H.323 that interoperate=A0
horizonta= lly between admin domains. =A0Just as=A0SIP and MGCP perform complementary = roles for VoIP,=A0
we see SOP and SDN/OF=A0performing complementary roles in the cloud sp= ace.

It is certainly possible that SOP compliments SDri= venNetworks too because they are a
=A0superset case=A0of Software Defined Networks. =A0The question is ho= w. There has already been discussion=A0
of=A0inter-domain SDN orc= hestrators, which seems to overlap with the intent of SOP. Have you=A0
considered this?

--Tom


Finally, imagine what cloud services means in terms o= f delivery of hardware and software by vendors
to both customer (enterprise) and cloud SP (e.g. carrier) domains. =A0= If the blade, disk, bridge, and router hardware
can, like a chame= leon, take on a different character depending on the firmware and software = layered on top,
then there needs to be a way to remotely provision and configure those= IaaS, PaaS, SaaS software layers,=A0
be it colored=A0Cisco, Juni= per, Dell, HP, IBM, Microsoft, Linux, or whatever. =A0
The nature of communications is that it works=A0best when both ends are ful= ly interoperable. =A0

So, while a private enterpri= se cloud will need to push an=A0on-demand=A0service request =A0to one or mo= re public clouds,
both those clouds may need to "rent" various layers of cloud= software either prior to or following that cloudburst
from multi= ple players in the vendor community. =A0
A standardized protocol = for service orchestration for all those cloud layers enables that.

We are already seeing such on-demand ecosystems becomin= g reality in the Unified Communications space
with the movement o= f IP-PBXs onto DCs as well as IMS components. =A0

If those can be provided on-demand=A0to meet the capaci= ty needs of the customer/carrier,=A0
then what stops any other ty= pe of cloud software from doing the same?

Mike


_______________________________________________
sop mailing list
sop@ietf.org
https://ww= w.ietf.org/mailman/listinfo/sop


--e0cb4efe2d58a7c4da04b9b76a91-- From tnadeau@lucidvision.com Fri Feb 24 07:31:45 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A91221F85B8 for ; Fri, 24 Feb 2012 07:31:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 jF1vpfH6vFiv for ; Fri, 24 Feb 2012 07:31:43 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9238421F85A1 for ; Fri, 24 Feb 2012 07:31:43 -0800 (PST) Received: from [10.100.68.228] (unknown [141.202.11.155]) by lucidvision.com (Postfix) with ESMTP id CDC0C142794; Fri, 24 Feb 2012 10:31:42 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_F41EC768-662D-4B40-A948-BA1ED41DBC98" From: Thomas Nadeau In-Reply-To: Date: Fri, 24 Feb 2012 10:31:45 -0500 Message-Id: References: <353D9CCB-2576-4A88-AAFC-DCE82FAF1101@lucidvision.com> To: Michael Hammer X-Mailer: Apple Mail (2.1257) Cc: sdnp@lucidvision.com, sop@ietf.org Subject: Re: [sop] Fwd: SOP and SDN Question X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 15:31:45 -0000 --Apple-Mail=_F41EC768-662D-4B40-A948-BA1ED41DBC98 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Feb 24, 2012, at 10:28 AM, Michael Hammer wrote: > Tom, >=20 > You seem to suggest that Open Flow can be expanded to include services = besides networking. I think you misunderstood what I wrote. Software Defined = Networks (i.e.: OpenFlow) is targeted at working=20 at the hardware abstraction level only. Software *Driven* Networks is = targeted at services and network elements.=20 There is a clear difference. --Tom > But, the key question is this: =20 > Does OF clearly separate out the service-dependent information from = the service-independent methods=20 > such that it can easily be extensible to any service? >=20 > Mike >=20 >=20 > On Fri, Feb 24, 2012 at 10:12 AM, Thomas Nadeau = wrote: >=20 > On Feb 24, 2012, at 10:02 AM, Michael Hammer wrote: >=20 >> Resending. >>=20 >> ---------- Forwarded message ---------- >> From: Michael Hammer >> Date: Thu, Feb 23, 2012 at 11:57 AM >> Subject: SOP and SDN Question >> To: sop@ietf.org >>=20 >>=20 >> All, >>=20 >> I saw some questions asking what is the difference between SOP and = SDN/OF. =20 >> So, I did a quick review of the SDN BOF presentations. >> Here is some food for thought: >>=20 >> 1) The SDN Problem Statement is more narrowly focused on network and = doesn't address=20 >> other important cloud elements of compute and storage, nor the = additional layers that make=20 >> up PaaS and SaaS. So, I am thinking that difference is really in the = scope of perspective. =20 >> SOP is about how to specify what cloud consumer needs the cloud to = do, while SDN is in=20 >> the weeds on how to do the network portion. What does SDN do for = compute and storage? >> Nothing. SOP provides a means to reference and stitch together those = disparate pieces. >=20 > I guess my question is (and I think Ping asked this too) is = how/why does SOP differ > from OpenStack, or where does it fit into that model. You can imagine = using OpenStack to do=20 > just what you are describing. Basically at a high level, you are = specifying service management - > which handles most of the XaaS cases I think. >=20 >> One presentation shows a lack of coordination by hypervisor with the = underlying network,=20 >> but then just moves the "solution" to the network layer, without = showing how coordination >> between the IT and C (network) is sync'd. Now imagine if those IT = resources are split=20 >> across multiple clouds/DCs. Isolation of network from the IT side = could lead to disconnect=20 >> amongst unified ITC service components. We believe SOP enables a = coordinated solution. >=20 > Fair point, but again why and how does this differ from what = OpenStack gives you today? >=20 >> 2) Some quotes from the BOF presentations: >> "OpenFlow does not configure, boot, or maintain a box". >> "Enabling programmatic automation of configuration, management,=20= >> monitoring, data mining, ... is largely orthogonal to OF/SDN" =20= >> Well, SOP is there to boot, configure, and maintain the various = layers of those boxes. >> It is about replacing slow-time-scale management etc. with on-demand = signaling and control. >> Cloud is about provisioning on-demand, in other words configuring and = booting resources=20 >> in the Cloud/DC. So, something missing here. I get the feeling that = OpenFlow is more like=20 >> assembly-language level execution of a macro-command. With SOP we = are focused on the=20 >> macro-command level, within which an admin domain might get = implemented by low-level=20 >> openflow execution. >>=20 >> 3) SDN seems to focus on replacing current generation static network = management configuration=20 >> versus focusing on the dynamic on-demand external customer aspects. = Would love to see security=20 >> implications on SDN. I could see an inter-domain SOP request fanning = out to IT (host) and network (SDN)=20 >> control signaling components, where the SDN replaces some existing = management controls. >> We are trying to address the cloud-bursting scenarios that cross = admin domains. >> The last slide of the operator's perspective gives insight to what we = want SOP to address. >=20 > =09 > I would characterize Software Driven Networks (SDrN) as you describe, = but Software Defined Networks (SDfN) > (or what we have been working on in the SDNp effort) is not quite = that. Its about manipulation and > interaction with network "entities" which include virtual or real = devices, but also network services. >=20 > BTW, I'd ask that as the thread goes forward, that you clearly = state what the "D" in SDN you=20 > are referring to is as it can mean quite different things.=20 >=20 >> 4) Perhaps the best way of explaining this is by analogy. The = essence of SDN/OF appears to be >> the separation of the control plane from the data (forwarding) plane. = So, where have I heard that before? >> Those working in the VoIP space are probably very familiar with the = separation between the >> Media Gateway Controller and the Media Gateways using either MGCP or = H.248. =20 >> Or how about the Media Resource Control Protocol? Those are examples = of vertical control protocols,=20 >> where a master controller manages multiple slave components within a = single admin domain. =20 >> Now contrast that with a signaling and control protocol such as SIP = or H.323 that interoperate=20 >> horizontally between admin domains. Just as SIP and MGCP perform = complementary roles for VoIP,=20 >> we see SOP and SDN/OF performing complementary roles in the cloud = space. >=20 > It is certainly possible that SOP compliments SDrivenNetworks = too because they are a > superset case of Software Defined Networks. The question is how. = There has already been discussion=20 > of inter-domain SDN orchestrators, which seems to overlap with the = intent of SOP. Have you=20 > considered this? >=20 > --Tom >=20 >=20 >> Finally, imagine what cloud services means in terms of delivery of = hardware and software by vendors >> to both customer (enterprise) and cloud SP (e.g. carrier) domains. = If the blade, disk, bridge, and router hardware >> can, like a chameleon, take on a different character depending on the = firmware and software layered on top, >> then there needs to be a way to remotely provision and configure = those IaaS, PaaS, SaaS software layers,=20 >> be it colored Cisco, Juniper, Dell, HP, IBM, Microsoft, Linux, or = whatever. =20 >> The nature of communications is that it works best when both ends are = fully interoperable. =20 >>=20 >> So, while a private enterprise cloud will need to push an on-demand = service request to one or more public clouds, >> both those clouds may need to "rent" various layers of cloud software = either prior to or following that cloudburst >> from multiple players in the vendor community. =20 >> A standardized protocol for service orchestration for all those cloud = layers enables that. >>=20 >> We are already seeing such on-demand ecosystems becoming reality in = the Unified Communications space >> with the movement of IP-PBXs onto DCs as well as IMS components. =20 >>=20 >> If those can be provided on-demand to meet the capacity needs of the = customer/carrier,=20 >> then what stops any other type of cloud software from doing the same? >>=20 >> Mike >>=20 >>=20 >> _______________________________________________ >> sop mailing list >> sop@ietf.org >> https://www.ietf.org/mailman/listinfo/sop >=20 >=20 --Apple-Mail=_F41EC768-662D-4B40-A948-BA1ED41DBC98 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Tom,

You seem to suggest that Open Flow = can be expanded to include services besides = networking.

I think = you misunderstood what I wrote. Software Defined Networks (i.e.: = OpenFlow) is targeted at working 
at the hardware = abstraction level only. Software *Driven* Networks is targeted at = services and network elements. 
There is a clear = difference.

= --Tom


But, the key question is this:  
Does = OF clearly separate out the service-dependent information from = the service-independent methods 
such that it can easily be extensible to any = service?

Mike


On Fri, Feb 24, 2012 at 10:12 AM, Thomas Nadeau = <tnadeau@lucidvision.com> wrote:

On Feb = 24, 2012, at 10:02 AM, Michael Hammer wrote:

Resending.

---------- Forwarded message ----------
From: = Michael Hammer <mphmmr@gmail.com>
Date: Thu, Feb 23, 2012 at 11:57 AM
Subject: SOP and SDN = Question
To: sop@ietf.org


All,

I = saw some questions asking what is the difference between SOP and SDN/OF. =  
So, I did a quick review of the SDN BOF = presentations.
Here is some food for = thought:

1) The SDN Problem Statement is more narrowly focused on = network and doesn't address 
other important cloud = elements of compute and storage, nor the additional layers that = make 
up PaaS and SaaS.  So, I am thinking that = difference is really in the scope of perspective.  
SOP is about how to specify what cloud consumer needs the = cloud to do, while SDN is in 
the weeds on how to do = the network portion.  What does SDN do for compute and = storage?
Nothing.  SOP provides a means to reference and = stitch together those disparate pieces.

I guess my question is (and I = think Ping asked this too) is how/why does SOP differ
from = OpenStack, or where does it fit into that model. You can imagine using = OpenStack to do 
just what you are describing.  Basically at a high level, you = are specifying service management -
which handles most of the = XaaS cases I think.

One presentation shows a lack of coordination by = hypervisor with the underlying network, 
but then just = moves the "solution" to the network layer, without showing how = coordination
between the IT and C (network) is sync'd.  Now imagine if = those IT resources are split 
across multiple clouds/DCs. =  Isolation of network from the IT side could lead to = disconnect 
amongst unified ITC service components.  We believe SOP enables a = coordinated = solution.

Fair point, but again why = and how does this differ from what OpenStack gives you today?

2)  Some quotes from the BOF = presentations:
    "OpenFlow does not = configure, boot, or maintain a box".
    = "Enabling programmatic automation of configuration,&nb= sp;management, 
    =  monitoring, data mining, = ... is largely orthogonal to OF/SDN" =  
Well, SOP is there to boot, configure, and = maintain the various layers of those boxes.
It is about replacing slow-time-scale management etc. with = on-demand signaling and control.
Cloud is about = provisioning on-demand, in other words configuring and booting = resources 
in the Cloud/DC.  So, something missing = here.  I get the feeling that OpenFlow is more like 
assembly-language level execution of a macro-command.  With = SOP we are focused on the 
macro-command = level, within which an admin domain might get implemented = by low-level 
openflow execution.

3)  SDN seems to focus on replacing current = generation static network management = configuration 
versus focusing on the dynamic on-demand = external customer aspects.  Would love to see security 
implications on SDN.  I could see an inter-domain SOP request = fanning out to IT (host) and network (SDN) 
control = signaling components, where the SDN replaces some existing management = controls.
We are trying to address the cloud-bursting = scenarios that cross admin domains.
The last slide of the operator's perspective gives insight to what = we want SOP to address.

I would characterize = Software Driven Networks (SDrN) as you describe, but Software Defined = Networks (SDfN)
(or what we have been working on in the SDNp effort) is not quite = that.  Its about manipulation and
interaction with = network "entities" which include virtual or real devices, but also = network services.

= BTW, I'd ask that as the thread goes forward, that  you = clearly state what the "D" in SDN you 
are referring to = is as it can mean quite different things. 

4)  Perhaps the best way of explaining = this is by analogy.  The essence of SDN/OF appears to = be
the separation of the control plane from the data = (forwarding) plane.  So, where have I heard that before?
Those working in the VoIP space are probably very familiar with the = separation between the
Media Gateway Controller and the Media Gateways using either MGCP = or H.248.  
Or how about the Media Resource Control = Protocol?  Those are examples of vertical control = protocols, 
where a master controller manages multiple slave components within = a single admin domain.  
Now contrast that with a = signaling and control protocol such as SIP or H.323 that = interoperate 
horizontally between admin domains. =  Just as SIP and MGCP perform complementary roles for = VoIP, 
we see SOP and SDN/OF performing complementary roles in the = cloud space.

It is certainly possible that SOP = compliments SDrivenNetworks too because they are a
 superset case of Software Defined Networks.  The = question is how. There has already been = discussion 
of inter-domain SDN orchestrators, which = seems to overlap with the intent of SOP. Have = you 
considered this?

= --Tom


Finally, imagine what cloud = services means in terms of delivery of hardware and software by = vendors
to both customer (enterprise) and cloud SP (e.g. carrier) domains. =  If the blade, disk, bridge, and router hardware
can, = like a chameleon, take on a different character depending on the = firmware and software layered on top,
then there needs to be a way to remotely provision and configure = those IaaS, PaaS, SaaS software layers, 
be it = colored Cisco, Juniper, Dell, HP, IBM, Microsoft, Linux, or = whatever.  
The nature of communications is that it works best when both ends = are fully interoperable.  

So, while a = private enterprise cloud will need to push = an on-demand service request  to one or more public = clouds,
both those clouds may need to "rent" various layers of cloud = software either prior to or following that cloudburst
from = multiple players in the vendor community.  
A = standardized protocol for service orchestration for all those cloud = layers enables that.

We are already seeing such on-demand ecosystems = becoming reality in the Unified Communications space
with the = movement of IP-PBXs onto DCs as well as IMS components.  

If those can be provided on-demand to meet the = capacity needs of the customer/carrier, 
then what stops = any other type of cloud software from doing the same?

Mike


_______________________________________________
sop mailing = list
sop@ietf.org
https://www.ietf.org/mailman/listinfo/sop



= --Apple-Mail=_F41EC768-662D-4B40-A948-BA1ED41DBC98-- From robert@raszuk.net Fri Feb 24 07:43:55 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F1821F8800 for ; Fri, 24 Feb 2012 07:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 hvImFNknNdhp for ; Fri, 24 Feb 2012 07:43:54 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5FD21F87E3 for ; Fri, 24 Feb 2012 07:43:54 -0800 (PST) Received: (qmail 27942 invoked by uid 399); 24 Feb 2012 15:43:53 -0000 Received: from unknown (HELO ?184.48.56.24?) (pbs:robert@raszuk.net@12.217.162.34) by mail1310.opentransfer.com with ESMTPM; 24 Feb 2012 15:43:53 -0000 X-Originating-IP: 12.217.162.34 Message-ID: <4F47B03C.8070301@raszuk.net> Date: Fri, 24 Feb 2012 16:43:56 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Thomas Nadeau References: <353D9CCB-2576-4A88-AAFC-DCE82FAF1101@lucidvision.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sdnp@lucidvision.com, sop@ietf.org, Michael Hammer Subject: Re: [sop] [Sdnp] Fwd: SOP and SDN Question X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 15:43:55 -0000 Hi Tom, >> You seem to suggest that Open Flow can be expanded to include services >> besides networking. > > I think you misunderstood what I wrote. Software Defined Networks (i.e.: > OpenFlow) is targeted at working at the hardware abstraction level only. That's completely inaccurate. SDN is all about network applications. You perhaps are confusing it with ONF which indeed at this point is focused on defining OpenFlow protocol. But protocols are not defined just by bunch of hardware enthusiasts. They are defined to address specific software defined applications. Best, R. Software *Driven* Networks is > targeted at services and network elements. > There is a clear difference. > > --Tom From tnadeau@lucidvision.com Fri Feb 24 07:48:43 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161F621F8807 for ; Fri, 24 Feb 2012 07:48:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] 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 rKUlMoelx+s5 for ; Fri, 24 Feb 2012 07:48:42 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7875921F8800 for ; Fri, 24 Feb 2012 07:48:42 -0800 (PST) Received: from [10.100.68.228] (unknown [141.202.11.155]) by lucidvision.com (Postfix) with ESMTP id A8BE21428B3; Fri, 24 Feb 2012 10:48:41 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Thomas Nadeau In-Reply-To: <4F47B03C.8070301@raszuk.net> Date: Fri, 24 Feb 2012 10:48:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2FB85049-EE2C-4D28-80A3-D2364B2FDB42@lucidvision.com> References: <353D9CCB-2576-4A88-AAFC-DCE82FAF1101@lucidvision.com> <4F47B03C.8070301@raszuk.net> To: robert@raszuk.net X-Mailer: Apple Mail (2.1257) Cc: sdnp@lucidvision.com, sop@ietf.org, Michael Hammer Subject: Re: [sop] [Sdnp] Fwd: SOP and SDN Question X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 15:48:43 -0000 On Feb 24, 2012, at 10:43 AM, Robert Raszuk wrote: > Hi Tom, >=20 >>> You seem to suggest that Open Flow can be expanded to include = services >>> besides networking. >>=20 >> I think you misunderstood what I wrote. Software Defined Networks = (i.e.: >> OpenFlow) is targeted at working at the hardware abstraction level = only. >=20 > That's completely inaccurate. Not completely. *) =09 > SDN is all about network applications. You perhaps are confusing it = with ONF which indeed at this point is focused on defining OpenFlow = protocol. Software DRIVEN Networks is all about network applications *and* = their interaction with network services and elements, of which a subset is Software *defined* Networks (I.e.: OpenFlow). We really need = to pick a different term for Software Driven Networks because=20 it is confusing everyone. People seem to equate "SDN" with OpenFlow = without being clear about the "D". --Tom > But protocols are not defined just by bunch of hardware enthusiasts. = They are defined to address specific software defined applications. >=20 > Best, > R. >=20 >=20 >=20 > Software *Driven* Networks is >> targeted at services and network elements. >> There is a clear difference. >>=20 >> --Tom >=20 >=20 From mphmmr@gmail.com Fri Feb 24 07:58:01 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1C821F87A4 for ; Fri, 24 Feb 2012 07:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.454 X-Spam-Level: X-Spam-Status: No, score=-3.454 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 BAMl7RSznK+J for ; Fri, 24 Feb 2012 07:58:01 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 866E521F86EB for ; Fri, 24 Feb 2012 07:57:53 -0800 (PST) Received: by lahl5 with SMTP id l5so3497368lah.31 for ; Fri, 24 Feb 2012 07:57:52 -0800 (PST) Received-SPF: pass (google.com: domain of mphmmr@gmail.com designates 10.112.24.162 as permitted sender) client-ip=10.112.24.162; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mphmmr@gmail.com designates 10.112.24.162 as permitted sender) smtp.mail=mphmmr@gmail.com; dkim=pass header.i=mphmmr@gmail.com Received: from mr.google.com ([10.112.24.162]) by 10.112.24.162 with SMTP id v2mr1199352lbf.21.1330099072603 (num_hops = 1); Fri, 24 Feb 2012 07:57:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VmwNUZ0X5AKxtOFjy4V5rjYLrGuvwLCxX60EfMLFxmY=; b=JP+p8TORIiLpRgwqCGpC9NIqDUxDztQQjnyyKUyFTpdQL5eqDL+vpfMLHeJytlnfOI tYbkEYXnaNfhRAMi13loiR6OZlLYTpiX8H/sLIZatH/KTjBFvM1x/22bg4MxZyjcD0q9 3lfjWCiBT5M3zV5hqY/maRCzr4dhH12cSkquQ= MIME-Version: 1.0 Received: by 10.112.24.162 with SMTP id v2mr992223lbf.21.1330099072527; Fri, 24 Feb 2012 07:57:52 -0800 (PST) Received: by 10.112.104.70 with HTTP; Fri, 24 Feb 2012 07:57:52 -0800 (PST) In-Reply-To: <2FB85049-EE2C-4D28-80A3-D2364B2FDB42@lucidvision.com> References: <353D9CCB-2576-4A88-AAFC-DCE82FAF1101@lucidvision.com> <4F47B03C.8070301@raszuk.net> <2FB85049-EE2C-4D28-80A3-D2364B2FDB42@lucidvision.com> Date: Fri, 24 Feb 2012 10:57:52 -0500 Message-ID: From: Michael Hammer To: Thomas Nadeau Content-Type: multipart/alternative; boundary=485b390f7d40bbee7204b9b7d29d Cc: sdnp@lucidvision.com, sop@ietf.org, robert@raszuk.net Subject: Re: [sop] [Sdnp] Fwd: SOP and SDN Question X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 15:58:01 -0000 --485b390f7d40bbee7204b9b7d29d Content-Type: text/plain; charset=ISO-8859-1 Agree there is confusion. Also, we need more discussion on APIs versus protocols, along with security implications. We attempted to address that in the IDs. Mike On Fri, Feb 24, 2012 at 10:48 AM, Thomas Nadeau wrote: > > On Feb 24, 2012, at 10:43 AM, Robert Raszuk wrote: > > > Hi Tom, > > > >>> You seem to suggest that Open Flow can be expanded to include services > >>> besides networking. > >> > >> I think you misunderstood what I wrote. Software Defined Networks (i.e.: > >> OpenFlow) is targeted at working at the hardware abstraction level only. > > > > That's completely inaccurate. > > Not completely. *) > > > SDN is all about network applications. You perhaps are confusing it with > ONF which indeed at this point is focused on defining OpenFlow protocol. > > Software DRIVEN Networks is all about network applications *and* > their interaction with network services and elements, of which a > subset is Software *defined* Networks (I.e.: OpenFlow). We really need > to pick a different term for Software Driven Networks because > it is confusing everyone. People seem to equate "SDN" with OpenFlow > without being clear about the "D". > > --Tom > > > > > But protocols are not defined just by bunch of hardware enthusiasts. > They are defined to address specific software defined applications. > > > > Best, > > R. > > > > > > > > Software *Driven* Networks is > >> targeted at services and network elements. > >> There is a clear difference. > >> > >> --Tom > > > > > > --485b390f7d40bbee7204b9b7d29d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Agree there is confusion.

Also, we need more discussion = on APIs versus protocols, along with security implications.
We at= tempted to address that in the IDs.

Mike


On Fri, Feb 24, 2012 at 10:48 AM, Thomas= Nadeau <tn= adeau@lucidvision.com> wrote:

On Feb 24, 2012, at 10:43 AM, Robert Raszuk wrote:

> Hi Tom,
>
>>> You seem to suggest that Open Flow can be expanded to include = services
>>> besides networking.
>>
>> I think you misunderstood what I wrote. Software Defined Networks = (i.e.:
>> OpenFlow) is targeted at working at the hardware abstraction level= only.
>
> That's completely inaccurate.

=A0 =A0 =A0 =A0Not completely. *)

> SDN is all about network applications. You perhaps are confusing it wi= th ONF which indeed at this point is focused on defining OpenFlow protocol.=

=A0 =A0 =A0 =A0Software DRIVEN Networks is all about network applica= tions *and* their interaction with network services and elements, of which = a
subset is Software *defined* Networks (I.e.: OpenFlow). =A0 We really need = to pick a different term for Software Driven Networks because
it is confusing everyone. People seem to equate "SDN" with OpenFl= ow without being clear about the "D".

=A0 =A0 =A0 =A0--Tom



> But protocols are not defined just by bunch of hardware enthusiasts. T= hey are defined to address specific software defined applications.
>
> Best,
> R.
>
>
>
> Software *Driven* Networks is
>> targeted at services and network elements.
>> There is a clear difference.
>>
>> --Tom
>
>


--485b390f7d40bbee7204b9b7d29d-- From robert@raszuk.net Fri Feb 24 08:00:05 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF7321F876F for ; Fri, 24 Feb 2012 08:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 9vg-8ZPSaYOn for ; Fri, 24 Feb 2012 08:00:05 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1B321F87AD for ; Fri, 24 Feb 2012 08:00:03 -0800 (PST) Received: (qmail 15123 invoked by uid 399); 24 Feb 2012 16:00:02 -0000 Received: from unknown (HELO ?184.48.56.24?) (pbs:robert@raszuk.net@12.217.162.34) by mail1310.opentransfer.com with ESMTPM; 24 Feb 2012 16:00:02 -0000 X-Originating-IP: 12.217.162.34 Message-ID: <4F47B406.1000306@raszuk.net> Date: Fri, 24 Feb 2012 17:00:06 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Thomas Nadeau References: <353D9CCB-2576-4A88-AAFC-DCE82FAF1101@lucidvision.com> <4F47B03C.8070301@raszuk.net> <2FB85049-EE2C-4D28-80A3-D2364B2FDB42@lucidvision.com> In-Reply-To: <2FB85049-EE2C-4D28-80A3-D2364B2FDB42@lucidvision.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sdnp@lucidvision.com, sop@ietf.org, Michael Hammer Subject: Re: [sop] [Sdnp] Fwd: SOP and SDN Question X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 16:00:05 -0000 Hi Tom, > Software DRIVEN Networks is all about network applications*and* their interaction with network services and elements, of which a > subset is Software*defined* Networks (I.e.: OpenFlow). We really need to pick a different term for Software Driven Networks because > it is confusing everyone. People seem to equate "SDN" with OpenFlow without being clear about the "D". "Software *defined* Networks (I.e.: OpenFlow)" ... well I see you seems to equate it too. That is not correct. Example: I can use OF protocol in my app to program the switches, but in the same time API to get the routes from bgp route reflectors. In fact I have this running in my lab today. How would you call it ? defined ? driven ? hybrid ? > We really need to pick a different term for Software Driven Networks > because it is confusing everyone. I think you can debate for months what name to pick. However at the end it really does not matter. What matters are actual network applications for network engineers to download, test and use to enhance their services to the users. And so far I see many more of them growing using fully or partially OpenFlow soil then purely on proprietary per vendor mixed API grounds. Cheers, R. From sam.aldrin@gmail.com Fri Feb 24 08:09:21 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A2921F885A for ; Fri, 24 Feb 2012 08:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] 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 5ziyuv1lnied for ; Fri, 24 Feb 2012 08:09:19 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B5C4E21F8807 for ; Fri, 24 Feb 2012 08:09:19 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so2880428pbc.31 for ; Fri, 24 Feb 2012 08:09:19 -0800 (PST) Received-SPF: pass (google.com: domain of sam.aldrin@gmail.com designates 10.68.224.9 as permitted sender) client-ip=10.68.224.9; Authentication-Results: mr.google.com; spf=pass (google.com: domain of sam.aldrin@gmail.com designates 10.68.224.9 as permitted sender) smtp.mail=sam.aldrin@gmail.com; dkim=pass header.i=sam.aldrin@gmail.com Received: from mr.google.com ([10.68.224.9]) by 10.68.224.9 with SMTP id qy9mr9220024pbc.102.1330099759629 (num_hops = 1); Fri, 24 Feb 2012 08:09:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=fs0sua57lB5KLvCr3dGWa8dU6Dv1LhxZcvYXV1NW6LE=; b=xLdSX4SaNNQrsQ40rk+cU10uXfOJ3QgzyH23wWFDiO5okZRQb01V2dlX+p2LEeuBzi eL2BQZ0fGhsCpMzkgVJCzWgS33Jo1MKqNJ18MwTw3wHNSvuYr33tsNbVtIXfGzgczU2A t+0noFsA3uwwCkB2dx4HRkmtyts1urLI5PRHI= Received: by 10.68.224.9 with SMTP id qy9mr7714230pbc.102.1330099759519; Fri, 24 Feb 2012 08:09:19 -0800 (PST) Received: from [192.168.1.3] (c-107-3-156-34.hsd1.ca.comcast.net. [107.3.156.34]) by mx.google.com with ESMTPS id 3sm4673878pbx.66.2012.02.24.08.09.17 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 24 Feb 2012 08:09:18 -0800 (PST) References: <353D9CCB-2576-4A88-AAFC-DCE82FAF1101@lucidvision.com> <4F47B03C.8070301@raszuk.net> <2FB85049-EE2C-4D28-80A3-D2364B2FDB42@lucidvision.com> In-Reply-To: <2FB85049-EE2C-4D28-80A3-D2364B2FDB42@lucidvision.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9A405) From: Sam Aldrin Date: Fri, 24 Feb 2012 08:09:16 -0800 To: Thomas Nadeau Cc: "sdnp@lucidvision.com" , "sop@ietf.org" , "robert@raszuk.net" Subject: Re: [sop] [Sdnp] Fwd: SOP and SDN Question X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 16:09:21 -0000 I think SDN is being over loaded and confusion exists, not just between Driv= en and Defined, but also what each of those does. The way i understood and a= lso being presented is, ONF SDN encompasses not just openflow, but network a= pplications with the help of northbound API between controller and applicati= ons. Where SDNP plays pivotal role in defining protocol elements and api to= interconnect network elements and applications. It is high time to gets the= terms identified along with clear definition of what it does, and more impo= rtantly, start using them in future conversations could alleviate the confus= ion. Cheers Sam Sent from my iPad On Feb 24, 2012, at 7:48 AM, Thomas Nadeau wrote: >=20 > On Feb 24, 2012, at 10:43 AM, Robert Raszuk wrote: >=20 >> Hi Tom, >>=20 >>>> You seem to suggest that Open Flow can be expanded to include services >>>> besides networking. >>>=20 >>> I think you misunderstood what I wrote. Software Defined Networks (i.e.:= >>> OpenFlow) is targeted at working at the hardware abstraction level only.= >>=20 >> That's completely inaccurate. >=20 > Not completely. *) > =20 >> SDN is all about network applications. You perhaps are confusing it with O= NF which indeed at this point is focused on defining OpenFlow protocol. >=20 > Software DRIVEN Networks is all about network applications *and* their i= nteraction with network services and elements, of which a > subset is Software *defined* Networks (I.e.: OpenFlow). We really need t= o pick a different term for Software Driven Networks because=20 > it is confusing everyone. People seem to equate "SDN" with OpenFlow withou= t being clear about the "D". >=20 > --Tom >=20 >=20 >=20 >> But protocols are not defined just by bunch of hardware enthusiasts. They= are defined to address specific software defined applications. >>=20 >> Best, >> R. >>=20 >>=20 >>=20 >> Software *Driven* Networks is >>> targeted at services and network elements. >>> There is a clear difference. >>>=20 >>> --Tom >>=20 >>=20 >=20 > _______________________________________________ > SDNP mailing list > SDNP@lucidvision.com > http://lucidvision.com/mailman/listinfo/sdnp From adalela@cisco.com Fri Feb 24 08:18:38 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E371921F8815 for ; Fri, 24 Feb 2012 08:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.305 X-Spam-Level: X-Spam-Status: No, score=-7.305 tagged_above=-999 required=5 tests=[AWL=3.294, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 6lkNQz0kp79R for ; Fri, 24 Feb 2012 08:18:37 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0FA21F8798 for ; Fri, 24 Feb 2012 08:18:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=3554; q=dns/txt; s=iport; t=1330100316; x=1331309916; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=8uA3xNyEMVswwqeaMKkX1hBPEYyEjQQeq7RY7oxdmWY=; b=QyxDgTj8vdU3HM6iHF4Kq+6ulQhjaX09jdw5EFa409BeVAlEWl2F9B6Y FP7IJ77DfqHLhhq7NfismNaaL1pRYi9eLUPpXupODnzHe0wsAnMMHHNas 6/ZnoIvGloniaapef59j6MgNHmcj8Phpb20ihVsoux2OpczMMSxdQqjxk o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAKC3R09Io8UY/2dsb2JhbABEtA6BcwEBAQMBAQEBDwEUCQo0CwwEAgEIEQQBAQEKBhcBBgEmHwkIAQEEAQoICBMHh18FC5pIAZ5kjHwDBAgVF0IWCoUeAjEDBAMCAwUBAQMEAgIECQEFAwMEgkpjBIhNn2U X-IronPort-AV: E=Sophos;i="4.73,476,1325462400"; d="scan'208";a="6334568" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 24 Feb 2012 16:18:34 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1OGIYie029642; Fri, 24 Feb 2012 16:18:34 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Feb 2012 21:48:34 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Feb 2012 21:48:32 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C51030E0C31@XMB-BGL-416.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sop] [Sdnp] Fwd: SOP and SDN Question Thread-Index: AczzDq9A5Dko/v1zSZG0BAGY8kO3XwAACiSg References: <353D9CCB-2576-4A88-AAFC-DCE82FAF1101@lucidvision.com><4F47B03C.8070301@raszuk.net><2FB85049-EE2C-4D28-80A3-D2364B2FDB42@lucidvision.com> From: "Ashish Dalela (adalela)" To: "Sam Aldrin" , "Thomas Nadeau" X-OriginalArrivalTime: 24 Feb 2012 16:18:34.0283 (UTC) FILETIME=[F4BA97B0:01CCF30F] Cc: sdnp@lucidvision.com, sop@ietf.org, robert@raszuk.net Subject: Re: [sop] [Sdnp] Fwd: SOP and SDN Question X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 16:18:38 -0000 One of the questions I had on an earlier thread was a comparison / contrast between the Application <--> Controller <--> Infrastructure model versus the Controller <--> {Application / Infrastructure} model. As an example, what happens if the application that is supposed to provision the network for its purposes fails (because of software or underlying infrastructure failures)? Who bootstraps the infrastructure and then the application? The second issue I wonder is the nature of the control SDN (D being whatever it is) wants to exercise over the network. As an example, one blog recently talked about why OF not good for solving the distributed forwarding state problem, but good solution for solving global optimization issues. http://networkheresy.wordpress.com/2011/11/17/is-openflowsdn-good-at-for warding/ What stand does SDNP take regarding this? Thanks, Ashish -----Original Message----- From: sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] On Behalf Of Sam Aldrin Sent: Friday, February 24, 2012 9:39 PM To: Thomas Nadeau Cc: sdnp@lucidvision.com; sop@ietf.org; robert@raszuk.net Subject: Re: [sop] [Sdnp] Fwd: SOP and SDN Question I think SDN is being over loaded and confusion exists, not just between Driven and Defined, but also what each of those does. The way i understood and also being presented is, ONF SDN encompasses not just openflow, but network applications with the help of northbound API between controller and applications. Where SDNP plays pivotal role in defining protocol elements and api to interconnect network elements and applications. It is high time to gets the terms identified along with clear definition of what it does, and more importantly, start using them in future conversations could alleviate the confusion. Cheers Sam Sent from my iPad On Feb 24, 2012, at 7:48 AM, Thomas Nadeau wrote: >=20 > On Feb 24, 2012, at 10:43 AM, Robert Raszuk wrote: >=20 >> Hi Tom, >>=20 >>>> You seem to suggest that Open Flow can be expanded to include services >>>> besides networking. >>>=20 >>> I think you misunderstood what I wrote. Software Defined Networks (i.e.: >>> OpenFlow) is targeted at working at the hardware abstraction level only. >>=20 >> That's completely inaccurate. >=20 > Not completely. *) > =20 >> SDN is all about network applications. You perhaps are confusing it with ONF which indeed at this point is focused on defining OpenFlow protocol. >=20 > Software DRIVEN Networks is all about network applications *and* their interaction with network services and elements, of which a > subset is Software *defined* Networks (I.e.: OpenFlow). We really need to pick a different term for Software Driven Networks because=20 > it is confusing everyone. People seem to equate "SDN" with OpenFlow without being clear about the "D". >=20 > --Tom >=20 >=20 >=20 >> But protocols are not defined just by bunch of hardware enthusiasts. They are defined to address specific software defined applications. >>=20 >> Best, >> R. >>=20 >>=20 >>=20 >> Software *Driven* Networks is >>> targeted at services and network elements. >>> There is a clear difference. >>>=20 >>> --Tom >>=20 >>=20 >=20 > _______________________________________________ > SDNP mailing list > SDNP@lucidvision.com > http://lucidvision.com/mailman/listinfo/sdnp _______________________________________________ sop mailing list sop@ietf.org https://www.ietf.org/mailman/listinfo/sop From mach.chen@huawei.com Fri Feb 24 17:14:32 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F5121F8531 for ; Fri, 24 Feb 2012 17:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Ozc+OplO-BMN for ; Fri, 24 Feb 2012 17:14:31 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 25F4821F852C for ; Fri, 24 Feb 2012 17:14:31 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZX00AQTCRY83@szxga04-in.huawei.com> for sop@ietf.org; Sat, 25 Feb 2012 09:14:22 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZX000OVCRY7Z@szxga04-in.huawei.com> for sop@ietf.org; Sat, 25 Feb 2012 09:14:22 +0800 (CST) Received: from szxeml209-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHK04756; Sat, 25 Feb 2012 09:14:21 +0800 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 25 Feb 2012 09:13:54 +0800 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.81]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Sat, 25 Feb 2012 09:14:20 +0800 Date: Sat, 25 Feb 2012 01:14:19 +0000 From: Mach Chen In-reply-to: X-Originating-IP: [10.108.4.51] To: Sam Aldrin , Thomas Nadeau Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [sop] [Sdnp] Fwd: SOP and SDN Question Thread-index: AQHM8w6wewRbZJ7wBUu02X9I1J7zQpZMzv9w X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <353D9CCB-2576-4A88-AAFC-DCE82FAF1101@lucidvision.com> <4F47B03C.8070301@raszuk.net> <2FB85049-EE2C-4D28-80A3-D2364B2FDB42@lucidvision.com> Cc: "sdnp@lucidvision.com" , "sop@ietf.org" , "robert@raszuk.net" Subject: Re: [sop] [Sdnp] Fwd: SOP and SDN Question X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 01:14:32 -0000 Fully agree with Sam here! Best regards, Mach > -----Original Message----- > From: sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] On Behalf Of Sam > Aldrin > Sent: Saturday, February 25, 2012 12:09 AM > To: Thomas Nadeau > Cc: sdnp@lucidvision.com; sop@ietf.org; robert@raszuk.net > Subject: Re: [sop] [Sdnp] Fwd: SOP and SDN Question > > I think SDN is being over loaded and confusion exists, not just between Driven > and Defined, but also what each of those does. The way i understood and also > being presented is, ONF SDN encompasses not just openflow, but network > applications with the help of northbound API between controller and > applications. Where SDNP plays pivotal role in defining protocol elements and > api to interconnect network elements and applications. It is high time to gets > the terms identified along with clear definition of what it does, and more > importantly, start using them in future conversations could alleviate the > confusion. > > Cheers > Sam > > Sent from my iPad > > On Feb 24, 2012, at 7:48 AM, Thomas Nadeau > wrote: > > > > > On Feb 24, 2012, at 10:43 AM, Robert Raszuk wrote: > > > >> Hi Tom, > >> > >>>> You seem to suggest that Open Flow can be expanded to include services > >>>> besides networking. > >>> > >>> I think you misunderstood what I wrote. Software Defined Networks (i.e.: > >>> OpenFlow) is targeted at working at the hardware abstraction level only. > >> > >> That's completely inaccurate. > > > > Not completely. *) > > > >> SDN is all about network applications. You perhaps are confusing it with ONF > which indeed at this point is focused on defining OpenFlow protocol. > > > > Software DRIVEN Networks is all about network applications *and* their > interaction with network services and elements, of which a > > subset is Software *defined* Networks (I.e.: OpenFlow). We really need to > pick a different term for Software Driven Networks because > > it is confusing everyone. People seem to equate "SDN" with OpenFlow > without being clear about the "D". > > > > --Tom > > > > > > > >> But protocols are not defined just by bunch of hardware enthusiasts. They > are defined to address specific software defined applications. > >> > >> Best, > >> R. > >> > >> > >> > >> Software *Driven* Networks is > >>> targeted at services and network elements. > >>> There is a clear difference. > >>> > >>> --Tom > >> > >> > > > > _______________________________________________ > > SDNP mailing list > > SDNP@lucidvision.com > > http://lucidvision.com/mailman/listinfo/sdnp > _______________________________________________ > sop mailing list > sop@ietf.org > https://www.ietf.org/mailman/listinfo/sop From vishwas.ietf@gmail.com Mon Feb 27 11:55:57 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C139621F87DF for ; Mon, 27 Feb 2012 11:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.816 X-Spam-Level: X-Spam-Status: No, score=-3.816 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 zvlqTruMWa2n for ; Mon, 27 Feb 2012 11:55:56 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5062E21F87D7 for ; Mon, 27 Feb 2012 11:55:56 -0800 (PST) Received: by ggnp2 with SMTP id p2so585601ggn.31 for ; Mon, 27 Feb 2012 11:55:55 -0800 (PST) Received-SPF: pass (google.com: domain of vishwas.ietf@gmail.com designates 10.60.27.6 as permitted sender) client-ip=10.60.27.6; Authentication-Results: mr.google.com; spf=pass (google.com: domain of vishwas.ietf@gmail.com designates 10.60.27.6 as permitted sender) smtp.mail=vishwas.ietf@gmail.com; dkim=pass header.i=vishwas.ietf@gmail.com Received: from mr.google.com ([10.60.27.6]) by 10.60.27.6 with SMTP id p6mr6592399oeg.36.1330372555849 (num_hops = 1); Mon, 27 Feb 2012 11:55:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rtsl8YagJs0rCY7O2iiMF+dHGjokCCx5H1p9YqHUrME=; b=h4OKDn5LWm5Rlvnn/551shzku8A+aCHUfpQhiFnZjYNkE8ztwNR+9xhWbdTPsd2Dst ZdyppH46G5gJn3SGMRKl/Qpwg1J87b9uqD+S7eEvkRKaJqc6BdEwUtw6p5akxPTFhTl3 1Z6lNUHLqBPJDGSeU1Yxp4EltNOrKK0jFkudU= MIME-Version: 1.0 Received: by 10.60.27.6 with SMTP id p6mr5759927oeg.36.1330372555766; Mon, 27 Feb 2012 11:55:55 -0800 (PST) Received: by 10.182.165.1 with HTTP; Mon, 27 Feb 2012 11:55:55 -0800 (PST) In-Reply-To: References: Date: Mon, 27 Feb 2012 11:55:55 -0800 Message-ID: From: Vishwas Manral To: Michael Hammer Content-Type: multipart/alternative; boundary=e89a8fb1ef189afa3e04b9f77fbe Cc: sop@ietf.org Subject: Re: [sop] SOP Requirements X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 19:55:57 -0000 --e89a8fb1ef189afa3e04b9f77fbe Content-Type: text/plain; charset=ISO-8859-1 Hi Michael, Sounds like we agree on most of the things, though I see the draft contradicting what we agree on. 1. Do we really see incompatibilities in the API's soar for say IaaS? The >> AWS API's seem to be the default standard adopted by most providers. From >> the little I know OpenStack based API's may be the alternative way and >> companies have built bridging layers to inter-operate between the same. >> > > > Seem? May be? Bridging layers? I think you are making the case for us. > :) > I'm sure Ashish will have more to say about APIs, but I would prefer there > be a de jure than a default, which in the long run is likely to change at > the whim of a single company, and perhaps not in a direction that everyone > would like. > What I am saying is we have 2 sets of API's and there are layers used to bridge the same. I know as services proliferate there could be a proliferation of distict API's but the same is true of the protocol layer too. > > >> 2. Instead of the term customer/ user can we instead use the term >> "consumer". Something like "cloud subscriber" etc could be used. All I am >> saying is can we use standard terms here. >> > > We can settle on specific terms to use, just so long as we keep the > distinction between the entity (enterprise?) that provisions the software > in the cloud, and the user of that software, which could be an employee or > a user in the general public. Using a SIP Proxy as a Service, the operator > of the Proxy provisions it with a CREATE, but the user is the one sending > INVITEs through it. Make sense? > The NIST document uses terms and we should try to use similar terms as far as possible. > > >> 3. Is orchestration about creating services (from the cloud providers >> perspective), or an instance of a service (for a particular user)? I think >> it is the latter, but doesn't sound so from the definition. >> > > Orchestration is about the on-demand provisioning of the > compute/storage/network/XaaS in the cloud by the subscriber/customer. Once > provisioned, the service can provide services to the intended user. We are > trying to be general here. Need to keep provisioning and operations > distinct. "Service" is occurring in levels. > Correct but the draft seems to differ. > > >> 4. How is Service Domain Name different from a URI? Aren't they the same? >> > > There is a distinction here between a class of services and running > instantiations of those services. Either may be hierarchically named. > Hmm. > > >> 5. Is Scenario -1 talking about all providers should provide the same >> services? I guess not. I think the idea should be the same set of services >> should be accessible from a cloud provider the same way. It however does >> not mean that all providers need to provide the same services, as it seems >> from the requirement. >> > > Agree. All providers may not provide the same set of services. > But, if two providers offer the same service, it should not require a new > customer protocol stack to do so. > And users should not know that they may be going to one provider or the > other when using the same service. > The requirement seems contradictory to what we agree. Similar for points below. Thanks, Vishwas > > >> 6. It seems for most purposes you are talking about users, but as such a >> user in an enterprise should be unaware of where the service is coming >> from. It is the role of the customer to actually provide clear demarcation >> so a user is unaware of the same. Interoperability with virtual provider is >> how companies achieve the same. >> > > Agree, and we would like that to be true for multi-provider cases as well. > I would go further to say that even a user not in the enterprise should be > unaware where the service is coming from. > > >> 7. I don't think you should mention providers should inter-operate with >> each other. That is a business decision. I think what you mean here is that >> providers should have a clear interoperable means should they wish to >> inter-operate. >> > > Yes. We want them to be able to inter-operate. Whether they want to is a > business decision. > > >> 8. Is it really a requirement for the Orchestration to allow >> inter-operation for all models? I would have thought we are focusing on the >> IaaS alone. >> > > We don't see a reason to limit it to just IaaS. We are looking several > years down the road here. > > >> 9. S-5 and S-3 sound like similar services to me. How are they different >> - vendor versus provider? >> > > We were considering cases where multiple companies are involved in > providing all the capabilities needed. One involved coordination within an > administrative domain, while the other involves independent administrative > domains. We didn't want to limit this to single company operations. Large > global providers may involve many companies. > > >> 10. I think one of the key requirements for SOP, is the ability to work >> across only a sub-set of the base services and allow for extensible >> services on top. There could be so many variants of the SaaS or even PaaS I >> am not sure how you would make every service inter-operate. >> > > There needs to be several layers of standards involved. This is an onion > not a single layer orange-peel. > Here we are trying to provide structure that allows easy extension, > substitution, and innovation at the more service-specific granular levels. > > >> 11. I think when a VM is moved the biggest issue is the ability to move >> the storage along with it. All other state is minor and minimal. >> > > I would say the networking is the biggest issue, but that is my bias. :0 > > >> 12. Section 6 seems to be relevent within a cloud too and not just >> between clouds. >> > > Agree. Internal to a cloud and from the customer to the cloud are the > simple cases. > We emphasize the inter-cloud cases to test the architecture for the worst > cases. > > >> 13. Doesn't CDN provide the ability to separate address and ability >> already? >> > > Probably needs more discussion. I see content as a specific scenario. > There you don't care which copy of data is accessed so long as you reach > it. In other types of services, a lot more control over who accesses what > is needed. > > >> 14. For Service discovery. management we wrote something quite a while >> back >> https://datatracker.ietf.org/doc/draft-yokota-opsawg-virtnw-service-management/ >> . >> >> Will take a look. Thanks. Mike > > >> Thanks, >> Vishwas >> >> _______________________________________________ >> sop mailing list >> sop@ietf.org >> https://www.ietf.org/mailman/listinfo/sop >> >> > --e89a8fb1ef189afa3e04b9f77fbe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Michael,

Sounds like we agree on most of the things, though I see= the draft contradicting what we agree on.

1. Do we really see incompatibilities in the API's soar for say IaaS? T= he AWS API's seem to be the default standard adopted by most providers.= From the little I know OpenStack based API's may be the alternative wa= y and companies have built bridging layers to inter-operate between the sam= e.


Seem? =A0May be? =A0Bridging lay= ers? =A0I think you are making the case for us. :)
I'm sure A= shish will have more to say about APIs, but I would prefer there be a de ju= re than a default, which in the long run is likely to change at the whim of= a single company, and perhaps not in a direction that everyone would like.=
What I am saying is we have 2 sets of API'= ;s and there are layers used to bridge the same. I know as services prolife= rate there could be a proliferation of distict API's but the same is tr= ue of the protocol layer too.
=A0
=A0
2. Instead of the term customer/ user can we instead use the term "con= sumer". Something like "cloud subscriber" etc could be used.= All I am saying is can we use standard terms here.

We can settle on specific terms to use, just so long a= s we keep the distinction between the entity (enterprise?) that provisions = the software in the cloud, and the user of that software, which could be an= employee or a user in the general public. =A0Using a SIP Proxy as a Servic= e, the operator of the Proxy provisions it with a CREATE, but the user is t= he one sending INVITEs through it. =A0Make sense?
The NIST document uses terms and we should tr= y to use similar terms as far as possible.
=A0
=A0
3. Is orchestration about crea= ting services (from the cloud providers perspective), or an instance of a s= ervice (for a particular user)? I think it is the latter, but doesn't s= ound so from the definition.

Orchestration is about the on-demand= provisioning of the compute/storage/network/XaaS in the cloud by the subsc= riber/customer. =A0Once provisioned, the service can provide services to th= e intended user. =A0We are trying to be general here. =A0Need to keep provi= sioning and operations distinct. =A0"Service" is occurring in lev= els.
Correct but the draft seems to differ.
=A0=
=A0
4. How is Service Domain Name different from a URI? Aren't they the sam= e?

There is a distinction here be= tween a class of services and running instantiations of those services. =A0= Either may be hierarchically named.
Hmm.
=A0
=
=A0
5. Is Scenario -1 talking abou= t all providers should provide the same services? I guess not. I think the = idea should be the same set of services should be accessible from a cloud p= rovider the same way. It however does not mean that all providers need to p= rovide the same services, as it seems from the requirement.

Agree. =A0All providers may not prov= ide the same set of services. =A0
But, if two providers offer the= same service, it should not require a new customer protocol stack to do so= .
And users should not know that they may be going to one provider or th= e other when using the same service.
The requirement seems contradictory to what= we agree. Similar for points below.

Thanks,
Vishwas
=A0
=A0
6. It seems for most purposes you are talking about users, but as such a us= er in an enterprise should be unaware of where the service is coming from. = It is the role of the customer to actually provide clear demarcation so a u= ser is unaware of the same. Interoperability with virtual provider is how c= ompanies achieve the same.

Agree, and we would like that to be = true for multi-provider cases as well.
I would go further to say = that even a user not in the enterprise should be unaware where the service = is coming from.
=A0
7. I don't think you should mention providers should inter-operate with= each other. That is a business decision. I think what you mean here is tha= t providers should have a clear interoperable means should they wish to int= er-operate.

Yes. =A0We want them to be able to i= nter-operate. =A0Whether they want to is a business decision.
=A0
8. Is it really a requirement for the Orchestration to allow inter-operatio= n for all models? I would have thought we are focusing on the IaaS alone.

We don't see a reason to limit= it to just IaaS. =A0We are looking several years down the road here.
=A0
9. S-5 and S-3 sound like simi= lar services to me. How are they different - vendor versus provider?

We were considering cases where multiple companie= s are involved in providing all the capabilities needed. =A0One involved co= ordination within an administrative domain, while the other involves indepe= ndent administrative domains. =A0We didn't want to limit this to single= company operations. =A0Large global providers may involve many companies.<= /div>
=A0
10. I think one of the key requirements for SOP, is the ability to work acr= oss only a sub-set of the base services and allow for extensible services o= n top. There could be so many variants of the SaaS or even PaaS I am not su= re how you would make every service inter-operate.

There needs to be several layers of = standards involved. =A0This is an onion not a single layer orange-peel.
Here we are trying to provide structure that allows easy extension, = substitution, and innovation at the more service-specific granular levels.<= /div>
=A0
11. I think when a VM is moved the biggest issue is the ability to move the= storage along with it. All other state is minor and minimal.

I would say the networking is the biggest issu= e, but that is my bias. =A0:0
=A0
12. Section 6 seems to be rele= vent within a cloud too and not just between clouds.
<= br>
Agree. =A0Internal to a cloud and from the customer to the= cloud are the simple cases. =A0
We emphasize the inter-cloud cas= es to test the architecture for the worst cases.
=A0
13. Doesn't CDN provide the ability to separate address and ability alr= eady?

Probably needs more discuss= ion. =A0I see content as a specific scenario. =A0There you don't care w= hich copy of data is accessed so long as you reach it. =A0In other types of= services, a lot more control over who accesses what is needed.
=A0
14. For Service discovery. man= agement we wrote something quite a while back https://datatracker.ietf.org/doc/draft-yokota-opsawg-virtnw-service-m= anagement/.

Will take a look. =A0Thanks. =A0Mike
= =A0
Thanks,
Vishwas

_______________________________________________
sop mailing list
sop@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sop



--e89a8fb1ef189afa3e04b9f77fbe-- From adalela@cisco.com Tue Feb 28 05:26:23 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2FA21F859A for ; Tue, 28 Feb 2012 05:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.349 X-Spam-Level: X-Spam-Status: No, score=-7.349 tagged_above=-999 required=5 tests=[AWL=3.249, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 sD8rWlZ2kz2f for ; Tue, 28 Feb 2012 05:26:17 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 4D57C21F8568 for ; Tue, 28 Feb 2012 05:26:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=32411; q=dns/txt; s=iport; t=1330435575; x=1331645175; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=hNqte45OUNQP8mPer67hisLdjFc0tFsziVy8wnBVvYg=; b=bt+Ea8ZIUZ4y8MoPG7RFZqeO23CSgER4aYaWXHJSBRphFknnJt1QSeXh 39NSN95Ri56OmML7dZR6by6aYW6uuc+7f57h9klInRU+h7cD/9FMYYmqW p6MdNhGgSobz8njtahAfRC82D+qFBOSUQByojF29ughJZV6UUQ1bmqx/G U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAPzUTE9Io8UY/2dsb2JhbABDglGyL4FzAQEBAwEBAQEPAQkRAz4LEAIBCBEBAwEBCwYQAQYBBgEmHwMGCAEBBAEKCAgXA4dfBQugeAGXPQSJdwkGgm4BBQEBAQECAgEIBAEBBAEBAQIIAUWEbgEVCg0BEQMzARgGGoJJYwSITZ9qgU0BBw X-IronPort-AV: E=Sophos;i="4.73,496,1325462400"; d="scan'208,217";a="6569833" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 28 Feb 2012 13:26:13 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1SDQ9J7006368; Tue, 28 Feb 2012 13:26:12 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Feb 2012 18:56:11 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCF61C.89AADEF1" Date: Tue, 28 Feb 2012 18:56:10 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C51030E1263@XMB-BGL-416.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sop] SOP Requirements Thread-Index: Acz1idsb+bhdbUC0TLeYBZtWhGkFrgAjxSvQ References: From: "Ashish Dalela (adalela)" To: "Vishwas Manral" , "Michael Hammer" X-OriginalArrivalTime: 28 Feb 2012 13:26:11.0910 (UTC) FILETIME=[89D8B660:01CCF61C] Cc: sop@ietf.org Subject: Re: [sop] SOP Requirements X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 13:26:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCF61C.89AADEF1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Vishwas, =20 >> What I am saying is we have 2 sets of API's and there are layers used to bridge the same.=20 =20 As the number of services increase or the complexity in a given service grows, this becomes very hard. Assume there is a service with N tunable parameters. You need at least N APIs that modify these parameters individually. Then permutations and combination of these parameters create hundreds of more APIs. That's just API bloat. And if you have to interoperate multiple instances of these APIs through bridges, it's just inviting more complexity. Another limitation is that when APIs have semantic incompatibilities, it becomes even harder to interoperate (syntax incompatibility is easier). =20 >From an operational standpoint, every new API introduction requires software upgrades to the controllers. That eventually hinders the rate of service creation. =20 >> I know as services proliferate there could be a proliferation of distict API's but the same is true of the protocol layer too. =20 That won't happen if we separate service-independent and service-dependent pieces. An example of that is SNMP. SNMP is device/service independent. MIB defines the specific service/device. If you have a standard protocol to manage a device, then you just have to add a new MIB to start managing it. You don't need to upgrade all the intermediate systems - hardware or software.=20 =20 BTW, I'm not advocating SNMP here because SNMP has many shortcomings in terms of network discovery, capability discovery, advertisements, transactions, etc. But, we need to keep in mind that API proliferation is inevitable as services proliferate. Protocol proliferation is not inevitable. Similar separation has been done in the past in SIP/SDP, HTTP/HTML, SMTP/MIME. That separation allows anyone to send any content in email to anyone. Or download any web-page, or have any type of codec (voice or video) use the same protocol. =20 If you compare the success and widespread use of above mentioned protocols the value of separation between service-independent and service-dependent seems pretty convincing. =20 >> Correct but the draft seems to differ. =20 Service and instance of service are (and can be) interchangeably used. Is bandwidth a service or an instance of a service? I think this is more semantics. =20 >> The requirement seems contradictory to what we agree. Similar for points below. =20 The requirement is really that services are portable across providers. I think it is fair to say (as you also agree) that a user must know where they are going for a service. After all, they will have to pay for the service and they ought to know in advance who are they going to receive a monthly check from.=20 =20 Thanks, Ashish =20 =20 From: sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] On Behalf Of Vishwas Manral Sent: Tuesday, February 28, 2012 1:26 AM To: Michael Hammer Cc: sop@ietf.org Subject: Re: [sop] SOP Requirements =20 Hi Michael, Sounds like we agree on most of the things, though I see the draft contradicting what we agree on. 1. Do we really see incompatibilities in the API's soar for say IaaS? The AWS API's seem to be the default standard adopted by most providers. From the little I know OpenStack based API's may be the alternative way and companies have built bridging layers to inter-operate between the same. =20 =20 Seem? May be? Bridging layers? I think you are making the case for us. :) I'm sure Ashish will have more to say about APIs, but I would prefer there be a de jure than a default, which in the long run is likely to change at the whim of a single company, and perhaps not in a direction that everyone would like. What I am saying is we have 2 sets of API's and there are layers used to bridge the same. I know as services proliferate there could be a proliferation of distict API's but the same is true of the protocol layer too. =20 =20 2. Instead of the term customer/ user can we instead use the term "consumer". Something like "cloud subscriber" etc could be used. All I am saying is can we use standard terms here. =20 We can settle on specific terms to use, just so long as we keep the distinction between the entity (enterprise?) that provisions the software in the cloud, and the user of that software, which could be an employee or a user in the general public. Using a SIP Proxy as a Service, the operator of the Proxy provisions it with a CREATE, but the user is the one sending INVITEs through it. Make sense? The NIST document uses terms and we should try to use similar terms as far as possible. =20 =20 3. Is orchestration about creating services (from the cloud providers perspective), or an instance of a service (for a particular user)? I think it is the latter, but doesn't sound so from the definition. =20 Orchestration is about the on-demand provisioning of the compute/storage/network/XaaS in the cloud by the subscriber/customer. Once provisioned, the service can provide services to the intended user. We are trying to be general here. Need to keep provisioning and operations distinct. "Service" is occurring in levels. Correct but the draft seems to differ. =20 =20 4. How is Service Domain Name different from a URI? Aren't they the same? =20 There is a distinction here between a class of services and running instantiations of those services. Either may be hierarchically named. Hmm. =20 =20 5. Is Scenario -1 talking about all providers should provide the same services? I guess not. I think the idea should be the same set of services should be accessible from a cloud provider the same way. It however does not mean that all providers need to provide the same services, as it seems from the requirement. =20 Agree. All providers may not provide the same set of services. But, if two providers offer the same service, it should not require a new customer protocol stack to do so. And users should not know that they may be going to one provider or the other when using the same service. The requirement seems contradictory to what we agree. Similar for points below. Thanks, Vishwas =20 =20 6. It seems for most purposes you are talking about users, but as such a user in an enterprise should be unaware of where the service is coming from. It is the role of the customer to actually provide clear demarcation so a user is unaware of the same. Interoperability with virtual provider is how companies achieve the same. =20 Agree, and we would like that to be true for multi-provider cases as well. I would go further to say that even a user not in the enterprise should be unaware where the service is coming from. =20 7. I don't think you should mention providers should inter-operate with each other. That is a business decision. I think what you mean here is that providers should have a clear interoperable means should they wish to inter-operate. =20 Yes. We want them to be able to inter-operate. Whether they want to is a business decision. =20 8. Is it really a requirement for the Orchestration to allow inter-operation for all models? I would have thought we are focusing on the IaaS alone. =20 We don't see a reason to limit it to just IaaS. We are looking several years down the road here. =20 9. S-5 and S-3 sound like similar services to me. How are they different - vendor versus provider? =20 We were considering cases where multiple companies are involved in providing all the capabilities needed. One involved coordination within an administrative domain, while the other involves independent administrative domains. We didn't want to limit this to single company operations. Large global providers may involve many companies. =20 10. I think one of the key requirements for SOP, is the ability to work across only a sub-set of the base services and allow for extensible services on top. There could be so many variants of the SaaS or even PaaS I am not sure how you would make every service inter-operate. =20 There needs to be several layers of standards involved. This is an onion not a single layer orange-peel. Here we are trying to provide structure that allows easy extension, substitution, and innovation at the more service-specific granular levels. =20 11. I think when a VM is moved the biggest issue is the ability to move the storage along with it. All other state is minor and minimal. =20 I would say the networking is the biggest issue, but that is my bias. :0 =20 12. Section 6 seems to be relevent within a cloud too and not just between clouds. =20 Agree. Internal to a cloud and from the customer to the cloud are the simple cases. =20 We emphasize the inter-cloud cases to test the architecture for the worst cases. =20 13. Doesn't CDN provide the ability to separate address and ability already? =20 Probably needs more discussion. I see content as a specific scenario. There you don't care which copy of data is accessed so long as you reach it. In other types of services, a lot more control over who accesses what is needed. =20 14. For Service discovery. management we wrote something quite a while back https://datatracker.ietf.org/doc/draft-yokota-opsawg-virtnw-service-mana gement/. Will take a look. Thanks. Mike =20 Thanks, Vishwas =09 _______________________________________________ sop mailing list sop@ietf.org https://www.ietf.org/mailman/listinfo/sop =20 =20 ------_=_NextPart_001_01CCF61C.89AADEF1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Vishwas,

 

>> What I am saying is we have 2 sets of API's = and there are layers used to bridge the same.

 

As the number of services increase or the complexity in a given = service grows, this becomes very hard. Assume there is a service with N = tunable parameters. You need at least N APIs that modify these = parameters individually. Then permutations and combination of these = parameters create hundreds of more APIs. That’s just API bloat. = And if you have to interoperate multiple instances of these APIs through = bridges, it’s just inviting more complexity. Another limitation is = that when APIs have semantic incompatibilities, it becomes even harder = to interoperate (syntax incompatibility is = easier).

 

From an operational standpoint, every new API introduction requires = software upgrades to the controllers. That eventually hinders the rate = of service creation.

 

>> I = know as services proliferate there could be a proliferation of distict = API's but the same is true of the protocol layer = too.
 

That won’t happen if we separate service-independent and = service-dependent pieces. An example of that is SNMP. SNMP is = device/service independent. MIB defines the specific service/device. If = you have a standard protocol to manage a device, then you just have to = add a new MIB to start managing it. You don’t need to upgrade all = the intermediate systems – hardware or software. =

 

BTW, I’m not advocating SNMP here because SNMP has many = shortcomings in terms of network discovery, capability discovery, = advertisements, transactions, etc. But, we need to keep in mind that API = proliferation is inevitable as services proliferate. Protocol = proliferation is not inevitable. Similar separation has been done in the = past in SIP/SDP, HTTP/HTML, SMTP/MIME. That separation allows anyone to = send any content in email to anyone. Or download any web-page, or have = any type of codec (voice or video) use the same = protocol.

 

If you compare the success and widespread use of above mentioned = protocols the value of separation between service-independent and = service-dependent seems pretty convincing.

 

>> Correct but the draft seems to differ.

 

Service and instance of service are (and can be) interchangeably = used. Is bandwidth a service or an instance of a service? I think this = is more semantics.

 

>> The requirement seems contradictory to what we agree. = Similar for points below.

 

The requirement is really that services are portable across = providers. I think it is fair to say (as you also agree) that a user = must know where they are going for a service. After all, they will have = to pay for the service and they ought to know in advance who are they = going to receive a monthly check from.

 

Thanks, Ashish

 

 

From:= = sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] On Behalf Of = Vishwas Manral
Sent: Tuesday, February 28, 2012 1:26 = AM
To: Michael Hammer
Cc: = sop@ietf.org
Subject: Re: [sop] SOP = Requirements

 

Hi Michael,

Sounds like we agree = on most of the things, though I see the draft contradicting what we = agree on.

1. Do we = really see incompatibilities in the API's soar for say IaaS? The AWS = API's seem to be the default standard adopted by most providers. From = the little I know OpenStack based API's may be the alternative way and = companies have built bridging layers to inter-operate between the = same.

 

 

Seem?  May be?  Bridging layers?  I = think you are making the case for us. :)

I'm sure Ashish will have more to say about APIs, but = I would prefer there be a de jure than a default, which in the long run = is likely to change at the whim of a single company, and perhaps not in = a direction that everyone would = like.

What I am saying is we have 2 sets of API's and there = are layers used to bridge the same. I know as services proliferate there = could be a proliferation of distict API's but the same is true of the = protocol layer too.
 

 

2. = Instead of the term customer/ user can we instead use the term = "consumer". Something like "cloud subscriber" etc = could be used. All I am saying is can we use standard terms = here.

 

We can settle on specific terms to use, just so long = as we keep the distinction between the entity (enterprise?) that = provisions the software in the cloud, and the user of that software, = which could be an employee or a user in the general public.  Using = a SIP Proxy as a Service, the operator of the Proxy provisions it with a = CREATE, but the user is the one sending INVITEs through it.  Make = sense?

The NIST document uses terms and we should try to use = similar terms as far as = possible.
 

 

3. Is = orchestration about creating services (from the cloud providers = perspective), or an instance of a service (for a particular user)? I = think it is the latter, but doesn't sound so from the = definition.

 

Orchestration is about the on-demand provisioning of = the compute/storage/network/XaaS in the cloud by the = subscriber/customer.  Once provisioned, the service can provide = services to the intended user.  We are trying to be general here. =  Need to keep provisioning and operations distinct. =  "Service" is occurring in = levels.

Correct but the draft seems to = differ.
 

 

4. How is = Service Domain Name different from a URI? Aren't they the = same?

 

There is a distinction here between a class of = services and running instantiations of those services.  Either may = be hierarchically = named.

Hmm.
 

 

5. Is = Scenario -1 talking about all providers should provide the same = services? I guess not. I think the idea should be the same set of = services should be accessible from a cloud provider the same way. It = however does not mean that all providers need to provide the same = services, as it seems from the = requirement.

 

Agree.  All providers may not provide the same = set of services.  

But, if two providers offer the same service, it = should not require a new customer protocol stack to do = so.

And users should not = know that they may be going to one provider or the other when using the = same service.

The requirement seems contradictory to what we agree. = Similar for points = below.

Thanks,
Vishwas
 

 

6. It = seems for most purposes you are talking about users, but as such a user = in an enterprise should be unaware of where the service is coming from. = It is the role of the customer to actually provide clear demarcation so = a user is unaware of the same. Interoperability with virtual provider is = how companies achieve the same.

 

Agree, and we would like that to be true for = multi-provider cases as well.

I would go further to say that even a user not in the = enterprise should be unaware where the service is coming = from.

 

7. I = don't think you should mention providers should inter-operate with each = other. That is a business decision. I think what you mean here is that = providers should have a clear interoperable means should they wish to = inter-operate.

 

Yes.  We want them to be able to inter-operate. =  Whether they want to is a business = decision.

 

8. Is it = really a requirement for the Orchestration to allow inter-operation for = all models? I would have thought we are focusing on the IaaS = alone.

 

We don't see a reason to limit it to just IaaS. =  We are looking several years down the road = here.

 

9. S-5 = and S-3 sound like similar services to me. How are they different - = vendor versus provider?

 

We were considering cases where multiple companies are = involved in providing all the capabilities needed.  One involved = coordination within an administrative domain, while the other involves = independent administrative domains.  We didn't want to limit this = to single company operations.  Large global providers may involve = many companies.

 

10. I = think one of the key requirements for SOP, is the ability to work across = only a sub-set of the base services and allow for extensible services on = top. There could be so many variants of the SaaS or even PaaS I am not = sure how you would make every service = inter-operate.

 

There needs to be several layers of standards = involved.  This is an onion not a single layer = orange-peel.

Here we are = trying to provide structure that allows easy extension, substitution, = and innovation at the more service-specific granular = levels.

 

11. I = think when a VM is moved the biggest issue is the ability to move the = storage along with it. All other state is minor and = minimal.

 

I would say the networking is the biggest issue, but = that is my bias.  :0

 

12. = Section 6 seems to be relevent within a cloud too and not just between = clouds.

 

Agree.  Internal to a cloud and from the customer = to the cloud are the simple cases.  

We emphasize the inter-cloud cases to test the = architecture for the worst cases.

 

13. = Doesn't CDN provide the ability to separate address and ability = already?

 

Probably needs more discussion.  I see content as = a specific scenario.  There you don't care which copy of data is = accessed so long as you reach it.  In other types of services, a = lot more control over who accesses what is = needed.

 

14. For Service discovery. management we = wrote something quite a while back https://datatracker.ietf.org/doc/draft-yokota-opsawg-vi= rtnw-service-management/.

Will take a look.  Thanks. =  Mike

 

Thanks,
Vishwas

________________= _______________________________
sop mailing list
sop@ietf.org
https://www.ietf.org/mailman/listinfo/sop

 

 

------_=_NextPart_001_01CCF61C.89AADEF1-- From hadi@mojatatu.com Tue Feb 28 06:23:21 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3977B21F8697 for ; Tue, 28 Feb 2012 06:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.306 X-Spam-Level: X-Spam-Status: No, score=-102.306 tagged_above=-999 required=5 tests=[AWL=0.671, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 g9qQMyq5oVA9 for ; Tue, 28 Feb 2012 06:23:20 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 69E9C21F8699 for ; Tue, 28 Feb 2012 06:23:20 -0800 (PST) Received: by bkuw5 with SMTP id w5so1677573bku.31 for ; Tue, 28 Feb 2012 06:23:19 -0800 (PST) Received-SPF: pass (google.com: domain of hadi@mojatatu.com designates 10.204.133.212 as permitted sender) client-ip=10.204.133.212; Authentication-Results: mr.google.com; spf=pass (google.com: domain of hadi@mojatatu.com designates 10.204.133.212 as permitted sender) smtp.mail=hadi@mojatatu.com Received: from mr.google.com ([10.204.133.212]) by 10.204.133.212 with SMTP id g20mr6845981bkt.71.1330438999578 (num_hops = 1); Tue, 28 Feb 2012 06:23:19 -0800 (PST) Received: by 10.204.133.212 with SMTP id g20mr5484371bkt.71.1330438999333; Tue, 28 Feb 2012 06:23:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.183.67 with HTTP; Tue, 28 Feb 2012 06:22:59 -0800 (PST) In-Reply-To: <618BE8B40039924EB9AED233D4A09C51030E1263@XMB-BGL-416.cisco.com> References: <618BE8B40039924EB9AED233D4A09C51030E1263@XMB-BGL-416.cisco.com> From: Jamal Hadi Salim Date: Tue, 28 Feb 2012 09:22:59 -0500 Message-ID: To: "Ashish Dalela (adalela)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnH0un2han7UXTzwIzyJJ0tS8uL1rgy+ODw7OR8DC2htI5aiacadIydUFBlk5fcb25zJemz Cc: Vishwas Manral , sop@ietf.org, Michael Hammer Subject: Re: [sop] SOP Requirements X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 14:23:21 -0000 Hi Ashish, On Tue, Feb 28, 2012 at 8:26 AM, Ashish Dalela (adalela) wrote: > > As the number of services increase or the complexity in a given service > grows, this becomes very hard. Assume there is a service with N tunable > parameters. You need at least N APIs that modify these parameters > individually. Then permutations and combination of these parameters creat= e > hundreds of more APIs. That=92s just API bloat. And if you have to > interoperate multiple instances of these APIs through bridges, it=92s jus= t > inviting more complexity. Another limitation is that when APIs have seman= tic > incompatibilities, it becomes even harder to interoperate (syntax > incompatibility is easier). > > > From an operational standpoint, every new API introduction requires softw= are > upgrades to the controllers. That eventually hinders the rate of service > creation. > This an _extremely important detail_ that is often missed by folks pushing OF for example as a service creation protocol (or even as a control-datapath proto= col). BTW: Have you looked at ForCES? I didnt see it mentioned in the drafts. To summarize: The initial goals were to separate a datapath vs a controller. There are ve= ry few verbs and the entity being controlled/configured can be formally modele= d using an XML language to define logical functional blocks. The blocks (whic= h could represent services) could be instantiated and hierachy of the differe= nt components/attributes is inherently built. Although the definitions are in XML, the protocol is binary for efficiency reasons. ForCES has discovery, capability discovery, advertisements, transactions, e= tc. The underlying transport could be customized for specific problem domains (I suspect service creation would have slightly different needs than a rout= er's control/line card transport desires). cheers, jamal From mphmmr@gmail.com Tue Feb 28 07:31:53 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2197B21F864D for ; Tue, 28 Feb 2012 07:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.462 X-Spam-Level: X-Spam-Status: No, score=-3.462 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 9Ti-wFeQ3TV5 for ; Tue, 28 Feb 2012 07:31:51 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C27E821F8647 for ; Tue, 28 Feb 2012 07:31:50 -0800 (PST) Received: by lagj5 with SMTP id j5so3920331lag.31 for ; Tue, 28 Feb 2012 07:31:49 -0800 (PST) Received-SPF: pass (google.com: domain of mphmmr@gmail.com designates 10.112.23.1 as permitted sender) client-ip=10.112.23.1; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mphmmr@gmail.com designates 10.112.23.1 as permitted sender) smtp.mail=mphmmr@gmail.com; dkim=pass header.i=mphmmr@gmail.com Received: from mr.google.com ([10.112.23.1]) by 10.112.23.1 with SMTP id i1mr1635658lbf.21.1330443109854 (num_hops = 1); Tue, 28 Feb 2012 07:31:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DpKSZ4e7MCbPW/8JVQ+7iH/+ccpNYYPIq9YpGS7NW+Q=; b=mSrzub9NH4PI7hK3Jg7tTzIn55zJoQLddS9VtZBT8wSPBNBlBweJEsGfb1Xag7oIYX 0HaXPSZvJsmRGiDaaHxoa8ofJ8I5LhXDkKUsuvQ5ajojDuuzkHZV+pZwCH7EraOQL7CR Ppy4VPO0Xn5xnlebFLJOnd405lMNjg7RMkcuQ= MIME-Version: 1.0 Received: by 10.112.23.1 with SMTP id i1mr1327994lbf.21.1330443109733; Tue, 28 Feb 2012 07:31:49 -0800 (PST) Received: by 10.112.104.70 with HTTP; Tue, 28 Feb 2012 07:31:49 -0800 (PST) In-Reply-To: References: Date: Tue, 28 Feb 2012 10:31:49 -0500 Message-ID: From: Michael Hammer To: Vishwas Manral Content-Type: multipart/alternative; boundary=90e6ba308bc8f315ff04ba07ecd3 Cc: sop@ietf.org Subject: Re: [sop] SOP Requirements X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 15:31:53 -0000 --90e6ba308bc8f315ff04ba07ecd3 Content-Type: text/plain; charset=ISO-8859-1 Vishwas, I think Ashish responded to most of your comments. Quick response to others below: We could align with the NIST document terms if they coincide. Could you point to which document you are referring so I can verify we and they are defining the same thing. I was using terms very common in the industry and would be surprised if NIST is not also. Provisioning an XaaS versus using an XaaS: As with all documents it takes many revisions to get the words to clearly say what we mean. If you would point us to the specific text in a 1-1 email, we could work to adjust the text in the next version. "users should not know that they may be going to one provider or the other when using the same service" Let me elaborate a bit more on that. I did mean to say "user" and not "subscriber": Imagine the UCaaS case. The customer/subscriber is the operator of the SIP Proxy or Customer X. They know they are using CSP Y to host that proxy. Once the service is provisioned in the cloud, they could be open for business to Users A, B, C who get their UC service from X. A knows X, but has no clue that their SIP requests may end up at Y. Second there could be Cloud ecosystem: Customer X goes to CSP Y who outsources part of the service to CSP Z. So, X knows he is going to Y, but Z may be invisible to him. Make sense? Mike On Mon, Feb 27, 2012 at 2:55 PM, Vishwas Manral wrote: > Hi Michael, > > Sounds like we agree on most of the things, though I see the draft > contradicting what we agree on. > > 1. Do we really see incompatibilities in the API's soar for say IaaS? The >>> AWS API's seem to be the default standard adopted by most providers. From >>> the little I know OpenStack based API's may be the alternative way and >>> companies have built bridging layers to inter-operate between the same. >>> >> >> >> Seem? May be? Bridging layers? I think you are making the case for us. >> :) >> I'm sure Ashish will have more to say about APIs, but I would prefer >> there be a de jure than a default, which in the long run is likely to >> change at the whim of a single company, and perhaps not in a direction that >> everyone would like. >> > What I am saying is we have 2 sets of API's and there are layers used to > bridge the same. I know as services proliferate there could be a > proliferation of distict API's but the same is true of the protocol layer > too. > > >> >> >>> 2. Instead of the term customer/ user can we instead use the term >>> "consumer". Something like "cloud subscriber" etc could be used. All I am >>> saying is can we use standard terms here. >>> >> >> We can settle on specific terms to use, just so long as we keep the >> distinction between the entity (enterprise?) that provisions the software >> in the cloud, and the user of that software, which could be an employee or >> a user in the general public. Using a SIP Proxy as a Service, the operator >> of the Proxy provisions it with a CREATE, but the user is the one sending >> INVITEs through it. Make sense? >> > The NIST document uses terms and we should try to use similar terms as far > as possible. > > >> >> >>> 3. Is orchestration about creating services (from the cloud providers >>> perspective), or an instance of a service (for a particular user)? I think >>> it is the latter, but doesn't sound so from the definition. >>> >> >> Orchestration is about the on-demand provisioning of the >> compute/storage/network/XaaS in the cloud by the subscriber/customer. Once >> provisioned, the service can provide services to the intended user. We are >> trying to be general here. Need to keep provisioning and operations >> distinct. "Service" is occurring in levels. >> > Correct but the draft seems to differ. > > >> >> >>> 4. How is Service Domain Name different from a URI? Aren't they the same? >>> >> >> There is a distinction here between a class of services and running >> instantiations of those services. Either may be hierarchically named. >> > Hmm. > > >> >> >>> 5. Is Scenario -1 talking about all providers should provide the same >>> services? I guess not. I think the idea should be the same set of services >>> should be accessible from a cloud provider the same way. It however does >>> not mean that all providers need to provide the same services, as it seems >>> from the requirement. >>> >> >> Agree. All providers may not provide the same set of services. >> But, if two providers offer the same service, it should not require a new >> customer protocol stack to do so. >> And users should not know that they may be going to one provider or the >> other when using the same service. >> > The requirement seems contradictory to what we agree. Similar for points > below. > > Thanks, > Vishwas > > >> >> >>> 6. It seems for most purposes you are talking about users, but as such a >>> user in an enterprise should be unaware of where the service is coming >>> from. It is the role of the customer to actually provide clear demarcation >>> so a user is unaware of the same. Interoperability with virtual provider is >>> how companies achieve the same. >>> >> >> Agree, and we would like that to be true for multi-provider cases as well. >> I would go further to say that even a user not in the enterprise should >> be unaware where the service is coming from. >> >> >>> 7. I don't think you should mention providers should inter-operate with >>> each other. That is a business decision. I think what you mean here is that >>> providers should have a clear interoperable means should they wish to >>> inter-operate. >>> >> >> Yes. We want them to be able to inter-operate. Whether they want to is >> a business decision. >> >> >>> 8. Is it really a requirement for the Orchestration to allow >>> inter-operation for all models? I would have thought we are focusing on the >>> IaaS alone. >>> >> >> We don't see a reason to limit it to just IaaS. We are looking several >> years down the road here. >> >> >>> 9. S-5 and S-3 sound like similar services to me. How are they different >>> - vendor versus provider? >>> >> >> We were considering cases where multiple companies are involved in >> providing all the capabilities needed. One involved coordination within an >> administrative domain, while the other involves independent administrative >> domains. We didn't want to limit this to single company operations. Large >> global providers may involve many companies. >> >> >>> 10. I think one of the key requirements for SOP, is the ability to work >>> across only a sub-set of the base services and allow for extensible >>> services on top. There could be so many variants of the SaaS or even PaaS I >>> am not sure how you would make every service inter-operate. >>> >> >> There needs to be several layers of standards involved. This is an onion >> not a single layer orange-peel. >> Here we are trying to provide structure that allows easy extension, >> substitution, and innovation at the more service-specific granular levels. >> >> >>> 11. I think when a VM is moved the biggest issue is the ability to move >>> the storage along with it. All other state is minor and minimal. >>> >> >> I would say the networking is the biggest issue, but that is my bias. :0 >> >> >>> 12. Section 6 seems to be relevent within a cloud too and not just >>> between clouds. >>> >> >> Agree. Internal to a cloud and from the customer to the cloud are the >> simple cases. >> We emphasize the inter-cloud cases to test the architecture for the worst >> cases. >> >> >>> 13. Doesn't CDN provide the ability to separate address and ability >>> already? >>> >> >> Probably needs more discussion. I see content as a specific scenario. >> There you don't care which copy of data is accessed so long as you reach >> it. In other types of services, a lot more control over who accesses what >> is needed. >> >> >>> 14. For Service discovery. management we wrote something quite a while >>> back >>> https://datatracker.ietf.org/doc/draft-yokota-opsawg-virtnw-service-management/ >>> . >>> >>> Will take a look. Thanks. Mike >> >> >>> Thanks, >>> Vishwas >>> >>> _______________________________________________ >>> sop mailing list >>> sop@ietf.org >>> https://www.ietf.org/mailman/listinfo/sop >>> >>> >> > --90e6ba308bc8f315ff04ba07ecd3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Vishwas,

I think Ashish responded to most of your commen= ts. =A0Quick response to others below:

We could al= ign with the NIST document terms if they coincide. =A0Could you point to wh= ich document you are referring so I can verify we and they are defining the= same thing. =A0I was using terms very common in the industry and would be = surprised if NIST is not also.

Provisioning an XaaS versus using an XaaS: =A0As with a= ll documents it takes many revisions to get the words to clearly say what w= e mean. =A0If you would point us to the specific text in a 1-1 email, we co= uld work to adjust the text in the next version.

"users should not know that they may be going to o= ne provider or the other when using the same service"
Let me= elaborate a bit more on that. =A0I did mean to say "user" and no= t "subscriber":
Imagine the UCaaS case. =A0The customer/subscriber is the = operator of the SIP Proxy or Customer X. =A0They know they are using CSP Y = to host that proxy. =A0Once the service is provisioned in the cloud, they c= ould be open for business to Users A, B, C who get their UC service from X.= =A0A knows X, but has no clue that their SIP requests may end up at Y.

Second there could be Cloud ecosystem:= =A0Customer X goes to CSP Y who outsources part of the service to CSP Z. = =A0So, X knows he is going to Y, but Z may be invisible to him.

Make sense?

Mike<= /div>


On Mon, Feb 27, 20= 12 at 2:55 PM, Vishwas Manral <vishwas.ietf@gmail.com> wrote:
Hi Michael,

Sounds like we agree on m= ost of the things, though I see the draft contradicting what we agree on.
1. Do we really see incompatibilities in the API's soar for say IaaS? T= he AWS API's seem to be the default standard adopted by most providers.= From the little I know OpenStack based API's may be the alternative wa= y and companies have built bridging layers to inter-operate between the sam= e.


Seem? =A0May be? =A0Bridging lay= ers? =A0I think you are making the case for us. :)
I'm sure A= shish will have more to say about APIs, but I would prefer there be a de ju= re than a default, which in the long run is likely to change at the whim of= a single company, and perhaps not in a direction that everyone would like.=
What I am saying is we have 2 sets of A= PI's and there are layers used to bridge the same. I know as services p= roliferate there could be a proliferation of distict API's but the same= is true of the protocol layer too.
=A0
=A0
2. Instead of the term customer/ user can we instead use the term "con= sumer". Something like "cloud subscriber" etc could be used.= All I am saying is can we use standard terms here.

We can settle on specific terms to use, just so long a= s we keep the distinction between the entity (enterprise?) that provisions = the software in the cloud, and the user of that software, which could be an= employee or a user in the general public. =A0Using a SIP Proxy as a Servic= e, the operator of the Proxy provisions it with a CREATE, but the user is t= he one sending INVITEs through it. =A0Make sense?
The NIST document uses terms and we sho= uld try to use similar terms as far as possible.
=A0
=A0
3. Is orchestration about crea= ting services (from the cloud providers perspective), or an instance of a s= ervice (for a particular user)? I think it is the latter, but doesn't s= ound so from the definition.

Orchestration is about the on-demand= provisioning of the compute/storage/network/XaaS in the cloud by the subsc= riber/customer. =A0Once provisioned, the service can provide services to th= e intended user. =A0We are trying to be general here. =A0Need to keep provi= sioning and operations distinct. =A0"Service" is occurring in lev= els.
Correct but the draft seems to differ.<= br>=A0
=A0
4. How is Service Domain Name different from a URI? Aren't they the sam= e?

There is a distinction here be= tween a class of services and running instantiations of those services. =A0= Either may be hierarchically named.
Hmm.
=A0
<= div class=3D"im">
=A0
5. Is Scenario -1 talking abou= t all providers should provide the same services? I guess not. I think the = idea should be the same set of services should be accessible from a cloud p= rovider the same way. It however does not mean that all providers need to p= rovide the same services, as it seems from the requirement.

Agree. =A0All providers may not prov= ide the same set of services. =A0
But, if two providers offer the= same service, it should not require a new customer protocol stack to do so= .
And users should not know that they may be going to one provider or th= e other when using the same service.
The requirement seems contradictory to what we agr= ee. Similar for points below.

Thanks,
Vishwas
=A0
<= div>=A0
6. It seems for most purposes you are talking about users, but as such a us= er in an enterprise should be unaware of where the service is coming from. = It is the role of the customer to actually provide clear demarcation so a u= ser is unaware of the same. Interoperability with virtual provider is how c= ompanies achieve the same.

Agree, and we would like that to be = true for multi-provider cases as well.
I would go further to say = that even a user not in the enterprise should be unaware where the service = is coming from.
=A0
7. I don't think you should mention providers should inter-operate with= each other. That is a business decision. I think what you mean here is tha= t providers should have a clear interoperable means should they wish to int= er-operate.

Yes. =A0We want them to be able to i= nter-operate. =A0Whether they want to is a business decision.
=A0
8. Is it really a requirement for the Orchestration to allow inter-operatio= n for all models? I would have thought we are focusing on the IaaS alone.

We don't see a reason to limit= it to just IaaS. =A0We are looking several years down the road here.
=A0
9. S-5 and S-3 sound like simi= lar services to me. How are they different - vendor versus provider?

We were considering cases where multiple companie= s are involved in providing all the capabilities needed. =A0One involved co= ordination within an administrative domain, while the other involves indepe= ndent administrative domains. =A0We didn't want to limit this to single= company operations. =A0Large global providers may involve many companies.<= /div>
=A0
10. I think one of the key requirements for SOP, is the ability to work acr= oss only a sub-set of the base services and allow for extensible services o= n top. There could be so many variants of the SaaS or even PaaS I am not su= re how you would make every service inter-operate.

There needs to be several layers of = standards involved. =A0This is an onion not a single layer orange-peel.
Here we are trying to provide structure that allows easy extension, = substitution, and innovation at the more service-specific granular levels.<= /div>
=A0
11. I think when a VM is moved the biggest issue is the ability to move the= storage along with it. All other state is minor and minimal.

I would say the networking is the biggest issu= e, but that is my bias. =A0:0
=A0
12. Section 6 seems to be rele= vent within a cloud too and not just between clouds.
<= br>
Agree. =A0Internal to a cloud and from the customer to the= cloud are the simple cases. =A0
We emphasize the inter-cloud cas= es to test the architecture for the worst cases.
=A0
13. Doesn't CDN provide the ability to separate address and ability alr= eady?

Probably needs more discuss= ion. =A0I see content as a specific scenario. =A0There you don't care w= hich copy of data is accessed so long as you reach it. =A0In other types of= services, a lot more control over who accesses what is needed.
=A0
14. For Service discovery. man= agement we wrote something quite a while back https://datatracker.ietf.org/doc/draft-yokota-opsawg-virtnw-service-m= anagement/.

Will take a look. =A0Thanks. =A0Mike
= =A0
Thanks,
Vishwas

_______________________________________________
sop mailing list
sop@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sop




--90e6ba308bc8f315ff04ba07ecd3-- From adalela@cisco.com Tue Feb 28 09:05:39 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30EC621F8643 for ; Tue, 28 Feb 2012 09:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.394 X-Spam-Level: X-Spam-Status: No, score=-7.394 tagged_above=-999 required=5 tests=[AWL=3.205, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 U42BZFEwiJN3 for ; Tue, 28 Feb 2012 09:05:38 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC9921F8566 for ; Tue, 28 Feb 2012 09:05:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=4871; q=dns/txt; s=iport; t=1330448737; x=1331658337; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Avk2xQWQ9oaD/GopnBUswVCmhTMnoF6uwI3liDy6lfc=; b=GMfLtfU2qGqvBs6k62qmd4IDq4/0FNnIiz5nRhXJ9UOMoovjyc6zwKJs ZSy+Mj2UD3zu238Mc+7FacCjd6aM78gSzXOa2vlsERDX8MUgwEEw8BZ/2 VIzrKyP2laiyiJ4AzF3snTMIA7VRi4WboJtCsDKVD/KFoiee3lju2xxgi 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAFIITU9Io8UY/2dsb2JhbABCtFmBdwEBAQMBAQEBDwEdCjQLDAQCAQgRBAEBCwYXAQYBJh8JCAEBBAsICBqHYQULmkEBnxEEiggGgnIDAQECBAMFAQQGAgIJAwJAFQuFDQMzAQ4KBgUVgkljBIhNn2qBTQE X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="6584149" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 28 Feb 2012 17:05:35 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1SH5ZQ5017698; Tue, 28 Feb 2012 17:05:35 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Feb 2012 22:35:35 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Feb 2012 22:35:33 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C51031BC083@XMB-BGL-416.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sop] SOP Requirements Thread-Index: Acz2JIkOfqcR4SKhSEi+JU5PZkuBygADroCw References: <618BE8B40039924EB9AED233D4A09C51030E1263@XMB-BGL-416.cisco.com> From: "Ashish Dalela (adalela)" To: "Jamal Hadi Salim" X-OriginalArrivalTime: 28 Feb 2012 17:05:35.0312 (UTC) FILETIME=[2FD87500:01CCF63B] Cc: Vishwas Manral , sop@ietf.org, Michael Hammer Subject: Re: [sop] SOP Requirements X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 17:05:39 -0000 Hi Jamal, The intent of ForCES is decomposition of a network element, and the goal of SOP is how to integrate network planes into a larger useful system.=20 When we decompose, the intent is that the decomposed pieces can be built by anyone. That means a vendor is no longer a NE vendor but a component vendor. It plays out differently. E.g. if we look outside network, can we say that ForCES type of protocol could be used to separate the storage controller from the disk? Technically that is feasible, but the challenges in getting it done are high. On the other hand, when we are trying to integrate already disparate systems, we are creating a new level of value. It allows every vendor to control the value in their product, but opening up a management interface - similar to how devices have been managed through MIBs.=20 You don't lose anything by supporting a standard MIB, but there is a value in the network management system if it can manage many diverse devices (beyond the element manager). The goal of SOP is to meet that value point, which is addressing some real problems today. =20 The complexity of the systems is becoming high, to the point that configuring / managing / monitoring these systems is becoming harder and much more expensive. The complexity is specially high for cloud. We need an approach that reduces the cost of provisioning and monitoring these islands and build a level of intelligence that sees these islands as part of a single system.=20 SOP is basically service independent protocol. In that respect, we can compare it to SNMP, SIP, HTTP, SMTP, etc. It has the verbs and constructs we need for virtual services. But we don't want to bundle this with service-dependent things - counterparts of MIBs, Codecs, HTML or MIME in the earlier cases. If we look at this historically, HTML was done in W3C and Codecs in various places including ITU. Independent evolution of these things just makes it easier and more manageable. The goal is to separate service-independent and service-dependent pieces and do them separately. Many service-dependent pieces already exist - e.g. OVF for virtual machines done by DMTF or the effort that SNIA is putting to define virtual storage. My view is that cloud standards will not and cannot happen in one place. We need the right level of decoupling to allow different SDOs to do their part, and be able to integrate that. SOP is just a service-independent vehicle to carry service-dependent information. Thanks, Ashish -----Original Message----- From: sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] On Behalf Of Jamal Hadi Salim Sent: Tuesday, February 28, 2012 7:53 PM To: Ashish Dalela (adalela) Cc: Vishwas Manral; sop@ietf.org; Michael Hammer Subject: Re: [sop] SOP Requirements Hi Ashish, On Tue, Feb 28, 2012 at 8:26 AM, Ashish Dalela (adalela) wrote: > > As the number of services increase or the complexity in a given service > grows, this becomes very hard. Assume there is a service with N tunable > parameters. You need at least N APIs that modify these parameters > individually. Then permutations and combination of these parameters create > hundreds of more APIs. That's just API bloat. And if you have to > interoperate multiple instances of these APIs through bridges, it's just > inviting more complexity. Another limitation is that when APIs have semantic > incompatibilities, it becomes even harder to interoperate (syntax > incompatibility is easier). > > > From an operational standpoint, every new API introduction requires software > upgrades to the controllers. That eventually hinders the rate of service > creation. > This an _extremely important detail_ that is often missed by folks pushing OF for example as a service creation protocol (or even as a control-datapath protocol). BTW: Have you looked at ForCES? I didnt see it mentioned in the drafts. To summarize: The initial goals were to separate a datapath vs a controller. There are very few verbs and the entity being controlled/configured can be formally modeled using an XML language to define logical functional blocks. The blocks (which could represent services) could be instantiated and hierachy of the different components/attributes is inherently built. Although the definitions are in XML, the protocol is binary for efficiency reasons. ForCES has discovery, capability discovery, advertisements, transactions, etc. The underlying transport could be customized for specific problem domains (I suspect service creation would have slightly different needs than a router's control/line card transport desires). cheers, jamal _______________________________________________ sop mailing list sop@ietf.org https://www.ietf.org/mailman/listinfo/sop From hadi@mojatatu.com Tue Feb 28 09:48:50 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6097B21F86DB for ; Tue, 28 Feb 2012 09:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.373 X-Spam-Level: X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 0tzR2R5yk2YG for ; Tue, 28 Feb 2012 09:48:49 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9845A21F86AB for ; Tue, 28 Feb 2012 09:48:49 -0800 (PST) Received: by obbeh20 with SMTP id eh20so3514792obb.31 for ; Tue, 28 Feb 2012 09:48:49 -0800 (PST) Received-SPF: pass (google.com: domain of hadi@mojatatu.com designates 10.182.31.47 as permitted sender) client-ip=10.182.31.47; Authentication-Results: mr.google.com; spf=pass (google.com: domain of hadi@mojatatu.com designates 10.182.31.47 as permitted sender) smtp.mail=hadi@mojatatu.com Received: from mr.google.com ([10.182.31.47]) by 10.182.31.47 with SMTP id x15mr7009872obh.76.1330451329321 (num_hops = 1); Tue, 28 Feb 2012 09:48:49 -0800 (PST) Received: by 10.182.31.47 with SMTP id x15mr6214597obh.76.1330451329220; Tue, 28 Feb 2012 09:48:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.40.202 with HTTP; Tue, 28 Feb 2012 09:48:29 -0800 (PST) In-Reply-To: <618BE8B40039924EB9AED233D4A09C51031BC083@XMB-BGL-416.cisco.com> References: <618BE8B40039924EB9AED233D4A09C51030E1263@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BC083@XMB-BGL-416.cisco.com> From: Jamal Hadi Salim Date: Tue, 28 Feb 2012 12:48:29 -0500 Message-ID: To: "Ashish Dalela (adalela)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlFRr4zaLKsUCGNTCvhxwtK8reV9kPf7pLzL6WSenW8zYNnorqR7x2s3+30YOV+FJhXggER Cc: Vishwas Manral , sop@ietf.org, Michael Hammer Subject: Re: [sop] SOP Requirements X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 17:48:50 -0000 Hi Ashish, You are probably more familiar with ForCES than i read in between the lines in your response, but i just wanted to clarify to be sure. On Tue, Feb 28, 2012 at 12:05 PM, Ashish Dalela (adalela) wrote: > > Hi Jamal, > > The intent of ForCES is decomposition of a network element, and the goal > of SOP is how to integrate network planes into a larger useful system. If you look at ForCES from originally-intended-use, you are right. That is not what i meant since the architecture is more generic. [Example we use it to configure/manage many non-network element specific attributes across disparate NEs.] > When we decompose, the intent is that the decomposed pieces can be built > by anyone. That means a vendor is no longer a NE vendor but a component > vendor. It plays out differently. E.g. if we look outside network, can > we say that ForCES type of protocol could be used to separate the > storage controller from the disk? Technically that is feasible, but the > challenges in getting it done are high. It shouldnt be hard: You would need to describe the disk attributes. The protocol _never_ has to change. > On the other hand, when we are trying to integrate already disparate > systems, we are creating a new level of value. It allows every vendor to > control the value in their product, but opening up a management > interface - similar to how devices have been managed through MIBs. > ForCES allows you to do that. The XML definitions are equivalent to MIBS. The general semantics of operation for forces are unix like: command [path] [args] path and args are specific on the object instance being referenced and command is part of the few verbs defined (SET/GET/DEL etc) > You don't lose anything by supporting a standard MIB, but there is a > value in the network management system if it can manage many diverse > devices (beyond the element manager). The goal of SOP is to meet that > value point, which is addressing some real problems today. > > The complexity of the systems is becoming high, to the point that > configuring / managing / monitoring these systems is becoming harder and > much more expensive. The complexity is specially high for cloud. We need > an approach that reduces the cost of provisioning and monitoring these > islands and build a level of intelligence that sees these islands as > part of a single system. > > SOP is basically service independent protocol. In that respect, we can > compare it to SNMP, SIP, HTTP, SMTP, etc. It has the verbs and > constructs we need for virtual services. The only reason i brought up ForCES is because the verbs you need look similar. >But we don't want to bundle > this with service-dependent things - counterparts of MIBs, Codecs, HTML > or MIME in the earlier cases. If we look at this historically, HTML was > done in W3C and Codecs in various places including ITU. Independent > evolution of these things just makes it easier and more manageable. The > goal is to separate service-independent and service-dependent pieces and > do them separately. > > Many service-dependent pieces already exist - e.g. OVF for virtual > machines done by DMTF or the effort that SNIA is putting to define > virtual storage. My view is that cloud standards will not and cannot > happen in one place. We need the right level of decoupling to allow > different SDOs to do their part, and be able to integrate that. SOP is > just a service-independent vehicle to carry service-dependent > information. So this is the part i may be missing, please help me understand. You want a protocol that is capable of working with all above definitions of a specific service? i.e , if i defined a specific object blah using OVF definition or DMTF definition or a MIB etc, that your protocol will be able to interop between two service providers with two different languages used to define that object? cheers, jamal From adalela@cisco.com Tue Feb 28 18:08:08 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7944021E805B for ; Tue, 28 Feb 2012 18:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.436 X-Spam-Level: X-Spam-Status: No, score=-7.436 tagged_above=-999 required=5 tests=[AWL=3.163, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 vDBXuFCl5+AI for ; Tue, 28 Feb 2012 18:08:07 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8490821E8058 for ; Tue, 28 Feb 2012 18:08:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=6797; q=dns/txt; s=iport; t=1330481286; x=1331690886; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=+13afisM8dL78km9E1jMt8NXuvzT+S9FO/vRQcH5B/A=; b=bomllGh6pj1jdquSi6mTgdOzk5+3sQFMQpraO3tCfi9I8AxIelaF46qY ++i7ovubJThjgYM1G9JJyditjedd+I3UhUHnZKbNcXyD0cGZs5vCsSVht l2rtO1l9QevB1RMl6UKqFl0PQshlIS/fPtjd1c56OeWedSxWGgxz+bOy0 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAFiITU9Io8UY/2dsb2JhbABDtF2BdwEBAQMBEgEdCi0SBQcEAgEIEQEDAQEBCgYXAQYBRQMGCAEBBAsICBqHYQWaFAGedYoIgngDAgIDAQgBBAUBAgIJAwJAFYUYAzQOFYJeYwSITZ9qgU0 X-IronPort-AV: E=Sophos;i="4.73,499,1325462400"; d="scan'208";a="6604190" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 29 Feb 2012 02:08:04 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1T2842x019050; Wed, 29 Feb 2012 02:08:04 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 Feb 2012 07:38:04 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Feb 2012 07:38:02 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C51031BC0D4@XMB-BGL-416.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sop] SOP Requirements Thread-Index: Acz2QTwcIJHJEq3qT/CvsFV5hdOu6QAQWmCw References: <618BE8B40039924EB9AED233D4A09C51030E1263@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BC083@XMB-BGL-416.cisco.com> From: "Ashish Dalela (adalela)" To: "Jamal Hadi Salim" X-OriginalArrivalTime: 29 Feb 2012 02:08:04.0493 (UTC) FILETIME=[F8AB53D0:01CCF686] Cc: Vishwas Manral , sop@ietf.org, Michael Hammer Subject: Re: [sop] SOP Requirements X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 02:08:08 -0000 Hi Jamal, We will look at ForCES again since you have mentioned similarities. >> i.e , if i defined a specific object blah using OVF definition or DMTF >> definition or a MIB etc, that your protocol will be able to interop between >> two service providers with two different languages used to define that >> object? The short answer is "no", and a long answer as follows: =09 Each device advertizes its capabilities - which means advertizes a set of "service names". In this case, the "service name" can be iaas.compute.virtual.ovf, which can stand for OVF capable servers. Another server can advertize a "service name" iaas.compute.virtual.xyz, which can stand for XYZ standard for VMs. When a request for VM arrives, it carries the "service name" aside from the service parameters. The orchestrator maps the target device to the request based on this service name, and a whole bunch of other policies (location, bandwidth, security, ...). Ideally, we should not have competing standards for the same service name - e.g. virtual machines, but if there are, then this is how you would do it. The goal is not to translate between OVF and XYZ, because that is so buggy and brittle (precisely the problem with mapping APIs). We map OVF requests to OVF capable servers and XYZ to XYZ capable servers. SOP Proxy acts to do the routing and policy application of requests to targets.=20 The "service names" are hierarchical, which means that the child domain inherits properties of the parent domain (like objects). That allows you to incrementally extend domains by adding new attributes or features. A device, may, for example, advertize iaas.compute.virtual.ovf.proprietary-extensions, and a user can request a VM based on OVF and/or proprietary-extensions. This allows, a provider to support a new type of service with "value additions", while remaining compatible with standard. No protocol changes or changes to infrastructure / software are needed to achieve these things.=20 The Proxy may be configured with defaults for this service, or configured to reject requests that don't conform to what the provider wants to support or with rules on how a proprietary / standard service interacts with other services. So, the Proxy becomes an important point at which to enforce variety of controls. The Proxy can be at customer and provider and service boundaries. So, there are many points where different rules can be applied. =09 Hope I answered you question. Thanks, Ashish -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@mojatatu.com]=20 Sent: Tuesday, February 28, 2012 11:18 PM To: Ashish Dalela (adalela) Cc: Vishwas Manral; sop@ietf.org; Michael Hammer Subject: Re: [sop] SOP Requirements Hi Ashish, You are probably more familiar with ForCES than i read in between the lines in your response, but i just wanted to clarify to be sure. On Tue, Feb 28, 2012 at 12:05 PM, Ashish Dalela (adalela) wrote: > > Hi Jamal, > > The intent of ForCES is decomposition of a network element, and the goal > of SOP is how to integrate network planes into a larger useful system. If you look at ForCES from originally-intended-use, you are right. That is not what i meant since the architecture is more generic. [Example we use it to configure/manage many non-network element specific attributes across disparate NEs.] > When we decompose, the intent is that the decomposed pieces can be built > by anyone. That means a vendor is no longer a NE vendor but a component > vendor. It plays out differently. E.g. if we look outside network, can > we say that ForCES type of protocol could be used to separate the > storage controller from the disk? Technically that is feasible, but the > challenges in getting it done are high. It shouldnt be hard: You would need to describe the disk attributes. The protocol _never_ has to change. > On the other hand, when we are trying to integrate already disparate > systems, we are creating a new level of value. It allows every vendor to > control the value in their product, but opening up a management > interface - similar to how devices have been managed through MIBs. > ForCES allows you to do that. The XML definitions are equivalent to MIBS. The general semantics of operation for forces are unix like: command [path] [args] path and args are specific on the object instance being referenced and command is part of the few verbs defined (SET/GET/DEL etc) > You don't lose anything by supporting a standard MIB, but there is a > value in the network management system if it can manage many diverse > devices (beyond the element manager). The goal of SOP is to meet that > value point, which is addressing some real problems today. > > The complexity of the systems is becoming high, to the point that > configuring / managing / monitoring these systems is becoming harder and > much more expensive. The complexity is specially high for cloud. We need > an approach that reduces the cost of provisioning and monitoring these > islands and build a level of intelligence that sees these islands as > part of a single system. > > SOP is basically service independent protocol. In that respect, we can > compare it to SNMP, SIP, HTTP, SMTP, etc. It has the verbs and > constructs we need for virtual services. The only reason i brought up ForCES is because the verbs you need look similar. >But we don't want to bundle > this with service-dependent things - counterparts of MIBs, Codecs, HTML > or MIME in the earlier cases. If we look at this historically, HTML was > done in W3C and Codecs in various places including ITU. Independent > evolution of these things just makes it easier and more manageable. The > goal is to separate service-independent and service-dependent pieces and > do them separately. > > Many service-dependent pieces already exist - e.g. OVF for virtual > machines done by DMTF or the effort that SNIA is putting to define > virtual storage. My view is that cloud standards will not and cannot > happen in one place. We need the right level of decoupling to allow > different SDOs to do their part, and be able to integrate that. SOP is > just a service-independent vehicle to carry service-dependent > information. So this is the part i may be missing, please help me understand. You want a protocol that is capable of working with all above definitions of a specific service? i.e , if i defined a specific object blah using OVF definition or DMTF definition or a MIB etc, that your protocol will be able to interop between two service providers with two different languages used to define that object? cheers, jamal From hadi@mojatatu.com Wed Feb 29 06:24:50 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6B421F8510 for ; Wed, 29 Feb 2012 06:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.428 X-Spam-Level: X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 N5DOvJv2plE1 for ; Wed, 29 Feb 2012 06:24:49 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9191F21F84C5 for ; Wed, 29 Feb 2012 06:24:49 -0800 (PST) Received: by obbeh20 with SMTP id eh20so4904669obb.31 for ; Wed, 29 Feb 2012 06:24:49 -0800 (PST) Received-SPF: pass (google.com: domain of hadi@mojatatu.com designates 10.60.12.131 as permitted sender) client-ip=10.60.12.131; Authentication-Results: mr.google.com; spf=pass (google.com: domain of hadi@mojatatu.com designates 10.60.12.131 as permitted sender) smtp.mail=hadi@mojatatu.com Received: from mr.google.com ([10.60.12.131]) by 10.60.12.131 with SMTP id y3mr221546oeb.26.1330525489176 (num_hops = 1); Wed, 29 Feb 2012 06:24:49 -0800 (PST) Received: by 10.60.12.131 with SMTP id y3mr188815oeb.26.1330525489103; Wed, 29 Feb 2012 06:24:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.40.202 with HTTP; Wed, 29 Feb 2012 06:24:29 -0800 (PST) In-Reply-To: <618BE8B40039924EB9AED233D4A09C51031BC0D4@XMB-BGL-416.cisco.com> References: <618BE8B40039924EB9AED233D4A09C51030E1263@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BC083@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BC0D4@XMB-BGL-416.cisco.com> From: Jamal Hadi Salim Date: Wed, 29 Feb 2012 09:24:29 -0500 Message-ID: To: "Ashish Dalela (adalela)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlAh9n7NpK21YcMyZhsbAHrjAvuRisTiBN/l7OXa5JggXc4BVNI2gcIa9337grnXlEB9/hS Cc: Vishwas Manral , sop@ietf.org, Michael Hammer Subject: Re: [sop] SOP Requirements X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 14:24:50 -0000 Hi Ashish, On Tue, Feb 28, 2012 at 9:08 PM, Ashish Dalela (adalela) wrote: > Hi Jamal, > > We will look at ForCES again since you have mentioned similarities. If you want to take a shortcut and get quick answers, feel free to email me or post on the ForCES list. > Each device advertizes its capabilities - which means advertizes a set > of "service names". In this case, the "service name" can be > iaas.compute.virtual.ovf, which can stand for OVF capable servers. > Another server can advertize a "service name" iaas.compute.virtual.xyz, > which can stand for XYZ standard for VMs. When a request for VM arrives, > it carries the "service name" aside from the service parameters. The > orchestrator maps the target device to the request based on this service > name, and a whole bunch of other policies (location, bandwidth, > security, ...). > > Ideally, we should not have competing standards for the same service > name - e.g. virtual machines, but if there are, then this is how you > would do it. Yes, makes sense. [One thing thats not clear is how discovery of this services happens. In the ForCES approach, these services would be akin to LFBs. The node that is providing these LFBs (analogous to an FE if you are trying to do an NE) would connect to the controller (aka CE) and tell it what it can support and what capacities of each service (aka LFB) it can handle etc.] > The goal is not to translate between OVF and XYZ, because that is so > buggy and brittle (precisely the problem with mapping APIs). We map OVF > requests to OVF capable servers and XYZ to XYZ capable servers. SOP > Proxy acts to do the routing and policy application of requests to > targets. When you use the term "proxy" i see "Translation" or at least the orchestrator being intelligent enough to take iaas.compute.virtual.ovf.instance1.foo and understand it to be the same thing as iaas.compute.virtual.xyz.bar I think thats not what you want to achieve, correct? You want the request to be explicit for iaas.compute.virtual.ovf.instance1.foo for an OVF knowledgeable app and iaas.compute.virtual.xyz.bar for XYZ standard app? > The "service names" are hierarchical, which means that the child domain > inherits properties of the parent domain (like objects). That allows you > to incrementally extend domains by adding new attributes or features. A > device, may, for example, advertize > iaas.compute.virtual.ovf.proprietary-extensions, and a user can request > a VM based on OVF and/or proprietary-extensions. ok > This allows, a provider to support a new type of service with "value > additions", while remaining compatible with standard. No protocol > changes or changes to infrastructure / software are needed to achieve > these things. Yes on the "no protocol changes or infrastructure/software". This is where OF fails miserably. While we are trying to standardize, what you are talking about is reality. Unfortunately, it reduces the standardized interface to be the lowest common denominator. > The Proxy may be configured with defaults for this service, or > configured to reject requests that don't conform to what the provider > wants to support or with rules on how a proprietary / standard service > interacts with other services. So, the Proxy becomes an important point > at which to enforce variety of controls. The Proxy can be at customer > and provider and service boundaries. So, there are many points where > different rules can be applied. Sure. > Hope I answered you question. it does with a small caveat above. cheers, jamal From adalela@cisco.com Wed Feb 29 07:05:11 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45EC121F85D0 for ; Wed, 29 Feb 2012 07:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.478 X-Spam-Level: X-Spam-Status: No, score=-7.478 tagged_above=-999 required=5 tests=[AWL=3.121, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 q0si9BAR83Md for ; Wed, 29 Feb 2012 07:05:09 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id A123921F85CF for ; Wed, 29 Feb 2012 07:05:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=5964; q=dns/txt; s=iport; t=1330527908; x=1331737508; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=iOT77S5MeI5LKFSmxwRpYErcqOPWUjwVCq+ElIOdpKw=; b=lH+9Lq6uXlzvDmqDENG4kD6xOpq8QqIUIG7/Z0yadq2RMvTfXEE0DZlV 9no767yz0ZUUR5mEvjV24WigEuSdwr7LECAnXpLqLWooQt1M5enS0ZH5P f29/RN6NOubrn2Z8Gd8mi9KVekALTdAuZP0/wQu2I/6zRfV+WF0gYHava o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAJ49Tk9Io8UY/2dsb2JhbABEtGiBdwEBAQMBAQEBDwEdCi0HCwUHBAIBCBEEAQEBCgYXAQYBJh8JCAEBBAsICBqHYQULmkQBnxyKAoJ9AgkBBQIDBAMFDAJAFYUYAzMBDgoEAgUDEoJJYwSITZ9rgVQ X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="6670166" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 29 Feb 2012 15:05:07 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1TF57UI011382; Wed, 29 Feb 2012 15:05:07 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 Feb 2012 20:35:07 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Feb 2012 20:35:04 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C51031BC382@XMB-BGL-416.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sop] SOP Requirements Thread-Index: Acz27e2Pdlu84sQUQ4WS5mNi87EpiQAAjb3w References: <618BE8B40039924EB9AED233D4A09C51030E1263@XMB-BGL-416.cisco.com><618BE8B40039924EB9AED233D4A09C51031BC083@XMB-BGL-416.cisco.com><618BE8B40039924EB9AED233D4A09C51031BC0D4@XMB-BGL-416.cisco.com> From: "Ashish Dalela (adalela)" To: "Jamal Hadi Salim" X-OriginalArrivalTime: 29 Feb 2012 15:05:07.0048 (UTC) FILETIME=[85E0A680:01CCF6F3] Cc: Vishwas Manral , sop@ietf.org, Michael Hammer Subject: Re: [sop] SOP Requirements X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 15:05:11 -0000 Hi Jamal, I think there may be some confusion here. There are two types of names we deal with - "types" and "instances". A "car" is a type and car with a specific number plate is an "instance". These are two separate things. Likewise, iaas.compute.virtual.ovf is "type", and abc.provider.com is an instance of a server that is OVF capable. We won't merge these two names. A packet is generally routed in IP world based on "instance" addresses. In SOP, a packet is routed based on "types". That means that a user requests a "type" and the provider routes the request to the "instance" based on policy constraints.=20 The proxy is *not* a translator. In SIP, the term Proxy is used, because the Proxy executes a task on behalf of the requestor. The Proxy "proxies" on behalf of the requestor. There is no translation involved. Likewise, terms like HTTP proxy, mail proxy etc are used. These are not translators. >> Unfortunately, it reduces the standardized interface to be the lowest common denominator. I think people have gotten really confused with OF way of thinking about a standard. We need to take a step back and see how we have built standards in the past. =09 Take example of a MIB and SNMP. SNMP is standard for all MIBs. That doesn't preclude thousands of MIBs to be created. Likewise SOP is like SNMP. Service descriptions are like MIBs. Standard SOP doesn't preclude thousands of service types. When you create a new MIB, you just load the MIB in the network manager and start managing. You don't have to upgrade the manager. That means a network manager can manage innumerable types of services, without a software upgrade. It is made possible by separation between SNMP and the MIB.=20 We want to create the same separation between SOP and service-dependent descriptions like OVF .. Makes sense? Thanks, Ashish -----Original Message----- From: sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] On Behalf Of Jamal Hadi Salim Sent: Wednesday, February 29, 2012 7:54 PM To: Ashish Dalela (adalela) Cc: Vishwas Manral; sop@ietf.org; Michael Hammer Subject: Re: [sop] SOP Requirements Hi Ashish, On Tue, Feb 28, 2012 at 9:08 PM, Ashish Dalela (adalela) wrote: > Hi Jamal, > > We will look at ForCES again since you have mentioned similarities. If you want to take a shortcut and get quick answers, feel free to email me or post on the ForCES list. > Each device advertizes its capabilities - which means advertizes a set > of "service names". In this case, the "service name" can be > iaas.compute.virtual.ovf, which can stand for OVF capable servers. > Another server can advertize a "service name" iaas.compute.virtual.xyz, > which can stand for XYZ standard for VMs. When a request for VM arrives, > it carries the "service name" aside from the service parameters. The > orchestrator maps the target device to the request based on this service > name, and a whole bunch of other policies (location, bandwidth, > security, ...). > > Ideally, we should not have competing standards for the same service > name - e.g. virtual machines, but if there are, then this is how you > would do it. Yes, makes sense. [One thing thats not clear is how discovery of this services happens. In the ForCES approach, these services would be akin to LFBs. The node that is providing these LFBs (analogous to an FE if you are trying to do an NE) would connect to the controller (aka CE) and tell it what it can support and what capacities of each service (aka LFB) it can handle etc.] > The goal is not to translate between OVF and XYZ, because that is so > buggy and brittle (precisely the problem with mapping APIs). We map OVF > requests to OVF capable servers and XYZ to XYZ capable servers. SOP > Proxy acts to do the routing and policy application of requests to > targets. When you use the term "proxy" i see "Translation" or at least the orchestrator being intelligent enough to take iaas.compute.virtual.ovf.instance1.foo and understand it to be the same thing as iaas.compute.virtual.xyz.bar I think thats not what you want to achieve, correct? You want the request to be explicit for iaas.compute.virtual.ovf.instance1.foo for an OVF knowledgeable app and iaas.compute.virtual.xyz.bar for XYZ standard app? > The "service names" are hierarchical, which means that the child domain > inherits properties of the parent domain (like objects). That allows you > to incrementally extend domains by adding new attributes or features. A > device, may, for example, advertize > iaas.compute.virtual.ovf.proprietary-extensions, and a user can request > a VM based on OVF and/or proprietary-extensions. ok > This allows, a provider to support a new type of service with "value > additions", while remaining compatible with standard. No protocol > changes or changes to infrastructure / software are needed to achieve > these things. Yes on the "no protocol changes or infrastructure/software". This is where OF fails miserably. While we are trying to standardize, what you are talking about is reality. Unfortunately, it reduces the standardized interface to be the lowest common denominator. > The Proxy may be configured with defaults for this service, or > configured to reject requests that don't conform to what the provider > wants to support or with rules on how a proprietary / standard service > interacts with other services. So, the Proxy becomes an important point > at which to enforce variety of controls. The Proxy can be at customer > and provider and service boundaries. So, there are many points where > different rules can be applied. Sure. > Hope I answered you question. it does with a small caveat above. cheers, jamal _______________________________________________ sop mailing list sop@ietf.org https://www.ietf.org/mailman/listinfo/sop From hadi@mojatatu.com Wed Feb 29 08:18:21 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4DF21F8790 for ; Wed, 29 Feb 2012 08:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 ugIKCEayvCvs for ; Wed, 29 Feb 2012 08:18:20 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA7521F8744 for ; Wed, 29 Feb 2012 08:18:20 -0800 (PST) Received: by obbeh20 with SMTP id eh20so5041185obb.31 for ; Wed, 29 Feb 2012 08:18:20 -0800 (PST) Received-SPF: pass (google.com: domain of hadi@mojatatu.com designates 10.182.127.20 as permitted sender) client-ip=10.182.127.20; Authentication-Results: mr.google.com; spf=pass (google.com: domain of hadi@mojatatu.com designates 10.182.127.20 as permitted sender) smtp.mail=hadi@mojatatu.com Received: from mr.google.com ([10.182.127.20]) by 10.182.127.20 with SMTP id nc20mr330543obb.66.1330532300215 (num_hops = 1); Wed, 29 Feb 2012 08:18:20 -0800 (PST) Received: by 10.182.127.20 with SMTP id nc20mr285041obb.66.1330532300127; Wed, 29 Feb 2012 08:18:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.40.202 with HTTP; Wed, 29 Feb 2012 08:17:59 -0800 (PST) In-Reply-To: <618BE8B40039924EB9AED233D4A09C51031BC382@XMB-BGL-416.cisco.com> References: <618BE8B40039924EB9AED233D4A09C51030E1263@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BC083@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BC0D4@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BC382@XMB-BGL-416.cisco.com> From: Jamal Hadi Salim Date: Wed, 29 Feb 2012 11:17:59 -0500 Message-ID: To: "Ashish Dalela (adalela)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlXuea+mQEzVYckYfk1QYLNNVbPCkdi1NpkNuMCiEcq1FMgoO7w51QtLXf1jtZGsPW98QRq Cc: Vishwas Manral , sop@ietf.org, Michael Hammer Subject: Re: [sop] SOP Requirements X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 16:18:21 -0000 Hi Ashish, On Wed, Feb 29, 2012 at 10:05 AM, Ashish Dalela (adalela) wrote: > Hi Jamal, > > I think there may be some confusion here. > > There are two types of names we deal with - "types" and "instances". A > "car" is a type and car with a specific number plate is an "instance". > These are two separate things. Sorry - I was using ForCES speak. A node like abc.provider.com can have a car - the only time you can use it is if you instantiate it (to use your analogy, give it a number plate). So the _instance_ in that view is not abc.provider.com rather explicit abc.provider.com/cars/plateXXXX. >Likewise, iaas.compute.virtual.ovf is > "type", and abc.provider.com is an instance of a server that is OVF > capable. We won't merge these two names. A packet is generally routed in > IP world based on "instance" addresses. In SOP, a packet is routed based > on "types". > > That means that a user requests a "type" and the provider routes the > request to the "instance" based on policy constraints. Ok - got it; but still unclear. So you essentially dont need to have the user to be aware of the instance? So if i wanted >1 instances how do i distinguish between them? I am assuming at some point after creation one would need refer to a specific instance (and instance IDs of some form play a role). > The proxy is *not* a translator. In SIP, the term Proxy is used, because > the Proxy executes a task on behalf of the requestor. The Proxy > "proxies" on behalf of the requestor. There is no translation involved. > Likewise, terms like HTTP proxy, mail proxy etc are used. These are not > translators. That definition may need to well described. There are a lot of "transparent" email/HTTP proxies that translate at least at the protocol packet level. > I think people have gotten really confused with OF way of thinking about > a standard. We need to take a step back and see how we have built > standards in the past. I am not preaching OF at all. While it serves a purpose and has brought excitement to the SDN aspect, sometimes i look at OF and think of the Emperors New clothes. > Take example of a MIB and SNMP. SNMP is standard for all MIBs. That > doesn't preclude thousands of MIBs to be created. Likewise SOP is like > SNMP. Service descriptions are like MIBs. Standard SOP doesn't preclude > thousands of service types. When you create a new MIB, you just load the > MIB in the network manager and start managing. You don't have to upgrade > the manager. That means a network manager can manage innumerable types > of services, without a software upgrade. It is made possible by > separation between SNMP and the MIB. > > We want to create the same separation between SOP and service-dependent > descriptions like OVF .. > > Makes sense? Indeed (and in total agreement). cheers, jamal From adalela@cisco.com Wed Feb 29 08:44:50 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA9021F85A2 for ; Wed, 29 Feb 2012 08:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.518 X-Spam-Level: X-Spam-Status: No, score=-7.518 tagged_above=-999 required=5 tests=[AWL=3.081, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 yOs3gxpfkdks for ; Wed, 29 Feb 2012 08:44:49 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5076921F8584 for ; Wed, 29 Feb 2012 08:44:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=5248; q=dns/txt; s=iport; t=1330533888; x=1331743488; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=apCh4dhIE+dzBr7hW85AQRBYS9+FYRAG9uKuZKFKC5Y=; b=OoGjMKv+RLiaIEJhddk63b/jZ1rBEHd8AjI3sWLcm9hXQJpKW/R9fjJ5 UPxdTG44RJNxnLsiljgVeZ/NW2pFAWd4f1juUysqvwehwPNP9gzKRQOJS 8Qvo7VNT4G3r/qWN2xGJV6kiR3+kMa4oOFq/WFBRD6G70Guz3wuKPAxBR 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAAJVTk9Io8UY/2dsb2JhbABEtGSBegEBAQMBEgEdCisUBQcEAgEIEQQBAQEKBhcBBgFFCQgBAQQLCAgah2IFmkEBnxqJfQUFgwMBBQIBBBYCQBWFGAM0Dg4HA4JbYwSITZ9rgUwBBw X-IronPort-AV: E=Sophos;i="4.73,503,1325462400"; d="scan'208";a="6677040" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 29 Feb 2012 16:44:46 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1TGikvl011969; Wed, 29 Feb 2012 16:44:46 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 Feb 2012 22:14:46 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Feb 2012 22:14:45 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C51031BC3B4@XMB-BGL-416.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sop] SOP Requirements Thread-Index: Acz2/cSyk2ozb4b+TaCGFgb9gxfTiQAAhX3w References: <618BE8B40039924EB9AED233D4A09C51030E1263@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BC083@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BC0D4@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BC382@XMB-BGL-416.cisco.com> From: "Ashish Dalela (adalela)" To: "Jamal Hadi Salim" X-OriginalArrivalTime: 29 Feb 2012 16:44:46.0439 (UTC) FILETIME=[71DF4F70:01CCF701] Cc: Vishwas Manral , sop@ietf.org, Michael Hammer Subject: Re: [sop] SOP Requirements X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 16:44:50 -0000 Hi Jamal, >> Sorry - I was using ForCES speak. >> A node like abc.provider.com can have a car - the only time >> you can use it is if you instantiate it (to use your analogy, >> give it a number plate). So the _instance_ in that view is not >> abc.provider.com rather explicit abc.provider.com/cars/plateXXXX I understand the ForCES background - the idea is aligned with ATCA and the notion that any node can be given any "personality". That may not be true in general where certain types of devices are "capable" of doing certain things. E.g. you can't trivially make a switch a firewall or a load-balancer. You certainly can't make a network device a storage device or a server trivially. It is true for x86 servers maybe, but as you get a wide variety of hardware capabilities or move up the software stack into a middleware or a specific type of application, the generalized view disappears. Until we get to a point where a common type of hardware can enact any type of functionality that view is limited. >> So you essentially dont need to have the user to be aware >> of the instance? So if i wanted >1 instances how do i distinguish >> between them? I am assuming at some point after creation one would >> need refer to a specific instance (and instance IDs of some form play a role). The reality with virtualized services is that the instance doesn't *exist* when you ask for it. E.g. when I request a VM, the VM that I will be allocated doesn't exist. It will be created on-demand. So, there is no way I can request the specific "instance". I have to only request a "type". The type has to be mapped to a capability source, and then converted into an instance. Once you have an instance, sure, you refer to it both by type and instance. >> That definition may need to well described. >> There are a lot of "transparent" email/HTTP proxies that translate at >> least at the protocol packet level. Sure, that can be clarified. I thought the definition was clear in the drafts, but if not, that can be clarified. Thanks, Ashish -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@mojatatu.com]=20 Sent: Wednesday, February 29, 2012 9:48 PM To: Ashish Dalela (adalela) Cc: Vishwas Manral; sop@ietf.org; Michael Hammer Subject: Re: [sop] SOP Requirements Hi Ashish, On Wed, Feb 29, 2012 at 10:05 AM, Ashish Dalela (adalela) wrote: > Hi Jamal, > > I think there may be some confusion here. > > There are two types of names we deal with - "types" and "instances". A > "car" is a type and car with a specific number plate is an "instance". > These are two separate things. Sorry - I was using ForCES speak. A node like abc.provider.com can have a car - the only time you can use it is if you instantiate it (to use your analogy, give it a number plate). So the _instance_ in that view is not abc.provider.com rather explicit abc.provider.com/cars/plateXXXX. >Likewise, iaas.compute.virtual.ovf is > "type", and abc.provider.com is an instance of a server that is OVF > capable. We won't merge these two names. A packet is generally routed in > IP world based on "instance" addresses. In SOP, a packet is routed based > on "types". > > That means that a user requests a "type" and the provider routes the > request to the "instance" based on policy constraints. Ok - got it; but still unclear. So you essentially dont need to have the user to be aware of the instance? So if i wanted >1 instances how do i distinguish between them? I am assuming at some point after creation one would need refer to a specific instance (and instance IDs of some form play a role). > The proxy is *not* a translator. In SIP, the term Proxy is used, because > the Proxy executes a task on behalf of the requestor. The Proxy > "proxies" on behalf of the requestor. There is no translation involved. > Likewise, terms like HTTP proxy, mail proxy etc are used. These are not > translators. That definition may need to well described. There are a lot of "transparent" email/HTTP proxies that translate at least at the protocol packet level. > I think people have gotten really confused with OF way of thinking about > a standard. We need to take a step back and see how we have built > standards in the past. I am not preaching OF at all. While it serves a purpose and has brought excitement to the SDN aspect, sometimes i look at OF and think of the Emperors New clothes. > Take example of a MIB and SNMP. SNMP is standard for all MIBs. That > doesn't preclude thousands of MIBs to be created. Likewise SOP is like > SNMP. Service descriptions are like MIBs. Standard SOP doesn't preclude > thousands of service types. When you create a new MIB, you just load the > MIB in the network manager and start managing. You don't have to upgrade > the manager. That means a network manager can manage innumerable types > of services, without a software upgrade. It is made possible by > separation between SNMP and the MIB. > > We want to create the same separation between SOP and service-dependent > descriptions like OVF .. > > Makes sense? Indeed (and in total agreement). cheers, jamal From diego@tid.es Wed Feb 29 08:45:30 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87FE721F8597 for ; Wed, 29 Feb 2012 08:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[AWL=-2.009, BAYES_50=0.001] 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 GLJZvpdgQtRx for ; Wed, 29 Feb 2012 08:45:29 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC9B21F8596 for ; Wed, 29 Feb 2012 08:45:23 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0500GZ7YJMXJ@tid.hi.inet> for sop@ietf.org; Wed, 29 Feb 2012 17:45:22 +0100 (MET) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id B8.FB.02893.1265E4F4; Wed, 29 Feb 2012 17:45:21 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0M0500GYOYJJXJ@tid.hi.inet> for sop@ietf.org; Wed, 29 Feb 2012 17:45:19 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad2.hi.inet ([192.168.0.2]) with mapi; Wed, 29 Feb 2012 17:45:19 +0100 Date: Wed, 29 Feb 2012 17:45:19 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> To: "Ashish Dalela (adalela)" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: [Sdnp] New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services Thread-index: Acz3AYVskQpZo5kwQFqCDnVu+1ahhQ== acceptlanguage: en-US X-AuditID: 0a5f4068-b7f2d6d000000b4d-c9-4f4e5621c33f X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGKsWRmVeSWpSXmKPExsXCFe/ApasY5udvcPuCjcXx7/NZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8Wz6M5aCq/wVc2ZtYmtgfM7TxcjJISFgInGp4zIrhC0mceHe erYuRi4OIYENjBL31zxlhnC+MUp8ONDLBOE0Mkpc2j6BEaSFRUBV4tT3DrB2NgF1iZaj31hA bGGBXIn+/htgcU4BX4nvyzaC2SIChhIvdt5gB7GZBRQlFi1vArN5BSwlvnxcxwJhC0r8mHyP BaJGT+Ljn9uMELa4RHPrTai4tsSTdxfAZjICnf391BomiPl5El0v7wLN5ACy9SSW/c6GKBGV uNO+nhHiSwGJJXvOM0PYohIvH/9jhfhrFaPEzUUn2SYwis9CcsYsJGfMQnLGLCRnLGBkWcUo VpxUlJmeUZKbmJmTbmCol5Gpl5mXWrKJERJJGTsYl+9UOcQowMGoxMO7wsnXX4g1say4MvcQ oyQHk5Ior2Won78QX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd63UkA53pTEyqrUonyYlAwHh5IE 7zuQNsGi1PTUirTMHGC6gEkzcXCCtPMAtW8DqeEtLkjMLc5Mh8ifYpSUEodICIAkMkrz4Hpf MYoDHSnMGw6S5QEmNriuV0ADmYAGBnB6gwwsSURISTUw7vYpP1pian1dp1x1ad9pzfwPr+vm 7g5pFFli07Epu7P1vFG2J7vFs+o6TaGL5z33s4lpFO8wuf/t5j72S5bNge6G3ueqWuXFak1K bmjl67I8e3Q49gqPcOXzY86npmiItp04XlK8UHB227lt6/1X3xOcMtX6QC7nwZ4i38IFW7fk PDotvT1diaU4I9FQi7moOBEAJ00rGCkDAAA= References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> Cc: "sop@ietf.org" Subject: Re: [sop] [Sdnp] New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 16:45:30 -0000 Hi, On 16 Feb 2012, at 16:02 , Ashish Dalela (adalela) wrote: > SOP has the following main goals =96 > > 1. Fix interoperability issues with cloud services today. Main examples = are inter-cloud, hybrid-cloud, and multi-vendor cloud. All cloud services a= re being enabled through proprietary APIs today, which don=92t interoperate= . To interoperate across vendors, providers and customers, we need an open = standard. Ability to go across administrative domains is a basic requiremen= t. > > 2. A clear separation between service-independent and service-dependent = pieces in cloud services. SOP is about service-independent pieces. Using SO= P, a variety of services could be accessed or advertized. Separation betwee= n service-independent and service-dependent pieces makes the scheme extensi= ble to any type of service =96 current or future. > > 3. Create a common scheme for service orchestration that can be used acr= oss compute, network, storage, security, applications, etc. A common set of= constructs that can be applied to any service type whether it is infrastru= cture or application. Though I've had no time to make a comparison in depth, I could not avoid no= ticing that SOP and the Intercloud effort recently started inside the IEEE = P2302 Working Group are very much related, if not overlapping. Alignment sh= ould be pursued, I think. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx From adalela@cisco.com Wed Feb 29 08:58:57 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE64921F8793 for ; Wed, 29 Feb 2012 08:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.558 X-Spam-Level: X-Spam-Status: No, score=-7.558 tagged_above=-999 required=5 tests=[AWL=3.041, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 PiJZffMAlNAj for ; Wed, 29 Feb 2012 08:58:57 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9432C21F874A for ; Wed, 29 Feb 2012 08:58:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=2506; q=dns/txt; s=iport; t=1330534736; x=1331744336; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=dJDOF1XajO+6/DTwJnn4lhtaSYj37ovjvwEd+8qNWMs=; b=jGH26WgScilbuPsdgD3Cz3ZyDe5okXFw7FkYzYvbqMJB7SDY3PbGfq0N HPNhRmNVgmqZroR6dY+6F68hL72zn2nTepHeazG4VVOn3prAaag0D9RNY nB2P6y2t0Cw3f7GDFuATXLyaohVACPITML6xCkokMupTul5e6XuZxGt6H c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAO9YTk9Io8UY/2dsb2JhbABDtHaBegEBAQQSAR0+CwwEAgEIEQQBAQEKBhcBBgFFCQgBAQQLCAgah2cLoGcBlzKKAgWCeAIBFgIFAQEMAkAVCQKFDQMKAQcGEQoBDQcEBhqCSWMEiBwxn2uBTQc X-IronPort-AV: E=Sophos;i="4.73,503,1325462400"; d="scan'208";a="6675129" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 29 Feb 2012 16:58:54 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1TGwsLq007300; Wed, 29 Feb 2012 16:58:54 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 Feb 2012 22:28:54 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Feb 2012 22:28:52 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C51031BC3BE@XMB-BGL-416.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sdnp] New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services Thread-Index: Acz3AYVskQpZo5kwQFqCDnVu+1ahhQAAbXUA References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> From: "Ashish Dalela (adalela)" To: "DIEGO LOPEZ GARCIA" X-OriginalArrivalTime: 29 Feb 2012 16:58:54.0463 (UTC) FILETIME=[6B5580F0:01CCF703] Cc: sop@ietf.org Subject: Re: [sop] [Sdnp] New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 16:58:57 -0000 Hi Diego, We are aware of the IEEE work on Intercloud, but I'm not sure if there = is a concrete technical proposal in place. I might not have seen it, in = which please do point it out to me. Thanks, Ashish -----Original Message----- From: DIEGO LOPEZ GARCIA [mailto:diego@tid.es]=20 Sent: Wednesday, February 29, 2012 10:15 PM To: Ashish Dalela (adalela) Cc: sop@ietf.org Subject: Re: [Sdnp] New Non-WG Mailing List: sop -- Service = Orchestration and Desciption for Cloud Services Hi, On 16 Feb 2012, at 16:02 , Ashish Dalela (adalela) wrote: > SOP has the following main goals - > > 1. Fix interoperability issues with cloud services today. Main = examples are inter-cloud, hybrid-cloud, and multi-vendor cloud. All = cloud services are being enabled through proprietary APIs today, which = don't interoperate. To interoperate across vendors, providers and = customers, we need an open standard. Ability to go across administrative = domains is a basic requirement. > > 2. A clear separation between service-independent and = service-dependent pieces in cloud services. SOP is about = service-independent pieces. Using SOP, a variety of services could be = accessed or advertized. Separation between service-independent and = service-dependent pieces makes the scheme extensible to any type of = service - current or future. > > 3. Create a common scheme for service orchestration that can be used = across compute, network, storage, security, applications, etc. A common = set of constructs that can be applied to any service type whether it is = infrastructure or application. Though I've had no time to make a comparison in depth, I could not avoid = noticing that SOP and the Intercloud effort recently started inside the = IEEE P2302 Working Group are very much related, if not overlapping. = Alignment should be pursued, I think. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- Este mensaje se dirige exclusivamente a su destinatario. Puede consultar = nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en = el enlace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and = receive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx From hadi@mojatatu.com Wed Feb 29 09:09:39 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEE021F8608 for ; Wed, 29 Feb 2012 09:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 8NvaYrLblrVp for ; Wed, 29 Feb 2012 09:09:38 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC1621F855D for ; Wed, 29 Feb 2012 09:09:38 -0800 (PST) Received: by ggmi1 with SMTP id i1so301284ggm.31 for ; Wed, 29 Feb 2012 09:09:38 -0800 (PST) Received-SPF: pass (google.com: domain of hadi@mojatatu.com designates 10.60.30.70 as permitted sender) client-ip=10.60.30.70; Authentication-Results: mr.google.com; spf=pass (google.com: domain of hadi@mojatatu.com designates 10.60.30.70 as permitted sender) smtp.mail=hadi@mojatatu.com Received: from mr.google.com ([10.60.30.70]) by 10.60.30.70 with SMTP id q6mr473298oeh.56.1330535378253 (num_hops = 1); Wed, 29 Feb 2012 09:09:38 -0800 (PST) Received: by 10.60.30.70 with SMTP id q6mr403072oeh.56.1330535378135; Wed, 29 Feb 2012 09:09:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.40.202 with HTTP; Wed, 29 Feb 2012 09:09:17 -0800 (PST) In-Reply-To: <618BE8B40039924EB9AED233D4A09C51031BC3B4@XMB-BGL-416.cisco.com> References: <618BE8B40039924EB9AED233D4A09C51030E1263@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BC083@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BC0D4@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BC382@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BC3B4@XMB-BGL-416.cisco.com> From: Jamal Hadi Salim Date: Wed, 29 Feb 2012 12:09:17 -0500 Message-ID: To: "Ashish Dalela (adalela)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl/M2dtAK94AgP1wQzMdLZ0GJTJP/IHzzyulYZ9ILHAG92EImuw/t6aUkmgaxLoDW0hocOK Cc: Vishwas Manral , sop@ietf.org, Michael Hammer Subject: Re: [sop] SOP Requirements X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 17:09:39 -0000 Hi Ashish, On Wed, Feb 29, 2012 at 11:44 AM, Ashish Dalela (adalela) wrote: > I understand the ForCES background - the idea is aligned with ATCA and > the notion that any node can be given any "personality". That may not be > true in general where certain types of devices are "capable" of doing > certain things. E.g. you can't trivially make a switch a firewall or a > load-balancer. You certainly can't make a network device a storage > device or a server trivially. It is true for x86 servers maybe, but as > you get a wide variety of hardware capabilities or move up the software > stack into a middleware or a specific type of application, the > generalized view disappears. Until we get to a point where a common type > of hardware can enact any type of functionality that view is limited. I dont need to know a node's "personality" - if it exists, it tells me. The creation or booting of the node is considered a setup process. [Once create/booted - the node becomes part of my resource pool. I may not use it at all if i choose not to.] In your case, you may consider the creation aspect part of the process. > The reality with virtualized services is that the instance doesn't > *exist* when you ask for it. E.g. when I request a VM, the VM that I > will be allocated doesn't exist. It will be created on-demand. So, there > is no way I can request the specific "instance". I have to only request > a "type". The type has to be mapped to a capability source, and then > converted into an instance. Once you have an instance, sure, you refer > to it both by type and instance. Then no conflict there. I presume theres an operation to say "create abc.vm" which returns me some ID. And going forward i can refer to that abc.vm.someID and be able to reference attribute abc.vm.someID.foo, no? > Sure, that can be clarified. I thought the definition was clear in the > drafts, but if not, that can be clarified. I will read the drafts closely and comment. Is the requirements one the best one to focus one (that is the one i have looked at). cheers, jamal From vishwas.ietf@gmail.com Wed Feb 29 09:15:09 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E18A21F8669 for ; Wed, 29 Feb 2012 09:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.795 X-Spam-Level: X-Spam-Status: No, score=-3.795 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 qtJbvaq-R+sE for ; Wed, 29 Feb 2012 09:15:07 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 01EA421F864C for ; Wed, 29 Feb 2012 09:15:06 -0800 (PST) Received: by obbeh20 with SMTP id eh20so5105221obb.31 for ; Wed, 29 Feb 2012 09:15:06 -0800 (PST) Received-SPF: pass (google.com: domain of vishwas.ietf@gmail.com designates 10.182.49.66 as permitted sender) client-ip=10.182.49.66; Authentication-Results: mr.google.com; spf=pass (google.com: domain of vishwas.ietf@gmail.com designates 10.182.49.66 as permitted sender) smtp.mail=vishwas.ietf@gmail.com; dkim=pass header.i=vishwas.ietf@gmail.com Received: from mr.google.com ([10.182.49.66]) by 10.182.49.66 with SMTP id s2mr504092obn.16.1330535706697 (num_hops = 1); Wed, 29 Feb 2012 09:15:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PQVhWEf0GC9V8jPLiimVMbuy4LKOLtyYBNZwfthpLzY=; b=t4kmLEv1onaBYOrU2iWrWW1PvlZ5C1VlSePT6CZ30T9Z6XX/MmaJEbeiz2MklAurny 6Iw0a6ryASluibAGsevS0BRCqHlHt3NlH9vvyzI5RHGQQ2cD9XhT3QPNmDCq0E5qzvVH fIwmlVS5jlbOxX3333lC+XtXT5YCA4TtbE2ms= MIME-Version: 1.0 Received: by 10.182.49.66 with SMTP id s2mr425680obn.16.1330535706612; Wed, 29 Feb 2012 09:15:06 -0800 (PST) Received: by 10.182.165.1 with HTTP; Wed, 29 Feb 2012 09:15:06 -0800 (PST) In-Reply-To: <618BE8B40039924EB9AED233D4A09C51030E1263@XMB-BGL-416.cisco.com> References: <618BE8B40039924EB9AED233D4A09C51030E1263@XMB-BGL-416.cisco.com> Date: Wed, 29 Feb 2012 09:15:06 -0800 Message-ID: From: Vishwas Manral To: "Ashish Dalela (adalela)" Content-Type: multipart/alternative; boundary=f46d044630da2752a504ba1d7cb7 Cc: sop@ietf.org, Michael Hammer Subject: Re: [sop] SOP Requirements X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 17:15:09 -0000 --f46d044630da2752a504ba1d7cb7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ashish, > > As the number of services increase or the complexity in a given service > grows, this becomes very hard. Assume there is a service with N tunable > parameters. You need at least N APIs that modify these parameters > individually. Then permutations and combination of these parameters creat= e > hundreds of more APIs. That=92s just API bloat. And if you have to > interoperate multiple instances of these APIs through bridges, it=92s jus= t > inviting more complexity. Another limitation is that when APIs have > semantic incompatibilities, it becomes even harder to interoperate (synta= x > incompatibility is easier). > Not true at all.For N parameters you can have one API. The API can be made forward compatible by using simple things like unions. Having worked in a software company, where we have to extend our software without breaking previous API's I am well aware of the fact. If you give an exact example I can try to help you see how we can make an extensible API for the same. Thanks, Vishwas > > > From an operational standpoint, every new API introduction requires > software upgrades to the controllers. That eventually hinders the rate of > service creation. > > > > >> I know as services proliferate there could be a proliferation of > distict API's but the same is true of the protocol layer too. > > > That won=92t happen if we separate service-independent and service-depend= ent > pieces. An example of that is SNMP. SNMP is device/service independent. M= IB > defines the specific service/device. If you have a standard protocol to > manage a device, then you just have to add a new MIB to start managing it= . > You don=92t need to upgrade all the intermediate systems =96 hardware or > software. > > > > BTW, I=92m not advocating SNMP here because SNMP has many shortcomings in > terms of network discovery, capability discovery, advertisements, > transactions, etc. But, we need to keep in mind that API proliferation is > inevitable as services proliferate. Protocol proliferation is not > inevitable. Similar separation has been done in the past in SIP/SDP, > HTTP/HTML, SMTP/MIME. That separation allows anyone to send any content i= n > email to anyone. Or download any web-page, or have any type of codec (voi= ce > or video) use the same protocol. > > > > If you compare the success and widespread use of above mentioned protocol= s > the value of separation between service-independent and service-dependent > seems pretty convincing. > > > > >> Correct but the draft seems to differ. > > > > Service and instance of service are (and can be) interchangeably used. Is > bandwidth a service or an instance of a service? I think this is more > semantics. > > > > >> The requirement seems contradictory to what we agree. Similar for > points below. > > > > The requirement is really that services are portable across providers. I > think it is fair to say (as you also agree) that a user must know where > they are going for a service. After all, they will have to pay for the > service and they ought to know in advance who are they going to receive a > monthly check from. > > > > Thanks, Ashish > > > > > > *From:* sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] *On Behalf Of = *Vishwas > Manral > *Sent:* Tuesday, February 28, 2012 1:26 AM > *To:* Michael Hammer > *Cc:* sop@ietf.org > *Subject:* Re: [sop] SOP Requirements > > > > Hi Michael, > > Sounds like we agree on most of the things, though I see the draft > contradicting what we agree on. > > 1. Do we really see incompatibilities in the API's soar for say IaaS? The > AWS API's seem to be the default standard adopted by most providers. From > the little I know OpenStack based API's may be the alternative way and > companies have built bridging layers to inter-operate between the same. > > > > > > Seem? May be? Bridging layers? I think you are making the case for us. > :) > > I'm sure Ashish will have more to say about APIs, but I would prefer ther= e > be a de jure than a default, which in the long run is likely to change at > the whim of a single company, and perhaps not in a direction that everyon= e > would like. > > What I am saying is we have 2 sets of API's and there are layers used to > bridge the same. I know as services proliferate there could be a > proliferation of distict API's but the same is true of the protocol layer > too. > > > > > 2. Instead of the term customer/ user can we instead use the term > "consumer". Something like "cloud subscriber" etc could be used. All I am > saying is can we use standard terms here. > > > > We can settle on specific terms to use, just so long as we keep the > distinction between the entity (enterprise?) that provisions the software > in the cloud, and the user of that software, which could be an employee o= r > a user in the general public. Using a SIP Proxy as a Service, the operat= or > of the Proxy provisions it with a CREATE, but the user is the one sending > INVITEs through it. Make sense? > > The NIST document uses terms and we should try to use similar terms as fa= r > as possible. > > > > > 3. Is orchestration about creating services (from the cloud providers > perspective), or an instance of a service (for a particular user)? I thin= k > it is the latter, but doesn't sound so from the definition. > > > > Orchestration is about the on-demand provisioning of the > compute/storage/network/XaaS in the cloud by the subscriber/customer. On= ce > provisioned, the service can provide services to the intended user. We a= re > trying to be general here. Need to keep provisioning and operations > distinct. "Service" is occurring in levels. > > Correct but the draft seems to differ. > > > > > 4. How is Service Domain Name different from a URI? Aren't they the same? > > > > There is a distinction here between a class of services and running > instantiations of those services. Either may be hierarchically named. > > Hmm. > > > > > 5. Is Scenario -1 talking about all providers should provide the same > services? I guess not. I think the idea should be the same set of service= s > should be accessible from a cloud provider the same way. It however does > not mean that all providers need to provide the same services, as it seem= s > from the requirement. > > > > Agree. All providers may not provide the same set of services. > > But, if two providers offer the same service, it should not require a new > customer protocol stack to do so. > > And users should not know that they may be going to one provider or the > other when using the same service. > > The requirement seems contradictory to what we agree. Similar for points > below. > > Thanks, > Vishwas > > > > > 6. It seems for most purposes you are talking about users, but as such a > user in an enterprise should be unaware of where the service is coming > from. It is the role of the customer to actually provide clear demarcatio= n > so a user is unaware of the same. Interoperability with virtual provider = is > how companies achieve the same. > > > > Agree, and we would like that to be true for multi-provider cases as well= . > > I would go further to say that even a user not in the enterprise should b= e > unaware where the service is coming from. > > > > 7. I don't think you should mention providers should inter-operate with > each other. That is a business decision. I think what you mean here is th= at > providers should have a clear interoperable means should they wish to > inter-operate. > > > > Yes. We want them to be able to inter-operate. Whether they want to is = a > business decision. > > > > 8. Is it really a requirement for the Orchestration to allow > inter-operation for all models? I would have thought we are focusing on t= he > IaaS alone. > > > > We don't see a reason to limit it to just IaaS. We are looking several > years down the road here. > > > > 9. S-5 and S-3 sound like similar services to me. How are they different = - > vendor versus provider? > > > > We were considering cases where multiple companies are involved in > providing all the capabilities needed. One involved coordination within = an > administrative domain, while the other involves independent administrativ= e > domains. We didn't want to limit this to single company operations. Lar= ge > global providers may involve many companies. > > > > 10. I think one of the key requirements for SOP, is the ability to work > across only a sub-set of the base services and allow for extensible > services on top. There could be so many variants of the SaaS or even PaaS= I > am not sure how you would make every service inter-operate. > > > > There needs to be several layers of standards involved. This is an onion > not a single layer orange-peel. > > Here we are trying to provide structure that allows easy extension, > substitution, and innovation at the more service-specific granular levels= . > > > > 11. I think when a VM is moved the biggest issue is the ability to move > the storage along with it. All other state is minor and minimal. > > > > I would say the networking is the biggest issue, but that is my bias. :0 > > > > 12. Section 6 seems to be relevent within a cloud too and not just betwee= n > clouds. > > > > Agree. Internal to a cloud and from the customer to the cloud are the > simple cases. > > We emphasize the inter-cloud cases to test the architecture for the worst > cases. > > > > 13. Doesn't CDN provide the ability to separate address and ability > already? > > > > Probably needs more discussion. I see content as a specific scenario. > There you don't care which copy of data is accessed so long as you reach > it. In other types of services, a lot more control over who accesses wha= t > is needed. > > > > 14. For Service discovery. management we wrote something quite a while > back > https://datatracker.ietf.org/doc/draft-yokota-opsawg-virtnw-service-manag= ement/ > . > > Will take a look. Thanks. Mike > > > > Thanks, > Vishwas > > _______________________________________________ > sop mailing list > sop@ietf.org > https://www.ietf.org/mailman/listinfo/sop > > > > > --f46d044630da2752a504ba1d7cb7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ashish,

=

=A0

As the numbe= r of services increase or the complexity in a given service grows, this bec= omes very hard. Assume there is a service with N tunable parameters. You ne= ed at least N APIs that modify these parameters individually. Then permutat= ions and combination of these parameters create hundreds of more APIs. That= =92s just API bloat. And if you have to interoperate multiple instances of = these APIs through bridges, it=92s just inviting more complexity. Another l= imitation is that when APIs have semantic incompatibilities, it becomes eve= n harder to interoperate (syntax incompatibility is easier).

Not true at all.For N parameters you can have= one API. The API can be made forward compatible by using simple things lik= e unions. Having worked in a software company, where we have to extend our = software without breaking previous API's I am well aware of the fact.
If you give an exact example I can try to help you see how we can make = an extensible API for the same.

Thanks,
Vishwas

=A0

From an operational standpoint, every new API introduct= ion requires software upgrades to the controllers. That eventually hinders = the rate of service creation.

=A0

>= > I know as services proliferate there could be a proliferation of disti= ct API's but the same is true of the protocol layer too.
=A0

That won=92t happen if we separate service-indep= endent and service-dependent pieces. An example of that is SNMP. SNMP is de= vice/service independent. MIB defines the specific service/device. If you h= ave a standard protocol to manage a device, then you just have to add a new= MIB to start managing it. You don=92t need to upgrade all the intermediate= systems =96 hardware or software.

=A0

BTW, I=92m not advocating SNMP here = because SNMP has many shortcomings in terms of network discovery, capabilit= y discovery, advertisements, transactions, etc. But, we need to keep in min= d that API proliferation is inevitable as services proliferate. Protocol pr= oliferation is not inevitable. Similar separation has been done in the past= in SIP/SDP, HTTP/HTML, SMTP/MIME. That separation allows anyone to send an= y content in email to anyone. Or download any web-page, or have any type of= codec (voice or video) use the same protocol.

=A0

If you compare the success and wides= pread use of above mentioned protocols the value of separation between serv= ice-independent and service-dependent seems pretty convincing.

=A0

>> Co= rrect but the draft seems to differ.

=A0

Service and instance of servic= e are (and can be) interchangeably used. Is bandwidth a service or an insta= nce of a service? I think this is more semantics.

=A0

>> Th= e requirement seems contradictory to what we agree. Similar for points belo= w.

=A0

The requirement is really that= services are portable across providers. I think it is fair to say (as you = also agree) that a user must know where they are going for a service. After= all, they will have to pay for the service and they ought to know in advan= ce who are they going to receive a monthly check from.

=A0

Thanks, Ashish

=A0

=A0

From: sop-bounces@iet= f.org [mailto:sop-bounces@ietf.org] On Behalf Of Vishwas Manral
Sent: Tuesday, February 28, 2012 1:26 AM
To: Michael Hamme= r
Cc: sop@ietf.= org
Subject: Re: [sop] SOP Requirements

=A0

Hi Michael,

Sounds like we agree on most = of the things, though I see the draft contradicting what we agree on.

1. Do we really see incompatibilities in the API's soar = for say IaaS? The AWS API's seem to be the default standard adopted by = most providers. From the little I know OpenStack based API's may be the= alternative way and companies have built bridging layers to inter-operate = between the same.

=A0

=A0<= /p>

Seem? =A0May be? =A0Bridging lay= ers? =A0I think you are making the case for us. :)

I'm sure Ashish will have more to say about APIs, but I = would prefer there be a de jure than a default, which in the long run is li= kely to change at the whim of a single company, and perhaps not in a direct= ion that everyone would like.

What I am saying= is we have 2 sets of API's and there are layers used to bridge the sam= e. I know as services proliferate there could be a proliferation of distict= API's but the same is true of the protocol layer too.
=A0

=

=A0

2. Instead of the term customer/ user can we instead= use the term "consumer". Something like "cloud subscriber&q= uot; etc could be used. All I am saying is can we use standard terms here.<= /p>

=A0

We can settle on specific terms to use, just so long as we k= eep the distinction between the entity (enterprise?) that provisions the so= ftware in the cloud, and the user of that software, which could be an emplo= yee or a user in the general public. =A0Using a SIP Proxy as a Service, the= operator of the Proxy provisions it with a CREATE, but the user is the one= sending INVITEs through it. =A0Make sense?

The NIST documen= t uses terms and we should try to use similar terms as far as possible.
= =A0

=A0

3. Is orchestrati= on about creating services (from the cloud providers perspective), or an in= stance of a service (for a particular user)? I think it is the latter, but = doesn't sound so from the definition.

=A0

Orchestration is about the on-demand provisioning of the com= pute/storage/network/XaaS in the cloud by the subscriber/customer. =A0Once = provisioned, the service can provide services to the intended user. =A0We a= re trying to be general here. =A0Need to keep provisioning and operations d= istinct. =A0"Service" is occurring in levels.

Correct but the = draft seems to differ.
=A0

=A0

4. How is Service= Domain Name different from a URI? Aren't they the same?

=A0

There is a distinction here between a class of services and = running instantiations of those services. =A0Either may be hierarchically n= amed.

Hmm.
=A0

<= /div>

=A0

5. Is Scenario -1 talking about all pro= viders should provide the same services? I guess not. I think the idea shou= ld be the same set of services should be accessible from a cloud provider t= he same way. It however does not mean that all providers need to provide th= e same services, as it seems from the requirement.

=A0

Agree. =A0All providers may not provide the same set of serv= ices. =A0

But, if two providers offer = the same service, it should not require a new customer protocol stack to do= so.

And users should not know that they may b= e going to one provider or the other when using the same service.

=

The requirement seems = contradictory to what we agree. Similar for points below.

Thanks,
Vishwas
=A0

=A0

6. It seems for most purposes you are talking about = users, but as such a user in an enterprise should be unaware of where the s= ervice is coming from. It is the role of the customer to actually provide c= lear demarcation so a user is unaware of the same. Interoperability with vi= rtual provider is how companies achieve the same.

=A0

Agree, and we would like that to be true for multi-provider = cases as well.

I would go further to s= ay that even a user not in the enterprise should be unaware where the servi= ce is coming from.

=A0

7. I don't think yo= u should mention providers should inter-operate with each other. That is a = business decision. I think what you mean here is that providers should have= a clear interoperable means should they wish to inter-operate.

=A0

Yes. =A0We want them to be able to inter-operate. =A0Whether= they want to is a business decision.

=A0

8. Is it really a requirement for the Orchestration to allow inter-op= eration for all models? I would have thought we are focusing on the IaaS al= one.

=A0

We don't see a reason to limit it to just IaaS. =A0We ar= e looking several years down the road here.

=A0

9. S-5 and S-3 sound like similar services to me. How are th= ey different - vendor versus provider?

=A0

We were considering cases where multiple companies are invol= ved in providing all the capabilities needed. =A0One involved coordination = within an administrative domain, while the other involves independent admin= istrative domains. =A0We didn't want to limit this to single company op= erations. =A0Large global providers may involve many companies.

=A0

10. I think one of the = key requirements for SOP, is the ability to work across only a sub-set of t= he base services and allow for extensible services on top. There could be s= o many variants of the SaaS or even PaaS I am not sure how you would make e= very service inter-operate.

=A0

There needs to be several layers of standards involved. =A0T= his is an onion not a single layer orange-peel.

Here we are trying to provide structure that allows easy extension, substit= ution, and innovation at the more service-specific granular levels.

=A0

11. I think when a VM is moved the biggest issue is = the ability to move the storage along with it. All other state is minor and= minimal.

=A0

I would say the networking is the biggest issue, but= that is my bias. =A0:0

=A0

12. Section 6 seems to be relevent within a cloud to= o and not just between clouds.

= =A0

Agree. =A0Internal to a clou= d and from the customer to the cloud are the simple cases. =A0

We emphasize the inter-cloud cases to tes= t the architecture for the worst cases.

=A0

13. Doesn't CDN provide the ability to separate = address and ability already?

= =A0

Probably needs more discussi= on. =A0I see content as a specific scenario. =A0There you don't care wh= ich copy of data is accessed so long as you reach it. =A0In other types of = services, a lot more control over who accesses what is needed.

=A0

14. For Service discovery. management we wrote something quite a while back= https://datatracker.ietf.org/doc/draft-= yokota-opsawg-virtnw-service-management/.

Will take a look. =A0Thanks.= =A0Mike

=A0

Thanks,
Vishwas
_______________________________________________
sop mailing listsop@ietf.org
https:/= /www.ietf.org/mailman/listinfo/sop

=A0

<= p class=3D"MsoNormal">=A0

--f46d044630da2752a504ba1d7cb7-- From adalela@cisco.com Wed Feb 29 18:51:38 2012 Return-Path: X-Original-To: sop@ietfa.amsl.com Delivered-To: sop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0494421E807B for ; Wed, 29 Feb 2012 18:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.596 X-Spam-Level: X-Spam-Status: No, score=-7.596 tagged_above=-999 required=5 tests=[AWL=3.002, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 9IHj7kE9csEP for ; Wed, 29 Feb 2012 18:51:30 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2E47421E8014 for ; Wed, 29 Feb 2012 18:51:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=53600; q=dns/txt; s=iport; t=1330570281; x=1331779881; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=UQjycJAJDkUZrlw5RRX+cmgw8sf9LLHFnri0DUR5sYw=; b=QxMewwJ9cqCEk142lNZztEA5qAo7ajVZauce+Q0Ljs6KcpEKHd5RIS3F jADy0ayLiPyDRNvUL+yKRA2RN51oJYT1xhor40sWHTVJJXLM1ajz/Hcx6 /Mhr5DQcxZc2n9pX8y9iFoTQIxxS3eAaXF7DC8APXTGU1V5DCZi/75L3b I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEABvjTk9Io8UY/2dsb2JhbABDglGyPoF6AQEBAwEBAQEPAQcCEQM+CxACAQgRAQMBAQsGEAEGAQYBIAYfAwYIAQEECwgIFwOHYgULoFQBlyAEiRdnCQaCbgEDAgEBAQECAgECBgMBAQEEAQEBAgIBBQFFhG4BFQoNAREDMwEYBgEYAYJJYwSITYhCj0qHX4FNAQY X-IronPort-AV: E=Sophos;i="4.73,507,1325462400"; d="scan'208,217";a="6700688" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 01 Mar 2012 02:51:18 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q212pI4M026602; Thu, 1 Mar 2012 02:51:18 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 08:21:18 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCF756.2CF04429" Date: Thu, 1 Mar 2012 08:21:16 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C51031BC437@XMB-BGL-416.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sop] SOP Requirements Thread-Index: Acz3BbVV+ZhyluLGRDqEZd9k/91zOQARiz1Q References: <618BE8B40039924EB9AED233D4A09C51030E1263@XMB-BGL-416.cisco.com> From: "Ashish Dalela (adalela)" To: "Vishwas Manral" X-OriginalArrivalTime: 01 Mar 2012 02:51:18.0421 (UTC) FILETIME=[2D2F1450:01CCF756] Cc: sop@ietf.org, Michael Hammer Subject: Re: [sop] SOP Requirements X-BeenThere: sop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Service Orchestration and Desciption for Cloud Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 02:51:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCF756.2CF04429 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Vishwas, =20 What everyone calls API today uses a protocol - HTTP. APIs survive on the interoperability provided by that protocol, and I don't think anyone can get away from that. The real question is - what is the right protocol on top of which to build APIs? That's the question SOP is raising. Once you do that, then we can talk of one or many APIs. =20 Limitations of using HTTP as the underlying protocol for any API have been described in detail in the requirements draft. I would like to hear your comments on that. That section describes what APIs can't do. Some of the limitations are because API is always unicast, and there are many things for which you need a manycast and broadcast. Other limitations because APIs are synchronous and you need to be asynchronous in some cases. Yet other issues because APIs are single complete transaction, but some transactions will spread over multiple such APIs.=20 =20 The total amount of information in a message is unchanged whether you put it inside a protocol header or the content body. Putting some things in the protocol header saves you having to reinvent them in the content for every type of service. In other words, a protocol saves you from increasing information across various services. As an example in SIP, we put From and To in the protocol header. Could we not put it in the body? Sure we could. In that case we would be repeating that for voice and video and chat content.=20 =20 To your point, you can have a single API for doing anything. As the service evolves and complexity grows, the number of parameters to that API increases. And yes, you can make that backward compatible in terms of implementation. But, nobody does that - especially when the interface is end-user facing. If this was an acceptable design, then we would not have object inheritance and there won't be hundreds of APIs being opened up by cloud providers today. You might want to suggest one API to Amazon or other cloud providers.=20 =20 A practical operational issue with APIs is that users don't understand all the details. A user understands a server memory and CPU, but don't understand VLAN and LUN, and zillions of other complicated things. Exposing them through APIs is useless because they can't use it. Why would a user buy an expensive TV when they can't use most of the features, because the remote is too complicated? The need is to reduce complexity through automation, not expose it all to the user via APIs. In other words, you need a more sophisticated policy engine not a sophisticated API system.=20 =20 For any problem there is a cure and there is a prevention. Building API bridges is a cure to diverse APIs, it's not a prevention. Once you recognize a problem, you build a short-term cure and a long-term prevention (at least ideally). Then, a single API is neither a cure nor prevention; its side-effects are so severe that we might be living with the original problem as well.=20 =20 APIs have always existed and will continue to exist. The goal is to interoperate diverse APIs without a translation bridge. That happens all the time with network protocols, when one vendor's APIs works with another vendor's APIs without a translation bridge. I think not having a bridge is always better than having a bridge. Agree? =20 Thanks, Ashish =20 =20 From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]=20 Sent: Wednesday, February 29, 2012 10:45 PM To: Ashish Dalela (adalela) Cc: Michael Hammer; sop@ietf.org Subject: Re: [sop] SOP Requirements =20 Hi Ashish, =20 As the number of services increase or the complexity in a given service grows, this becomes very hard. Assume there is a service with N tunable parameters. You need at least N APIs that modify these parameters individually. Then permutations and combination of these parameters create hundreds of more APIs. That's just API bloat. And if you have to interoperate multiple instances of these APIs through bridges, it's just inviting more complexity. Another limitation is that when APIs have semantic incompatibilities, it becomes even harder to interoperate (syntax incompatibility is easier). Not true at all.For N parameters you can have one API. The API can be made forward compatible by using simple things like unions. Having worked in a software company, where we have to extend our software without breaking previous API's I am well aware of the fact. If you give an exact example I can try to help you see how we can make an extensible API for the same. Thanks, Vishwas=20 =20 From an operational standpoint, every new API introduction requires software upgrades to the controllers. That eventually hinders the rate of service creation. =20 >> I know as services proliferate there could be a proliferation of distict API's but the same is true of the protocol layer too. =20 That won't happen if we separate service-independent and service-dependent pieces. An example of that is SNMP. SNMP is device/service independent. MIB defines the specific service/device. If you have a standard protocol to manage a device, then you just have to add a new MIB to start managing it. You don't need to upgrade all the intermediate systems - hardware or software.=20 =20 BTW, I'm not advocating SNMP here because SNMP has many shortcomings in terms of network discovery, capability discovery, advertisements, transactions, etc. But, we need to keep in mind that API proliferation is inevitable as services proliferate. Protocol proliferation is not inevitable. Similar separation has been done in the past in SIP/SDP, HTTP/HTML, SMTP/MIME. That separation allows anyone to send any content in email to anyone. Or download any web-page, or have any type of codec (voice or video) use the same protocol. =20 If you compare the success and widespread use of above mentioned protocols the value of separation between service-independent and service-dependent seems pretty convincing. =20 >> Correct but the draft seems to differ. =20 Service and instance of service are (and can be) interchangeably used. Is bandwidth a service or an instance of a service? I think this is more semantics. =20 >> The requirement seems contradictory to what we agree. Similar for points below. =20 The requirement is really that services are portable across providers. I think it is fair to say (as you also agree) that a user must know where they are going for a service. After all, they will have to pay for the service and they ought to know in advance who are they going to receive a monthly check from.=20 =20 Thanks, Ashish =20 =20 From: sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] On Behalf Of Vishwas Manral Sent: Tuesday, February 28, 2012 1:26 AM To: Michael Hammer Cc: sop@ietf.org Subject: Re: [sop] SOP Requirements =20 Hi Michael, =09 Sounds like we agree on most of the things, though I see the draft contradicting what we agree on. 1. Do we really see incompatibilities in the API's soar for say IaaS? The AWS API's seem to be the default standard adopted by most providers. From the little I know OpenStack based API's may be the alternative way and companies have built bridging layers to inter-operate between the same. =20 =20 Seem? May be? Bridging layers? I think you are making the case for us. :) I'm sure Ashish will have more to say about APIs, but I would prefer there be a de jure than a default, which in the long run is likely to change at the whim of a single company, and perhaps not in a direction that everyone would like. What I am saying is we have 2 sets of API's and there are layers used to bridge the same. I know as services proliferate there could be a proliferation of distict API's but the same is true of the protocol layer too. =20 =20 2. Instead of the term customer/ user can we instead use the term "consumer". Something like "cloud subscriber" etc could be used. All I am saying is can we use standard terms here. =20 We can settle on specific terms to use, just so long as we keep the distinction between the entity (enterprise?) that provisions the software in the cloud, and the user of that software, which could be an employee or a user in the general public. Using a SIP Proxy as a Service, the operator of the Proxy provisions it with a CREATE, but the user is the one sending INVITEs through it. Make sense? The NIST document uses terms and we should try to use similar terms as far as possible. =20 =20 3. Is orchestration about creating services (from the cloud providers perspective), or an instance of a service (for a particular user)? I think it is the latter, but doesn't sound so from the definition. =20 Orchestration is about the on-demand provisioning of the compute/storage/network/XaaS in the cloud by the subscriber/customer. Once provisioned, the service can provide services to the intended user. We are trying to be general here. Need to keep provisioning and operations distinct. "Service" is occurring in levels. Correct but the draft seems to differ. =20 =20 4. How is Service Domain Name different from a URI? Aren't they the same? =20 There is a distinction here between a class of services and running instantiations of those services. Either may be hierarchically named. Hmm. =20 =20 5. Is Scenario -1 talking about all providers should provide the same services? I guess not. I think the idea should be the same set of services should be accessible from a cloud provider the same way. It however does not mean that all providers need to provide the same services, as it seems from the requirement. =20 Agree. All providers may not provide the same set of services. =20 But, if two providers offer the same service, it should not require a new customer protocol stack to do so. And users should not know that they may be going to one provider or the other when using the same service. The requirement seems contradictory to what we agree. Similar for points below. =09 Thanks, Vishwas =20 =20 6. It seems for most purposes you are talking about users, but as such a user in an enterprise should be unaware of where the service is coming from. It is the role of the customer to actually provide clear demarcation so a user is unaware of the same. Interoperability with virtual provider is how companies achieve the same. =20 Agree, and we would like that to be true for multi-provider cases as well. I would go further to say that even a user not in the enterprise should be unaware where the service is coming from. =20 7. I don't think you should mention providers should inter-operate with each other. That is a business decision. I think what you mean here is that providers should have a clear interoperable means should they wish to inter-operate. =20 Yes. We want them to be able to inter-operate. Whether they want to is a business decision. =20 8. Is it really a requirement for the Orchestration to allow inter-operation for all models? I would have thought we are focusing on the IaaS alone. =20 We don't see a reason to limit it to just IaaS. We are looking several years down the road here. =20 9. S-5 and S-3 sound like similar services to me. How are they different - vendor versus provider? =20 We were considering cases where multiple companies are involved in providing all the capabilities needed. One involved coordination within an administrative domain, while the other involves independent administrative domains. We didn't want to limit this to single company operations. Large global providers may involve many companies. =20 10. I think one of the key requirements for SOP, is the ability to work across only a sub-set of the base services and allow for extensible services on top. There could be so many variants of the SaaS or even PaaS I am not sure how you would make every service inter-operate. =20 There needs to be several layers of standards involved. This is an onion not a single layer orange-peel. Here we are trying to provide structure that allows easy extension, substitution, and innovation at the more service-specific granular levels. =20 11. I think when a VM is moved the biggest issue is the ability to move the storage along with it. All other state is minor and minimal. =20 I would say the networking is the biggest issue, but that is my bias. :0 =20 12. Section 6 seems to be relevent within a cloud too and not just between clouds. =20 Agree. Internal to a cloud and from the customer to the cloud are the simple cases. =20 We emphasize the inter-cloud cases to test the architecture for the worst cases. =20 13. Doesn't CDN provide the ability to separate address and ability already? =20 Probably needs more discussion. I see content as a specific scenario. There you don't care which copy of data is accessed so long as you reach it. In other types of services, a lot more control over who accesses what is needed. =20 14. For Service discovery. management we wrote something quite a while back https://datatracker.ietf.org/doc/draft-yokota-opsawg-virtnw-service-mana gement/. Will take a look. Thanks. Mike =20 Thanks, Vishwas =09 _______________________________________________ sop mailing list sop@ietf.org https://www.ietf.org/mailman/listinfo/sop =20 =20 =20 ------_=_NextPart_001_01CCF756.2CF04429 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Vishwas,

 

What everyone calls API today uses a protocol – HTTP. APIs = survive on the interoperability provided by that protocol, and I = don’t think anyone can get away from that. The real question is = – what is the right protocol on top of which to build APIs? = That’s the question SOP is raising. Once you do that, then we can = talk of one or many APIs.

 

Limitations of using HTTP as the underlying protocol for any API have = been described in detail in the requirements draft. I would like to hear = your comments on that. That section describes what APIs can’t do. = Some of the limitations are because API is always unicast, and there are = many things for which you need a manycast and broadcast. Other = limitations because APIs are synchronous and you need to be asynchronous = in some cases. Yet other issues because APIs are single complete = transaction, but some transactions will spread over multiple such APIs. =

 

The total amount of information in a message is unchanged whether you = put it inside a protocol header or the content body. Putting some things = in the protocol header saves you having to reinvent them in the content = for every type of service. In other words, a protocol saves you from = increasing information across various services. As an example in SIP, we = put From and To in the protocol header. Could we not put it in the body? = Sure we could. In that case we would be repeating that for voice and = video and chat content.

 

To your point, you can have a single API for doing anything. As the = service evolves and complexity grows, the number of parameters to that = API increases. And yes, you can make that backward compatible in terms = of implementation. But, nobody does that – especially when the = interface is end-user facing. If this was an acceptable design, then we = would not have object inheritance and there won’t be hundreds of = APIs being opened up by cloud providers today. You might want to suggest = one API to Amazon or other cloud providers.

 

A practical operational issue with APIs is that users don’t = understand all the details. A user understands a server memory and CPU, = but don’t understand VLAN and LUN, and zillions of other = complicated things. Exposing them through APIs is useless because they = can’t use it. Why would a user buy an expensive TV when they = can’t use most of the features, because the remote is too = complicated? The need is to reduce complexity through automation, not = expose it all to the user via APIs. In other words, you need a more = sophisticated policy engine not a sophisticated API system. =

 

For any problem there is a cure and there is a prevention. Building = API bridges is a cure to diverse APIs, it’s not a prevention. Once = you recognize a problem, you build a short-term cure and a long-term = prevention (at least ideally). Then, a single API is neither a cure nor = prevention; its side-effects are so severe that we might be living with = the original problem as well.

 

APIs have always existed and will continue to exist. The goal is to = interoperate diverse APIs without a translation bridge. That happens all = the time with network protocols, when one vendor’s APIs works with = another vendor’s APIs without a translation bridge. I think not = having a bridge is always better than having a bridge. = Agree?

 

Thanks, Ashish

 

 

From:= = Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: = Wednesday, February 29, 2012 10:45 PM
To: Ashish Dalela = (adalela)
Cc: Michael Hammer; sop@ietf.org
Subject: = Re: [sop] SOP Requirements

 

Hi Ashish,

 <= /o:p>

As the number of services increase or the complexity in a given = service grows, this becomes very hard. Assume there is a service with N = tunable parameters. You need at least N APIs that modify these = parameters individually. Then permutations and combination of these = parameters create hundreds of more APIs. That’s just API bloat. = And if you have to interoperate multiple instances of these APIs through = bridges, it’s just inviting more complexity. Another limitation is = that when APIs have semantic incompatibilities, it becomes even harder = to interoperate (syntax incompatibility is = easier).

Not true at all.For N parameters you can have one API. = The API can be made forward compatible by using simple things like = unions. Having worked in a software company, where we have to extend our = software without breaking previous API's I am well aware of the = fact.

If you give an exact example I can try to help you see how = we can make an extensible API for the same.

Thanks,
Vishwas =

 

From an operational standpoint, every new API introduction requires = software upgrades to the controllers. That eventually hinders the rate = of service creation.

 <= /o:p>

>> I = know as services proliferate there could be a proliferation of distict = API's but the same is true of the protocol layer = too.
 

That won’t happen if we separate service-independent and = service-dependent pieces. An example of that is SNMP. SNMP is = device/service independent. MIB defines the specific service/device. If = you have a standard protocol to manage a device, then you just have to = add a new MIB to start managing it. You don’t need to upgrade all = the intermediate systems – hardware or software. =

 

BTW, I’m not advocating SNMP here because SNMP has many = shortcomings in terms of network discovery, capability discovery, = advertisements, transactions, etc. But, we need to keep in mind that API = proliferation is inevitable as services proliferate. Protocol = proliferation is not inevitable. Similar separation has been done in the = past in SIP/SDP, HTTP/HTML, SMTP/MIME. That separation allows anyone to = send any content in email to anyone. Or download any web-page, or have = any type of codec (voice or video) use the same = protocol.

 

If you compare the success and widespread use of above mentioned = protocols the value of separation between service-independent and = service-dependent seems pretty convincing.

 

>> Correct but the draft seems to = differ.

 

Service and instance of service are (and can be) interchangeably = used. Is bandwidth a service or an instance of a service? I think this = is more semantics.

 

>> The requirement seems contradictory to what we agree. = Similar for points below.

 

The requirement is really that services are portable across = providers. I think it is fair to say (as you also agree) that a user = must know where they are going for a service. After all, they will have = to pay for the service and they ought to know in advance who are they = going to receive a monthly check from.

 

Thanks, Ashish

 

 

From:= = sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] On Behalf Of Vishwas = Manral
Sent: Tuesday, February 28, 2012 1:26 AM
To: = Michael Hammer
Cc: sop@ietf.org
Subject: Re: [sop] SOP = Requirements

 <= /o:p>

Hi = Michael,

Sounds like we agree on most of the things, though I see = the draft contradicting what we agree on.

1. Do we = really see incompatibilities in the API's soar for say IaaS? The AWS = API's seem to be the default standard adopted by most providers. From = the little I know OpenStack based API's may be the alternative way and = companies have built bridging layers to inter-operate between the = same.

 <= /o:p>

 <= /o:p>

Seem? =  May be?  Bridging layers?  I think you are making the = case for us. :)

I'm sure = Ashish will have more to say about APIs, but I would prefer there be a = de jure than a default, which in the long run is likely to change at the = whim of a single company, and perhaps not in a direction that everyone = would like.

What I am = saying is we have 2 sets of API's and there are layers used to bridge = the same. I know as services proliferate there could be a proliferation = of distict API's but the same is true of the protocol layer = too.
 

 <= /o:p>

2. Instead = of the term customer/ user can we instead use the term = "consumer". Something like "cloud subscriber" etc = could be used. All I am saying is can we use standard terms = here.

 <= /o:p>

We can = settle on specific terms to use, just so long as we keep the distinction = between the entity (enterprise?) that provisions the software in the = cloud, and the user of that software, which could be an employee or a = user in the general public.  Using a SIP Proxy as a Service, the = operator of the Proxy provisions it with a CREATE, but the user is the = one sending INVITEs through it.  Make = sense?

The NIST = document uses terms and we should try to use similar terms as far as = possible.
 

 <= /o:p>

3. Is = orchestration about creating services (from the cloud providers = perspective), or an instance of a service (for a particular user)? I = think it is the latter, but doesn't sound so from the = definition.

 <= /o:p>

Orchestratio= n is about the on-demand provisioning of the = compute/storage/network/XaaS in the cloud by the subscriber/customer. =  Once provisioned, the service can provide services to the intended = user.  We are trying to be general here.  Need to keep = provisioning and operations distinct.  "Service" is = occurring in = levels.

Correct but = the draft seems to differ.
 

 <= /o:p>

4. How is = Service Domain Name different from a URI? Aren't they the = same?

 <= /o:p>

There is a = distinction here between a class of services and running instantiations = of those services.  Either may be hierarchically = named.

Hmm.
&nbs= p;

 <= /o:p>

5. Is = Scenario -1 talking about all providers should provide the same = services? I guess not. I think the idea should be the same set of = services should be accessible from a cloud provider the same way. It = however does not mean that all providers need to provide the same = services, as it seems from the = requirement.

 <= /o:p>

Agree. =  All providers may not provide the same set of services. =  

But, if two = providers offer the same service, it should not require a new customer = protocol stack to do so.

And users = should not know that they may be going to one provider or the other when = using the same = service.

The = requirement seems contradictory to what we agree. Similar for points = below.

Thanks,
Vishwas
 

 <= /o:p>

6. It seems = for most purposes you are talking about users, but as such a user in an = enterprise should be unaware of where the service is coming from. It is = the role of the customer to actually provide clear demarcation so a user = is unaware of the same. Interoperability with virtual provider is how = companies achieve the same.

 <= /o:p>

Agree, and = we would like that to be true for multi-provider cases as = well.

I would go = further to say that even a user not in the enterprise should be unaware = where the service is coming from.

 <= /o:p>

7. I don't = think you should mention providers should inter-operate with each other. = That is a business decision. I think what you mean here is that = providers should have a clear interoperable means should they wish to = inter-operate.

 <= /o:p>

Yes. =  We want them to be able to inter-operate.  Whether they want = to is a business decision.

 <= /o:p>

8. Is it = really a requirement for the Orchestration to allow inter-operation for = all models? I would have thought we are focusing on the IaaS = alone.

 <= /o:p>

We don't = see a reason to limit it to just IaaS.  We are looking several = years down the road here.

 <= /o:p>

9. S-5 and = S-3 sound like similar services to me. How are they different - vendor = versus provider?

 <= /o:p>

We were = considering cases where multiple companies are involved in providing all = the capabilities needed.  One involved coordination within an = administrative domain, while the other involves independent = administrative domains.  We didn't want to limit this to single = company operations.  Large global providers may involve many = companies.

 <= /o:p>

10. I think = one of the key requirements for SOP, is the ability to work across only = a sub-set of the base services and allow for extensible services on top. = There could be so many variants of the SaaS or even PaaS I am not sure = how you would make every service = inter-operate.

 <= /o:p>

There needs = to be several layers of standards involved.  This is an onion not a = single layer orange-peel.

Here we are = trying to provide structure that allows easy extension, substitution, = and innovation at the more service-specific granular = levels.

 <= /o:p>

11. I think = when a VM is moved the biggest issue is the ability to move the storage = along with it. All other state is minor and = minimal.

 <= /o:p>

I would say = the networking is the biggest issue, but that is my bias. =  :0

 <= /o:p>

12. Section = 6 seems to be relevent within a cloud too and not just between = clouds.

 <= /o:p>

Agree. =  Internal to a cloud and from the customer to the cloud are the = simple cases.  

We = emphasize the inter-cloud cases to test the architecture for the worst = cases.

 <= /o:p>

13. Doesn't = CDN provide the ability to separate address and ability = already?

 <= /o:p>

Probably = needs more discussion.  I see content as a specific scenario. =  There you don't care which copy of data is accessed so long as you = reach it.  In other types of services, a lot more control over who = accesses what is needed.

 <= /o:p>

14. For Service = discovery. management we wrote something quite a while back https://datatracker.ietf.org/doc/draft-yokota-opsawg-vi= rtnw-service-management/.

Will take a = look.  Thanks.  Mike

 <= /o:p>

Thanks,
Vishwas=

_______________________________________________
sop mailing = list
sop@ietf.org
https://www.ietf.org/mailman/listinfo/sop

 <= /o:p>

 <= /o:p>

 

------_=_NextPart_001_01CCF756.2CF04429--