From diego@tid.es Thu Mar 1 02:46: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 342BE21F863E for ; Thu, 1 Mar 2012 02:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[AWL=1.383, 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 wU+wM+E-4N+K for ; Thu, 1 Mar 2012 02:46:22 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id E46F921F86D3 for ; Thu, 1 Mar 2012 02:46:21 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M07000ZTCL31D@tid.hi.inet> for sop@ietf.org; Thu, 01 Mar 2012 11:46:19 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id C2.BC.02643.B735F4F4; Thu, 01 Mar 2012 11:46:19 +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 <0M0700LGWCL79H@tid.hi.inet> for sop@ietf.org; Thu, 01 Mar 2012 11:46:19 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad2.hi.inet ([192.168.0.2]) with mapi; Thu, 01 Mar 2012 11:46:19 +0100 Date: Thu, 01 Mar 2012 11:46:18 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: <618BE8B40039924EB9AED233D4A09C51031BC3BE@XMB-BGL-416.cisco.com> To: "Ashish Dalela (adalela)" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: [sop] [Sdnp] New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services Thread-index: Acz3mIh+O5WgIDHzSD+6EWpP6yU9Gw== acceptlanguage: en-US X-AuditID: 0a5f4e69-b7f6b6d000000a53-f2-4f4f537b0127 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKKsWRmVeSWpSXmKPExsXCFe9nqFsd7O9v8LNbw+L49/ksDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKuPyxruAcV8XRSQtYGhj3c3QxcnJICJhIzD9wlQ3CFpO4cG89 kM3FISSwjVFi3YydrBDON0aJ6Sf2sUA4jYwSBzouATkcHCwCqhK/PzKDdLMJqEu0HP3GAmIL CxRLbN29lxXE5hTwlehZdBOsRkTAUOLFzhvsIDazgKLEouVNYDavgKXE9P9r2SBsQYkfk++x QNToSPR+/8YMYYtLNLfehIprSzx5dwFsPiPQ1d9PrWGCmF8iMWvLAjYIW0+i8dUHJogaUYk7 7esZIb4UkFiy5zwzhC0q8fLxP6gn5zJJrF63g3ECo/gsJHfMQnLHLCR3zEJyxwJGllWMYsVJ RZnpGSW5iZk56QZGehmZepl5qSWbGCFxlLmDcflOlUOMAhyMSjy8O2r8/IVYE8uKK3MPMUpy MCmJ8noE+fsL8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuGtsgXK8aYkVlalFuXDpGQ4OJQkeP1A 2gSLUtNTK9Iyc4DJAibNxMEJ0s4D1J4JUsNbXJCYW5yZDpE/xSgpJc5rDJIQAElklObB9b5i FAc6Upg3AyTLA0xrcF2vgAYyAQ1cfNkPZGBJIkJKqoFR4de9FimHu+8Oubx0r2WS5TfKDDE2 SJk9N8BostP0+4bR0RoJL4oevsl56BTYy3SyTePQiesee1Qe79lkyNr59X50tL9V7an6e4lN z/W4tO+4/33z7CzTlqx5QTqTc5d+9Dq0+/lvdcaH7B1/DVcwbpju/D90Roei/e6y+a0i1dcf /3++wkZIiaU4I9FQi7moOBEA7Ld1BCgDAAA= References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BC3BE@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: Thu, 01 Mar 2012 10:46:23 -0000 Hi Ashish, On 29 Feb 2012, at 17:58 , Ashish Dalela (adalela) wrote: > 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. There is only a draft on architechtural concepts, and that's precisely why = seeking for cooperation and alignment is especially relevant. There are people in my company following this and contributing to DMTF as w= ell, and we discussed this in our last meeting. While I see a clear line be= tween DMTF and the ideas around SOP, and that line defines a clear way for = compatibility, in the case of the IEEE Intercloud that line is (as far as I= see it) much more blurred. 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 Thu Mar 1 03:03: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 CBB6021F86FD for ; Thu, 1 Mar 2012 03:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.634 X-Spam-Level: X-Spam-Status: No, score=-7.634 tagged_above=-999 required=5 tests=[AWL=2.965, 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 G--S0RYFvPfY for ; Thu, 1 Mar 2012 03:03:44 -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 93FA621F86B1 for ; Thu, 1 Mar 2012 03:03:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=2175; q=dns/txt; s=iport; t=1330599824; x=1331809424; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Im+LNGAdT7yTfjByLA3iviP/Q8B6Yk6fj/nxMZBvB5k=; b=MKPcuyD4Oz7LEVex7rJ6rTjlIAM2RL+xPocZG76UpK4SzN6o+2uRS+3k wBizdQqL7ap0WtUh2d8mcIqpoN424R6o2p2XraI1slSaMpk55FnOtRxZE Si3nFH81N6daTlOmI0uGY/uMV9mwrkvW0iTBLbvUin1PB0UqjCnIHqqDQ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAA9XT09Io8UY/2dsb2JhbABDtQyBfQEBAQQBAQEPAR0+CwwEAgEIEQQBAQEKBhMEAQYBJh8JCAEBBAsICBqHZAuaIQGfAooGgn8KDAECAgQNAkAVCQKFDQMKAQcGEQoBDQcEBhqCTWMEiBwxn2iBVA X-IronPort-AV: E=Sophos;i="4.73,509,1325462400"; d="scan'208";a="6750595" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 01 Mar 2012 11:03:41 +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 q21B3ft9021324; Thu, 1 Mar 2012 11:03: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, 1 Mar 2012 16:33:41 +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: Thu, 1 Mar 2012 16:33:40 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C51031BC603@XMB-BGL-416.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sop] [Sdnp] New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services Thread-Index: Acz3mIh+O5WgIDHzSD+6EWpP6yU9GwAAfOyw References: <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com><618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com><618BE8B40039924EB9AED233D4A09C51031BC3BE@XMB-BGL-416.cisco.com> From: "Ashish Dalela (adalela)" To: "DIEGO LOPEZ GARCIA" X-OriginalArrivalTime: 01 Mar 2012 11:03:41.0301 (UTC) FILETIME=[F61CD250:01CCF79A] 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: Thu, 01 Mar 2012 11:03:44 -0000 Hi Diego, Yes, I understand the need to draw the line. That line allows us to = leverage the work that is already done, while allow future developments = to continue without a big-bang change, which IMO, is very hard. I will speak to others more on the IEEE effort and see what we can do = for alignment. Appreciate your suggestion. Thanks, Ashish -----Original Message----- From: sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] On Behalf Of = DIEGO LOPEZ GARCIA Sent: Thursday, March 01, 2012 4:16 PM To: Ashish Dalela (adalela) Cc: sop@ietf.org Subject: Re: [sop] [Sdnp] New Non-WG Mailing List: sop -- Service = Orchestration and Desciption for Cloud Services Hi Ashish, On 29 Feb 2012, at 17:58 , Ashish Dalela (adalela) wrote: > 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. There is only a draft on architechtural concepts, and that's precisely = why seeking for cooperation and alignment is especially relevant. There are people in my company following this and contributing to DMTF = as well, and we discussed this in our last meeting. While I see a clear = line between DMTF and the ideas around SOP, and that line defines a = clear way for compatibility, in the case of the IEEE Intercloud that = line is (as far as I see it) much more blurred. 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 _______________________________________________ sop mailing list sop@ietf.org https://www.ietf.org/mailman/listinfo/sop From adalela@cisco.com Thu Mar 1 10:08: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 A7F6621E8117 for ; Thu, 1 Mar 2012 10:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.671 X-Spam-Level: X-Spam-Status: No, score=-7.671 tagged_above=-999 required=5 tests=[AWL=2.928, 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 h2Q1OtFeHx86 for ; Thu, 1 Mar 2012 10:08:10 -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 C713321E80CF for ; Thu, 1 Mar 2012 10:08:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=3955; q=dns/txt; s=iport; t=1330625289; x=1331834889; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=S00ScMDoG5JGaboEQpv0VVcm15JMqZ4HPz9NuVn49vs=; b=AzY+Ky5vnNAJjZ+oask38J2R04qSJ2hVp+kU7Ghd9Le6SGze7To4VwLy RwvsWWHYydKNF6mDG3g34S6W4AngLh+oADjAwWabgGPJW04RHXsGmu2yT ndsZddmSnmJPiDSiCI5RN5tpL2167K83e8jCQsmUWnLKoytBJM7NWRBif k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAJu6T09Io8UY/2dsb2JhbABDtRaBfQEBAQMBAQEBDwEdCisJCwUHBAIBCBEBAwEBCwYXAQYBJh8DBggBAQQLCAgah18FC6A5AZcEBIoBCoJ3CgEBCAUNCQJAFQuFDQMzAQ4KBgUVgk1jBIhNn2iBTAE X-IronPort-AV: E=Sophos;i="4.73,512,1325462400"; d="scan'208";a="6835492" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 01 Mar 2012 18:08:07 +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 q21I87Li026985; Thu, 1 Mar 2012 18:08: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); Thu, 1 Mar 2012 23:38:06 +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: Thu, 1 Mar 2012 23:38:05 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C51031BC6F5@XMB-BGL-416.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sop] SOP Requirements Thread-Index: Acz3BPK5UjSopdPrSj2rGDzrWNz61gAz30oQ 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: "Ashish Dalela (adalela)" To: "Jamal Hadi Salim" X-OriginalArrivalTime: 01 Mar 2012 18:08:06.0974 (UTC) FILETIME=[40D625E0:01CCF7D6] 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: Thu, 01 Mar 2012 18:08:10 -0000 Hi Jamal, >> 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? Please note that the resources we create and the names we assign them have to be DNS accessible. That's because from a user standpoint cloud and non-cloud services must work just the same. Hence, you don't want to give a name like - abc.vm.someID. You want to give a name that will be resolved by a DNS server so that the user can reach that server in the same way, transparent to the fact that it is cloud created. To make cloud work incrementally, we need a separate name space for "types", and not mix it with existing names in DNS. So, we end up with two name spaces - one for types and another for instances. The properties of an instance are really properties of a "type" but referenced by an instance. The "type" can have a "name" attribute that references an instance, without loss of generality. That way, if we change the name, we are still consistent. >> Is the requirements one the best one to focus one (that is the one i have looked at). Requirements is certainly the place to start at. Many of the questions you have raise also touch upon architecture, and specifics are in the protocol draft. Look forward to your comments. Thanks, Ashish =09 -----Original Message----- From: sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] On Behalf Of Jamal Hadi Salim Sent: Wednesday, February 29, 2012 10:39 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 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 _______________________________________________ sop mailing list sop@ietf.org https://www.ietf.org/mailman/listinfo/sop From mphmmr@gmail.com Thu Mar 1 10:24: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 64DFA21E813B for ; Thu, 1 Mar 2012 10:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=0.129, 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 8ejreUnugLoR for ; Thu, 1 Mar 2012 10:24: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 E0C1D21E8156 for ; Thu, 1 Mar 2012 10:24:37 -0800 (PST) Received: by lagj5 with SMTP id j5so1288465lag.31 for ; Thu, 01 Mar 2012 10:24:36 -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 v8mr2889220lbk.49.1330626276944 (num_hops = 1); Thu, 01 Mar 2012 10:24: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=4lNUUm5QdrIU8mtbyyB55S78EkUGXDBdk5KBiMED+RE=; b=K3WBp8LwqyD8uGdETop1GYPL/rWqXT9L3DgymjO9kqyUzdW2Xcwsl8VM2KOQDs4sih 1XnKzq+MfCd3rIBvLyVFInjX5jkBBAQr2xbBYb5sGQKDoXHk/YN6ceaRufNhCvLtRUyY 2ivmfw9ohZdF0JEuvpDu0jT5XpKMH4UauA+WE= MIME-Version: 1.0 Received: by 10.112.40.72 with SMTP id v8mr2371930lbk.49.1330626276815; Thu, 01 Mar 2012 10:24:36 -0800 (PST) Received: by 10.112.104.70 with HTTP; Thu, 1 Mar 2012 10:24:36 -0800 (PST) In-Reply-To: <618BE8B40039924EB9AED233D4A09C51031BC6F5@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> <618BE8B40039924EB9AED233D4A09C51031BC6F5@XMB-BGL-416.cisco.com> Date: Thu, 1 Mar 2012 13:24:36 -0500 Message-ID: From: Michael Hammer To: "Ashish Dalela (adalela)" Content-Type: multipart/alternative; boundary=e0cb4efe2d588ef52604ba329216 Cc: Vishwas Manral , sop@ietf.org, Jamal Hadi Salim 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 18:24:39 -0000 --e0cb4efe2d588ef52604ba329216 Content-Type: text/plain; charset=ISO-8859-1 We also need to maintain independence between cloud customer and cloud service provider naming conventions. Those can be linked and de-referenced through name server registries operated by the appropriate entities. Mike On Thu, Mar 1, 2012 at 1:08 PM, Ashish Dalela (adalela) wrote: > Hi Jamal, > > >> 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? > > Please note that the resources we create and the names we assign them > have to be DNS accessible. That's because from a user standpoint cloud > and non-cloud services must work just the same. Hence, you don't want to > give a name like - abc.vm.someID. You want to give a name that will be > resolved by a DNS server so that the user can reach that server in the > same way, transparent to the fact that it is cloud created. > > To make cloud work incrementally, we need a separate name space for > "types", and not mix it with existing names in DNS. So, we end up with > two name spaces - one for types and another for instances. The > properties of an instance are really properties of a "type" but > referenced by an instance. The "type" can have a "name" attribute that > references an instance, without loss of generality. That way, if we > change the name, we are still consistent. > > >> Is the requirements one the best one to focus one (that is the one i > have looked at). > > Requirements is certainly the place to start at. Many of the questions > you have raise also touch upon architecture, and specifics are in the > protocol draft. Look forward to your comments. > > 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 10:39 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 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 > _______________________________________________ > sop mailing list > sop@ietf.org > https://www.ietf.org/mailman/listinfo/sop > --e0cb4efe2d588ef52604ba329216 Content-Type: text/html; charset=ISO-8859-1 We also need to maintain independence between cloud customer and cloud service provider naming conventions.
Those can be linked and de-referenced through name server registries operated by the appropriate entities.

Mike


On Thu, Mar 1, 2012 at 1:08 PM, Ashish Dalela (adalela) <adalela@cisco.com> wrote:
Hi Jamal,

>> 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?

Please note that the resources we create and the names we assign them
have to be DNS accessible. That's because from a user standpoint cloud
and non-cloud services must work just the same. Hence, you don't want to
give a name like - abc.vm.someID. You want to give a name that will be
resolved by a DNS server so that the user can reach that server in the
same way, transparent to the fact that it is cloud created.

To make cloud work incrementally, we need a separate name space for
"types", and not mix it with existing names in DNS. So, we end up with
two name spaces - one for types and another for instances. The
properties of an instance are really properties of a "type" but
referenced by an instance. The "type" can have a "name" attribute that
references an instance, without loss of generality. That way, if we
change the name, we are still consistent.

>> Is the requirements one the best one to focus one (that is the one i
have looked at).

Requirements is certainly the place to start at. Many of the questions
you have raise also touch upon architecture, and specifics are in the
protocol draft. Look forward to your comments.

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 10:39 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 11:44 AM, Ashish Dalela (adalela)
<adalela@cisco.com> 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
_______________________________________________
sop mailing list
sop@ietf.org
https://www.ietf.org/mailman/listinfo/sop

--e0cb4efe2d588ef52604ba329216-- From hadi@mojatatu.com Fri Mar 2 10:22: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 6459E21F85E7 for ; Fri, 2 Mar 2012 10:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.431, 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 or7Gsyq4wZcV for ; Fri, 2 Mar 2012 10:22:41 -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 9A04821F85B5 for ; Fri, 2 Mar 2012 10:22:41 -0800 (PST) Received: by obbeh20 with SMTP id eh20so2779134obb.31 for ; Fri, 02 Mar 2012 10:22:41 -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 x15mr4221877obh.76.1330712561328 (num_hops = 1); Fri, 02 Mar 2012 10:22:41 -0800 (PST) Received: by 10.182.31.47 with SMTP id x15mr3649484obh.76.1330712561211; Fri, 02 Mar 2012 10:22:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.40.202 with HTTP; Fri, 2 Mar 2012 10:22:21 -0800 (PST) In-Reply-To: <618BE8B40039924EB9AED233D4A09C51031BC6F5@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> <618BE8B40039924EB9AED233D4A09C51031BC6F5@XMB-BGL-416.cisco.com> From: Jamal Hadi Salim Date: Fri, 2 Mar 2012 13:22:21 -0500 Message-ID: To: "Ashish Dalela (adalela)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmhCVZe/jOdBpI8xlX8lnSz4f8t7q9a3syL4ba0VHoPS9zsDXyA8uBMGGi8pUOmVEkGpNcu 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: Fri, 02 Mar 2012 18:22:42 -0000 Hi Ashish, I will read the drafts and provide better comments. I guess the point i was missing was you put out requirements to look for a protocol and it turns out you already have a protocol which suits your needs. cheers, jamal On Thu, Mar 1, 2012 at 1:08 PM, Ashish Dalela (adalela) wrote: > > Please note that the resources we create and the names we assign them > have to be DNS accessible. That's because from a user standpoint cloud > and non-cloud services must work just the same. Hence, you don't want to > give a name like - abc.vm.someID. You want to give a name that will be > resolved by a DNS server so that the user can reach that server in the > same way, transparent to the fact that it is cloud created. Ok - didnt realize that angle. > To make cloud work incrementally, we need a separate name space for > "types", and not mix it with existing names in DNS. So, we end up with > two name spaces - one for types and another for instances. The > properties of an instance are really properties of a "type" but > referenced by an instance. The "type" can have a "name" attribute that > references an instance, without loss of generality. That way, if we > change the name, we are still consistent. > >>> Is the requirements one the best one to focus one (that is the one i > have looked at). > > Requirements is certainly the place to start at. Many of the questions > you have raise also touch upon architecture, and specifics are in the > protocol draft. Look forward to your comments. > > 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 10:39 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 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 > _______________________________________________ > sop mailing list > sop@ietf.org > https://www.ietf.org/mailman/listinfo/sop From vishwas.ietf@gmail.com Fri Mar 2 10:48:36 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 3209921E8057 for ; Fri, 2 Mar 2012 10:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.812 X-Spam-Level: X-Spam-Status: No, score=-3.812 tagged_above=-999 required=5 tests=[AWL=-0.214, 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 pDyZTTEIXGnb for ; Fri, 2 Mar 2012 10:48:33 -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 9FB4C21E8050 for ; Fri, 2 Mar 2012 10:48:33 -0800 (PST) Received: by obbeh20 with SMTP id eh20so2808911obb.31 for ; Fri, 02 Mar 2012 10:48:33 -0800 (PST) Received-SPF: pass (google.com: domain of vishwas.ietf@gmail.com designates 10.182.232.106 as permitted sender) client-ip=10.182.232.106; Authentication-Results: mr.google.com; spf=pass (google.com: domain of vishwas.ietf@gmail.com designates 10.182.232.106 as permitted sender) smtp.mail=vishwas.ietf@gmail.com; dkim=pass header.i=vishwas.ietf@gmail.com Received: from mr.google.com ([10.182.232.106]) by 10.182.232.106 with SMTP id tn10mr4587410obc.6.1330714113352 (num_hops = 1); Fri, 02 Mar 2012 10:48:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7wyhcKCBkC1eJj+xzOO17tj2OQOzCBKWrmYLP3xNYMk=; b=Jhxrrs4JhhhPSoM+8VqI1HmzHCTHkZWUru/uMcI4dfu1XaBQgdb4UqVFLehNBUXmKu zLdHfH24TqoscXT+HwVk9mbEkx0RsQ4IEL1ObFXVKmuB0W6AQXYoZs822sRD/Z+Yj88r g9c6zWML2/T0P/aGhVPyevWQFSBbcA+isG9ohj9D+3gpMD1ScaK2NHFhCcw/D+aiB+2A q45HPrIvQyUTZKcoOkooQZPvs00/sqh+W4rwabYZUBPZ0y9GgNk6mFZBGnBGliS6/qYt CXextO7LNnkTfXN3R7cNNY2GUoHVTq/pVndn+RmRGxSURDUzzpTu56m95BsIoKGPRyG6 Cyrg== MIME-Version: 1.0 Received: by 10.182.232.106 with SMTP id tn10mr3929185obc.6.1330714113241; Fri, 02 Mar 2012 10:48:33 -0800 (PST) Received: by 10.182.165.1 with HTTP; Fri, 2 Mar 2012 10:48:33 -0800 (PST) In-Reply-To: <618BE8B40039924EB9AED233D4A09C51031BC437@XMB-BGL-416.cisco.com> References: <618BE8B40039924EB9AED233D4A09C51030E1263@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BC437@XMB-BGL-416.cisco.com> Date: Fri, 2 Mar 2012 10:48:33 -0800 Message-ID: From: Vishwas Manral To: "Ashish Dalela (adalela)" Content-Type: multipart/alternative; boundary=f46d0444736704739a04ba470668 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: Fri, 02 Mar 2012 18:48:36 -0000 --f46d0444736704739a04ba470668 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ashish, My point was very simple. You had talked about cases where protocol is more flexible than an API, and I was trying to help you understand that anything that can be done in an East West manner (with protocols), can be done in North-South manner with API's. If you say we can do something with protocols with only X packets, we can do the same with just X API's too. That was my point and not the fact that we have only 1 API or more. Also API's on which base services sit and ones which end users use could be different. Am I missing the point altogether? Thanks, Vishwas On Wed, Feb 29, 2012 at 6:51 PM, Ashish Dalela (adalela) wrote: > Hi Vishwas,**** > > ** ** > > What everyone calls API today uses a protocol =96 HTTP. APIs survive on t= he > interoperability provided by that protocol, and I don=92t think anyone ca= n > get away from that. The real question is =96 what is the right protocol o= n > top of which to build APIs? That=92s the question SOP is raising. Once yo= u do > that, then we can talk of one or many APIs.**** > > ** ** > > Limitations of using HTTP as the underlying protocol for any API have bee= n > described in detail in the requirements draft. I would like to hear your > comments on that. That section describes what APIs can=92t do. Some of th= e > limitations are because API is always unicast, and there are many things > for which you need a manycast and broadcast. Other limitations because AP= Is > are synchronous and you need to be asynchronous in some cases. Yet other > issues because APIs are single complete transaction, but some transaction= s > 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 t= he > protocol header saves you having to reinvent them in the content for ever= y > type of service. In other words, a protocol saves you from increasing > information across various services. As an example in SIP, we put From an= d > 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 AP= I > increases. And yes, you can make that backward compatible in terms of > implementation. But, nobody does that =96 especially when the interface i= s > end-user facing. If this was an acceptable design, then we would not have > object inheritance and there won=92t be hundreds of APIs being opened up = by > cloud providers today. You might want to suggest one API to Amazon or oth= er > cloud providers. **** > > ** ** > > A practical operational issue with APIs is that users don=92t understand = all > the details. A user understands a server memory and CPU, but don=92t > understand VLAN and LUN, and zillions of other complicated things. Exposi= ng > them through APIs is useless because they can=92t use it. Why would a use= r > buy an expensive TV when they can=92t use most of the features, because t= he > 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=92s not a prevention. Once you > recognize a problem, you build a short-term cure and a long-term preventi= on > (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=92s APIs works with anot= her > vendor=92s 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,**** > > **** > > 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 mad= e > 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**** > > **** > > **** > > ** ** > --f46d0444736704739a04ba470668 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ashish,

My point was very simple.

You had talked about ca= ses where protocol is more flexible than an API, and I was trying to help y= ou understand that anything that can be done in an East West manner (with p= rotocols), can be done in North-South manner with API's. If you say we = can do something with protocols with only X packets, we can do the same wit= h just X API's too. That was my point and not the fact that we have onl= y 1 API or more.

Also API's on which base services sit and ones which end users use = could be different.

Am I missing the point altogether?

Thanks= ,
Vishwas

On Wed, Feb 29, 2012 at 6:51= PM, Ashish Dalela (adalela) <adalela@cisco.com> wrote:

Hi Vishwas,

=A0<= /p>

What everyone calls AP= I today uses a protocol =96 HTTP. APIs survive on the interoperability prov= ided by that protocol, and I don=92t think anyone can get away from that. T= he real question is =96 what is the right protocol on top of which to build= APIs? That=92s the question SOP is raising. Once you do that, then we can = talk of one or many APIs.

=A0<= /p>

Limitations of using H= TTP 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 s= ection describes what APIs can=92t do. Some of the limitations are because = API is always unicast, and there are many things for which you need a manyc= ast and broadcast. Other limitations because APIs are synchronous and you n= eed to be asynchronous in some cases. Yet other issues because APIs are sin= gle complete transaction, but some transactions will spread over multiple s= uch APIs.

=A0<= /p>

The total amount of in= formation in a message is unchanged whether you put it inside a protocol he= ader 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 ot= her 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 re= peating that for voice and video and chat content.

=A0<= /p>

To your point, you can= have a single API for doing anything. As the service evolves and complexit= y grows, the number of parameters to that API increases. And yes, you can m= ake that backward compatible in terms of implementation. But, nobody does t= hat =96 especially when the interface is end-user facing. If this was an ac= ceptable design, then we would not have object inheritance and there won=92= t be hundreds of APIs being opened up by cloud providers today. You might w= ant to suggest one API to Amazon or other cloud providers.

=A0<= /p>

A practical operationa= l issue with APIs is that users don=92t understand all the details. A user = understands a server memory and CPU, but don=92t understand VLAN and LUN, a= nd zillions of other complicated things. Exposing them through APIs is usel= ess because they can=92t use it. Why would a user buy an expensive TV when = they can=92t use most of the features, because the remote is too complicate= d? The need is to reduce complexity through automation, not expose it all t= o the user via APIs. In other words, you need a more sophisticated policy e= ngine not a sophisticated API system.

=A0<= /p>

For any problem there = is a cure and there is a prevention. Building API bridges is a cure to dive= rse APIs, it=92s not a prevention. Once you recognize a problem, you build = a short-term cure and a long-term prevention (at least ideally). Then, a si= ngle API is neither a cure nor prevention; its side-effects are so severe t= hat we might be living with the original problem as well.

=A0<= /p>

APIs have always exist= ed and will continue to exist. The goal is to interoperate diverse APIs wit= hout a translation bridge. That happens all the time with network protocols= , when one vendor=92s APIs works with another vendor=92s APIs without a tra= nslation bridge. I think not having a bridge is always better than having a= bridge. Agree?

=A0<= /p>

Thanks, Ashish<= u>

=A0<= /p>

=A0

From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: Wednesday, February 29, 2012 10:45 PM
To: Ashish Dal= ela (adalela)
Cc: Michael Hammer; sop@ietf.org


Subject: Re: [sop] SOP Requirements

=A0=

Hi Ashish,=

=A0

As the number of services increas= e or the complexity in a given service grows, this becomes very hard. Assum= e there is a service with N tunable parameters. You need at least N APIs th= at modify these parameters individually. Then permutations 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 br= idges, it=92s just inviting more complexity. Another limitation is that whe= n APIs have semantic incompatibilities, it becomes even harder to interoper= ate (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 we= ll 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 oper= ational standpoint, every new API introduction requires software upgrades t= o the controllers. That eventually hinders the rate of service creation.

=A0

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

That won=92t happen= if we separate service-independent and service-dependent pieces. An exampl= e of that is SNMP. SNMP is device/service independent. MIB defines the spec= ific service/device. If you have a standard protocol to manage a device, th= en 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. <= /u>

=A0<= /p>

BTW, I=92m not advocat= ing SNMP here because SNMP has many shortcomings in terms of network discov= ery, capability discovery, advertisements, transactions, etc. But, we need = to keep in mind that API proliferation is inevitable as services proliferat= e. Protocol proliferation is not inevitable. Similar separation has been do= ne in the past in SIP/SDP, HTTP/HTML, SMTP/MIME. That separation allows any= one to send any content in email to anyone. Or download any web-page, or ha= ve any type of codec (voice or video) use the same protocol.<= u>

=A0<= /p>

If you compare the suc= cess and widespread use of above mentioned protocols the value of separatio= n between service-independent and service-dependent seems pretty convincing= .

=A0=

>> C= orrect but the draft seems to differ.

=A0<= /p>

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

=A0=

>> T= he requirement seems contradictory to what we agree. Similar for points bel= ow.

=A0<= /p>

The requirement = is really that services are portable across providers. I think it is fair t= o 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.

=A0<= /p>

Thanks, Ashish<= u>

=A0<= /p>

=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<= /p>

=A0

Hi Michael,

Sounds like we ag= ree on most of the things, though I see the draft contradicting what we agr= ee 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 ado= pted by most providers. From the little I know OpenStack based API's ma= y be the alternative way and companies have built bridging layers to inter-= operate between the same.

=A0

=A0

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 perh= aps 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 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" etc could be used. All I am s= aying is can we use standard terms here.

=A0

<= div>

We can settle on specific terms to use, just so = long as we keep the distinction between the entity (enterprise?) that provi= sions 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 = Service, the operator of the Proxy provisions it with a CREATE, but the use= r 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 orchestration about creating services (from th= e cloud providers perspective), or an instance of a service (for a particul= ar user)? I think it is the latter, but doesn't sound so from the defin= ition.

=A0

<= div>

Orchestration is about the on-demand provisionin= g of the compute/storage/network/XaaS in the cloud by the subscriber/custom= er. =A0Once provisioned, the service can provide services to the intended u= ser. =A0We are trying to be general here. =A0Need to keep provisioning and = operations distinct. =A0"Service" is occurring in levels.<= u>

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 instantiatio= ns of those services. =A0Either may be hierarchically named.<= /p>

Hmm.
=A0

=A0

5. Is Scenario -1 talking about all providers should= provide the same services? I guess not. I think the idea should be the sam= e 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 servic= es, as it seems from the requirement.

=A0

<= div>

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

Bu= t, if two providers offer the same service, it should not require a new cus= tomer 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 requ= irement seems contradictory to what we agree. Similar for points below.

Thanks,
Vishwas
=A0

=A0

<= p class=3D"MsoNormal"> 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.

=A0

<= div>

Agree, and we would like that to be true for mul= ti-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 sh= ould inter-operate with each other. That is a business decision. I think wh= at you mean here is that providers should have a clear interoperable means = should they wish to inter-operate.

=A0

<= div>

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-operatio= n for all models? I would have thought we are focusing on the IaaS alone.

=A0<= /p>

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 similar services to me. Ho= w are they different - vendor versus provider?

=A0

We were considering cases where multiple companies are involved in providin= g all the capabilities needed. =A0One involved coordination within an admin= istrative domain, while the other involves independent administrative domai= ns. =A0We didn't want to limit this to single company operations. =A0La= rge 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 the base services and allow fo= r extensible services on top. There could be so many variants of the SaaS o= r even PaaS I am not sure how you would make every service inter-operate.

=A0

<= div>

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

Here we are trying to provide structure that al= lows easy extension, substitution, and innovation at the more service-speci= fic granular levels.

=A0

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

=A0

<= div>

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 too and not just between clouds.<= /u>

=A0

<= div>

Agree. =A0Internal to a cloud and from the custo= mer to the cloud are the simple cases. =A0

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

=A0=

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

=A0

Pr= obably needs more discussion. =A0I see content as a specific scenario. =A0T= here you don't care which copy of data is accessed so long as you reach= it. =A0In other types of services, a lot more control over who accesses wh= at is needed.

=A0

14. For Service disco= very. 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

=A0

=

=A0

=
--f46d0444736704739a04ba470668-- From adalela@cisco.com Fri Mar 2 19:04: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 748BB11E8074 for ; Fri, 2 Mar 2012 19:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.706 X-Spam-Level: X-Spam-Status: No, score=-7.706 tagged_above=-999 required=5 tests=[AWL=2.893, 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 OhU4xh492X30 for ; Fri, 2 Mar 2012 19:04:55 -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 A2B8711E8073 for ; Fri, 2 Mar 2012 19:04:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=4688; q=dns/txt; s=iport; t=1330743894; x=1331953494; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=3s7Ce/o5N/19hZXdhGK+Hb42HHO4Z1rY2JVoitFLnSU=; b=KfXmOHPm8Ti6lHXYIx3dLPwKSetS365j5zMcrHHKbyALXO6mDH3Jmd2C 1pKELVsvtrz/YUfxd/njKTH0IkKHChEYRu5XnbBr357ZqxA6iTU/L84fa ++5859JXHb6rOVOx55F1WqDobxT3KXyYsM1YePCQjrrAn2wppnQv/0bvq c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEALuJUU9Io8UY/2dsb2JhbABDtUSBfQEBAQMBAQEBDwEdCisJCwUHBAIBCBEBAwEBAQoGFwEGASYfAwYIAQEECwgIEweHXwULmjYBnm4EiggKhVpjBIhOn22BTAE X-IronPort-AV: E=Sophos;i="4.73,523,1325462400"; d="scan'208";a="7021201" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 03 Mar 2012 03:04:52 +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 q2334lja016384; Sat, 3 Mar 2012 03:04:47 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); Sat, 3 Mar 2012 08:34:47 +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: Sat, 3 Mar 2012 08:34:38 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C51031BC9CA@XMB-BGL-416.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sop] SOP Requirements Thread-Index: Acz4oXXyJoJkw3QDQ8i71IRIF641YgASKWww 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> <618BE8B40039924EB9AED233D4A09C51031BC6F5@XMB-BGL-416.cisco.com> From: "Ashish Dalela (adalela)" To: "Jamal Hadi Salim" X-OriginalArrivalTime: 03 Mar 2012 03:04:47.0202 (UTC) FILETIME=[6414C420:01CCF8EA] 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: Sat, 03 Mar 2012 03:04:56 -0000 Hi Jamal, Yes, the IETF format is to describe requirements and/or problem statements before you put out a solution. So, we have put both a problem statement and a solution. Thanks, Ashish -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@mojatatu.com]=20 Sent: Friday, March 02, 2012 11:52 PM To: Ashish Dalela (adalela) Cc: Vishwas Manral; sop@ietf.org; Michael Hammer Subject: Re: [sop] SOP Requirements Hi Ashish, I will read the drafts and provide better comments. I guess the point i was missing was you put out requirements to look for a protocol and it turns out you already have a protocol which suits your needs. cheers, jamal On Thu, Mar 1, 2012 at 1:08 PM, Ashish Dalela (adalela) wrote: > > Please note that the resources we create and the names we assign them > have to be DNS accessible. That's because from a user standpoint cloud > and non-cloud services must work just the same. Hence, you don't want to > give a name like - abc.vm.someID. You want to give a name that will be > resolved by a DNS server so that the user can reach that server in the > same way, transparent to the fact that it is cloud created. Ok - didnt realize that angle. > To make cloud work incrementally, we need a separate name space for > "types", and not mix it with existing names in DNS. So, we end up with > two name spaces - one for types and another for instances. The > properties of an instance are really properties of a "type" but > referenced by an instance. The "type" can have a "name" attribute that > references an instance, without loss of generality. That way, if we > change the name, we are still consistent. > >>> Is the requirements one the best one to focus one (that is the one i > have looked at). > > Requirements is certainly the place to start at. Many of the questions > you have raise also touch upon architecture, and specifics are in the > protocol draft. Look forward to your comments. > > 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 10:39 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 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 > _______________________________________________ > sop mailing list > sop@ietf.org > https://www.ietf.org/mailman/listinfo/sop From adalela@cisco.com Fri Mar 2 19:26: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 716CE21E8011 for ; Fri, 2 Mar 2012 19:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.741 X-Spam-Level: X-Spam-Status: No, score=-7.741 tagged_above=-999 required=5 tests=[AWL=2.857, 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 rtXyQxERGIAX for ; Fri, 2 Mar 2012 19:26:47 -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 5AD3421E800E for ; Fri, 2 Mar 2012 19:26:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=62864; q=dns/txt; s=iport; t=1330745204; x=1331954804; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=O2L/70EKoVPany2L6e8lvY9Wkh2RfRbErJj4poq4dMI=; b=llnVpW4nSCXCSHo6lw+sWgg8hVBKWXG0dxiQem3IOEHTeWYZHodjVqqz J5DRaoCOeZKjA9rIbE1CBXbZx9mnlH4K8apjwavX1tL9vqkCW+P9lHuSY J1vEJIjnM3kmUa7vtCulDR02eEgRLWtNp+aLjpfpabQkDz4E6ZRD+8Vuh c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoEAHeOUU9Io8UY/2dsb2JhbABDgkWoewGKA4F9AQEBAwEBAQEPAQcCEQM+CxACAQgRAQMBAQsGEAEGAQYBIAYfAwYIAQEECwgIFwOHXwULmj4Bnm+JIGkJBoVUYwSITohDj0uHX4FNAQY X-IronPort-AV: E=Sophos;i="4.73,523,1325462400"; d="scan'208,217";a="7021581" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 03 Mar 2012 03:26:42 +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 q233QgLx008785; Sat, 3 Mar 2012 03:26:42 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); Sat, 3 Mar 2012 08:56: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_01CCF8ED.7364AFD9" Date: Sat, 3 Mar 2012 08:56:39 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C51031BC9CC@XMB-BGL-416.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sop] SOP Requirements Thread-Index: Acz4pRoxhAZkua+2RZWI6EIEZQKw8wARWCDw References: <618BE8B40039924EB9AED233D4A09C51030E1263@XMB-BGL-416.cisco.com><618BE8B40039924EB9AED233D4A09C51031BC437@XMB-BGL-416.cisco.com> From: "Ashish Dalela (adalela)" To: "Vishwas Manral" X-OriginalArrivalTime: 03 Mar 2012 03:26:41.0938 (UTC) FILETIME=[73B98F20:01CCF8ED] 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: Sat, 03 Mar 2012 03:26:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCF8ED.7364AFD9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Vishwas, =20 It is better if you comment on the drafts because there is a section dedicated to this very topic. =20 http://tools.ietf.org/html/draft-dalela-orchestration-00#section-8=20 =20 This describes what you can't do with web-services (assuming that's what you mean by APIs). This is *not* the shortcoming of the APIs, but that of the underlying *protocol* (HTTP). So, if you changed the underlying protocol to fix issues with HTTP, then the APIs would be more powerful. That protocol we propose to be SOP. =20 You are mistaking me in pitching API against protocols. I'm pitching protocol (HTTP) against protocol (SOP). Unfortunately, application developers abuse the term API to mean HTTP web-services, and the discussion is then messed up into thinking protocol against API. =20 Thanks, Ashish =20 From: sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] On Behalf Of Vishwas Manral Sent: Saturday, March 03, 2012 12:19 AM To: Ashish Dalela (adalela) Cc: sop@ietf.org; Michael Hammer Subject: Re: [sop] SOP Requirements =20 Hi Ashish, My point was very simple.=20 You had talked about cases where protocol is more flexible than an API, and I was trying to help you understand that anything that can be done in an East West manner (with protocols), can be done in North-South manner with API's. If you say we can do something with protocols with only X packets, we can do the same with just X API's too. That was my point and not the fact that we have only 1 API or more. Also API's on which base services sit and ones which end users use could be different. Am I missing the point altogether? Thanks, Vishwas On Wed, Feb 29, 2012 at 6:51 PM, Ashish Dalela (adalela) wrote: 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 =20 ------_=_NextPart_001_01CCF8ED.7364AFD9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Vishwas,

 

It is better if you comment on the drafts because there is a section = dedicated to this very topic.

 

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

 

This describes what you can’t do with web-services (assuming = that’s what you mean by APIs). This is *not* the = shortcoming of the APIs, but that of the underlying *protocol* = (HTTP). So, if you changed the underlying protocol to fix issues with = HTTP, then the APIs would be more powerful. That protocol we propose to = be SOP.

 

You are mistaking me in pitching API against protocols. I’m = pitching protocol (HTTP) against protocol (SOP). Unfortunately, = application developers abuse the term API to mean HTTP web-services, and = the discussion is then messed up into thinking protocol against = API.

 

Thanks, Ashish

 

From:= = sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] On Behalf Of = Vishwas Manral
Sent: Saturday, March 03, 2012 12:19 = AM
To: Ashish Dalela (adalela)
Cc: sop@ietf.org; = Michael Hammer
Subject: Re: [sop] SOP = Requirements

 

Hi Ashish,

My point was very = simple.

You had talked about cases where protocol is more = flexible than an API, and I was trying to help you understand that = anything that can be done in an East West manner (with protocols), can = be done in North-South manner with API's. If you say we can do something = with protocols with only X packets, we can do the same with just X API's = too. That was my point and not the fact that we have only 1 API or = more.

Also API's on which base services sit and ones which end = users use could be different.

Am I missing the point = altogether?

Thanks,
Vishwas

On Wed, Feb 29, 2012 at 6:51 PM, Ashish Dalela = (adalela) <adalela@cisco.com> = wrote:

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

 <= /o:p>

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>

 <= /o:p>

 

------_=_NextPart_001_01CCF8ED.7364AFD9-- From vishwas.ietf@gmail.com Mon Mar 5 13:00: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 634A421F882C for ; Mon, 5 Mar 2012 13:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.946 X-Spam-Level: X-Spam-Status: No, score=-2.946 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_20=-0.74, 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 3k7ocI5AiGhp for ; Mon, 5 Mar 2012 13:00:15 -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 D9B0521F8953 for ; Mon, 5 Mar 2012 13:00:09 -0800 (PST) Received: by ggmi1 with SMTP id i1so2152749ggm.31 for ; Mon, 05 Mar 2012 13:00:09 -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 p6mr10303318oeg.36.1330981209431 (num_hops = 1); Mon, 05 Mar 2012 13:00:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VZvN99jalJfmDtU6Tv6FiYdmm3pGGgqDChklSALun5E=; b=uL4v97XE8g66ij81oQwXwSCZ8IauBZ4Hc3HNR6wVc3WyIogRk9ZJ7eqnYVJCs2c4XB px60Hz/c2ZIQqsRiLtd8mr/qJdHF31w09Ih01D+fjZO2+29YC0HTU16Ofbd8jaS5IzVn 6a9WPZX84IJR/h3z9GHuonSCMSR2qkKjAVA+9bobgE/DXJrXZcIMNH5LvXbAbqfpOXxY y+Y2dACiKOdZsGSMpA7NmpAvTZ0B/DnZaOim8v2PT5pq31ylaPXLcyqMQsw1r1OzDO5l R0jPkzw1ztikQjgMDt7S/SQoMKzzvR6YYzIdaxbpjin9gIDgaCKt9/Z6nMrosZRZzPz4 j7NA== MIME-Version: 1.0 Received: by 10.60.27.6 with SMTP id p6mr8907638oeg.36.1330981209245; Mon, 05 Mar 2012 13:00:09 -0800 (PST) Received: by 10.182.165.1 with HTTP; Mon, 5 Mar 2012 13:00:09 -0800 (PST) In-Reply-To: <618BE8B40039924EB9AED233D4A09C51031BC9CC@XMB-BGL-416.cisco.com> References: <618BE8B40039924EB9AED233D4A09C51030E1263@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BC437@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BC9CC@XMB-BGL-416.cisco.com> Date: Mon, 5 Mar 2012 13:00:09 -0800 Message-ID: From: Vishwas Manral To: "Ashish Dalela (adalela)" Content-Type: multipart/alternative; boundary=e89a8fb1ef182e08db04ba8536df 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: Mon, 05 Mar 2012 21:00:18 -0000 --e89a8fb1ef182e08db04ba8536df Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ashish, Thanks for the mail. So I looked at some of the reasons you mentioned you want to go in for SOP instead of HTTP. I however have worked in the past with the DLNA stack, where we extended HTTP and used protocols like SOAP to get behaviors you mention - like service discovery, transaction support etc. If that is what we want, we should look at the DLNA stack and see how we can leverage existing mechanisms for the same. I however think finalizing the requirements is a good start. Thanks, Vishwas On Fri, Mar 2, 2012 at 7:26 PM, Ashish Dalela (adalela) wrote: > Hi Vishwas,**** > > ** ** > > It is better if you comment on the drafts because there is a section > dedicated to this very topic.**** > > ** ** > > http://tools.ietf.org/html/draft-dalela-orchestration-00#section-8 **** > > ** ** > > This describes what you can=92t do with web-services (assuming that=92s w= hat > you mean by APIs). This is **not** the shortcoming of the APIs, but that > of the underlying **protocol** (HTTP). So, if you changed the underlying > protocol to fix issues with HTTP, then the APIs would be more powerful. > That protocol we propose to be SOP.**** > > ** ** > > You are mistaking me in pitching API against protocols. I=92m pitching > protocol (HTTP) against protocol (SOP). Unfortunately, application > developers abuse the term API to mean HTTP web-services, and the discussi= on > is then messed up into thinking protocol against API.**** > > ** ** > > Thanks, Ashish**** > > ** ** > > *From:* sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] *On Behalf Of = *Vishwas > Manral > *Sent:* Saturday, March 03, 2012 12:19 AM > *To:* Ashish Dalela (adalela) > *Cc:* sop@ietf.org; Michael Hammer > > *Subject:* Re: [sop] SOP Requirements**** > > ** ** > > Hi Ashish, > > My point was very simple. > > You had talked about cases where protocol is more flexible than an API, > and I was trying to help you understand that anything that can be done in > an East West manner (with protocols), can be done in North-South manner > with API's. If you say we can do something with protocols with only X > packets, we can do the same with just X API's too. That was my point and > not the fact that we have only 1 API or more. > > Also API's on which base services sit and ones which end users use could > be different. > > Am I missing the point altogether? > > Thanks, > Vishwas**** > > On Wed, Feb 29, 2012 at 6:51 PM, Ashish Dalela (adalela) < > adalela@cisco.com> wrote:**** > > Hi Vishwas,**** > > **** > > What everyone calls API today uses a protocol =96 HTTP. APIs survive on t= he > interoperability provided by that protocol, and I don=92t think anyone ca= n > get away from that. The real question is =96 what is the right protocol o= n > top of which to build APIs? That=92s the question SOP is raising. Once yo= u do > that, then we can talk of one or many APIs.**** > > **** > > Limitations of using HTTP as the underlying protocol for any API have bee= n > described in detail in the requirements draft. I would like to hear your > comments on that. That section describes what APIs can=92t do. Some of th= e > limitations are because API is always unicast, and there are many things > for which you need a manycast and broadcast. Other limitations because AP= Is > are synchronous and you need to be asynchronous in some cases. Yet other > issues because APIs are single complete transaction, but some transaction= s > 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 t= he > protocol header saves you having to reinvent them in the content for ever= y > type of service. In other words, a protocol saves you from increasing > information across various services. As an example in SIP, we put From an= d > 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 AP= I > increases. And yes, you can make that backward compatible in terms of > implementation. But, nobody does that =96 especially when the interface i= s > end-user facing. If this was an acceptable design, then we would not have > object inheritance and there won=92t be hundreds of APIs being opened up = by > cloud providers today. You might want to suggest one API to Amazon or oth= er > cloud providers. **** > > **** > > A practical operational issue with APIs is that users don=92t understand = all > the details. A user understands a server memory and CPU, but don=92t > understand VLAN and LUN, and zillions of other complicated things. Exposi= ng > them through APIs is useless because they can=92t use it. Why would a use= r > buy an expensive TV when they can=92t use most of the features, because t= he > 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=92s not a prevention. Once you > recognize a problem, you build a short-term cure and a long-term preventi= on > (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=92s APIs works with anot= her > vendor=92s 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,**** > > **** > > 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 mad= e > 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**** > > **** > > **** > > **** > > ** ** > --e89a8fb1ef182e08db04ba8536df Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ashish,

Thanks for the mail.

So I looked at some of the re= asons you mentioned you want to go in for SOP instead of HTTP.

I how= ever have worked in the past with the DLNA stack, where we extended HTTP an= d used protocols like SOAP to get behaviors you mention - like service disc= overy, transaction support etc.

If that is what we want, we should look at the DLNA stack and see how w= e can leverage existing mechanisms for the same.

I however think fi= nalizing the requirements is a good start.

Thanks,
Vishwas

On Fri, Mar 2, 2012 at 7:26 PM, Ashish Dalel= a (adalela) <adal= ela@cisco.com> wrote:

Hi Vishwas,

=A0

It is better if you comment on the drafts bec= ause there is a section dedicated to this very topic.<= /p>

=A0<= /p>

http://tools.ietf.org/html/= draft-dalela-orchestration-00#section-8 <= /u>

=A0<= /p>

This describes what yo= u can=92t do with web-services (assuming that=92s what you mean by APIs). T= his is *not* the shortcoming of the APIs, but that of the underlying= *protocol* (HTTP). So, if you changed the underlying protocol to fi= x issues with HTTP, then the APIs would be more powerful. That protocol we = propose to be SOP.

=A0<= /p>

You are mistaking me i= n pitching API against protocols. I=92m pitching protocol (HTTP) against pr= otocol (SOP). Unfortunately, application developers abuse the term API to m= ean HTTP web-services, and the discussion is then messed up into thinking p= rotocol against API.

=A0<= /p>

Thanks, Ashish<= u>

=A0<= /p>

From: sop-bounces@ietf.org= [mailto:sop-boun= ces@ietf.org] On Behalf Of Vishwas Manral
Sent: Saturday, March 03, 2012 12:19 AM
To: Ashish Dalela = (adalela)
Cc: s= op@ietf.org; Michael Hammer


Sub= ject: Re: [sop] SOP Requirements

=A0=

Hi Ashish,=

My point was very simple.

You had talked about cases where = protocol is more flexible than an API, and I was trying to help you underst= and that anything that can be done in an East West manner (with protocols),= can be done in North-South manner with API's. If you say we can do som= ething with protocols with only X packets, we can do the same with just X A= PI's too. That was my point and not the fact that we have only 1 API or= more.

Also API's on which base services sit and ones which end users use = could be different.

Am I missing the point altogether?

Thanks= ,
Vishwas

On Wed, Feb 29, 2= 012 at 6:51 PM, Ashish Dalela (adalela) <adalela@cisco.com> wrote:

Hi Vishwas,

=A0<= /span>

What everyone calls API t= oday uses a protocol =96 HTTP. APIs survive on the interoperability provide= d by that protocol, and I don=92t think anyone can get away from that. The = real question is =96 what is the right protocol on top of which to build AP= Is? That=92s the question SOP is raising. Once you do that, then we can tal= k of one or many APIs.

=A0<= /p>

Limitations of using H= TTP 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 s= ection describes what APIs can=92t do. Some of the limitations are because = API is always unicast, and there are many things for which you need a manyc= ast and broadcast. Other limitations because APIs are synchronous and you n= eed to be asynchronous in some cases. Yet other issues because APIs are sin= gle complete transaction, but some transactions will spread over multiple s= uch APIs.

=A0<= /p>

The total amount of in= formation in a message is unchanged whether you put it inside a protocol he= ader 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 ot= her 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 re= peating that for voice and video and chat content.

=A0<= /p>

To your point, you can= have a single API for doing anything. As the service evolves and complexit= y grows, the number of parameters to that API increases. And yes, you can m= ake that backward compatible in terms of implementation. But, nobody does t= hat =96 especially when the interface is end-user facing. If this was an ac= ceptable design, then we would not have object inheritance and there won=92= t be hundreds of APIs being opened up by cloud providers today. You might w= ant to suggest one API to Amazon or other cloud providers.

=A0<= /p>

A practical operationa= l issue with APIs is that users don=92t understand all the details. A user = understands a server memory and CPU, but don=92t understand VLAN and LUN, a= nd zillions of other complicated things. Exposing them through APIs is usel= ess because they can=92t use it. Why would a user buy an expensive TV when = they can=92t use most of the features, because the remote is too complicate= d? The need is to reduce complexity through automation, not expose it all t= o the user via APIs. In other words, you need a more sophisticated policy e= ngine not a sophisticated API system.

=A0<= /p>

For any problem there = is a cure and there is a prevention. Building API bridges is a cure to dive= rse APIs, it=92s not a prevention. Once you recognize a problem, you build = a short-term cure and a long-term prevention (at least ideally). Then, a si= ngle API is neither a cure nor prevention; its side-effects are so severe t= hat we might be living with the original problem as well. =

=A0<= /p>

APIs have always exist= ed and will continue to exist. The goal is to interoperate diverse APIs wit= hout a translation bridge. That happens all the time with network protocols= , when one vendor=92s APIs works with another vendor=92s APIs without a tra= nslation bridge. I think not having a bridge is always better than having a= bridge. Agree?

=A0<= /p>

Thanks, Ashish<= u>

=A0<= /p>

=A0

From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: Wednesday, February 29, 2012 10:45 PM
To: Ashish Dal= ela (adalela)
Cc: Michael Hammer; sop@ietf.org


Subject: Re: [sop] SOP Requirements

=A0

Hi Ashish,

=A0

As the number of services increas= e or the complexity in a given service grows, this becomes very hard. Assum= e there is a service with N tunable parameters. You need at least N APIs th= at modify these parameters individually. Then permutations 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 br= idges, it=92s just inviting more complexity. Another limitation is that whe= n APIs have semantic incompatibilities, it becomes even harder to interoper= ate (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 we= ll 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 oper= ational standpoint, every new API introduction requires software upgrades t= o the controllers. That eventually hinders the rate of service creation.

=A0

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

That won=92t happen= if we separate service-independent and service-dependent pieces. An exampl= e of that is SNMP. SNMP is device/service independent. MIB defines the spec= ific service/device. If you have a standard protocol to manage a device, th= en 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. <= /u>

=A0<= /p>

BTW, I=92m not advocat= ing SNMP here because SNMP has many shortcomings in terms of network discov= ery, capability discovery, advertisements, transactions, etc. But, we need = to keep in mind that API proliferation is inevitable as services proliferat= e. Protocol proliferation is not inevitable. Similar separation has been do= ne in the past in SIP/SDP, HTTP/HTML, SMTP/MIME. That separation allows any= one to send any content in email to anyone. Or download any web-page, or ha= ve any type of codec (voice or video) use the same protocol.<= u>

=A0<= /p>

If you compare the suc= cess and widespread use of above mentioned protocols the value of separatio= n between service-independent and service-dependent seems pretty convincing= .

=A0=

>> C= orrect but the draft seems to differ.

=A0<= /p>

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

=A0=

>> T= he requirement seems contradictory to what we agree. Similar for points bel= ow.

=A0<= /p>

The requirement = is really that services are portable across providers. I think it is fair t= o 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.

=A0<= /p>

Thanks, Ashish<= u>

=A0<= /p>

=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<= /p>

=A0

Hi Michael,

Sounds like we ag= ree on most of the things, though I see the draft contradicting what we agr= ee 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 ado= pted by most providers. From the little I know OpenStack based API's ma= y be the alternative way and companies have built bridging layers to inter-= operate between the same.

=A0

=A0

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 perh= aps 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 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" etc could be used. All I am s= aying is can we use standard terms here.

=A0

<= div>

We can settle on specific terms to use, just so = long as we keep the distinction between the entity (enterprise?) that provi= sions 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 = Service, the operator of the Proxy provisions it with a CREATE, but the use= r 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 orchestration about creating services (from th= e cloud providers perspective), or an instance of a service (for a particul= ar user)? I think it is the latter, but doesn't sound so from the defin= ition.

=A0

<= div>

Orchestration is about the on-demand provisionin= g of the compute/storage/network/XaaS in the cloud by the subscriber/custom= er. =A0Once provisioned, the service can provide services to the intended u= ser. =A0We are trying to be general here. =A0Need to keep provisioning and = operations distinct. =A0"Service" is occurring in levels.<= u>

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 instantiatio= ns of those services. =A0Either may be hierarchically named.<= /p>

Hmm.
=A0

=A0

5. Is Scenario -1 talking about all providers should= provide the same services? I guess not. I think the idea should be the sam= e 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 servic= es, as it seems from the requirement.

=A0

<= div>

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

Bu= t, if two providers offer the same service, it should not require a new cus= tomer 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 requ= irement seems contradictory to what we agree. Similar for points below.

Thanks,
Vishwas
=A0

=A0

<= p class=3D"MsoNormal"> 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.

=A0

<= div>

Agree, and we would like that to be true for mul= ti-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 sh= ould inter-operate with each other. That is a business decision. I think wh= at you mean here is that providers should have a clear interoperable means = should they wish to inter-operate.

=A0

<= div>

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-operatio= n for all models? I would have thought we are focusing on the IaaS alone.

=A0<= /p>

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 similar services to me. Ho= w are they different - vendor versus provider?

=A0

We were considering cases where multiple companies are involved in providin= g all the capabilities needed. =A0One involved coordination within an admin= istrative domain, while the other involves independent administrative domai= ns. =A0We didn't want to limit this to single company operations. =A0La= rge 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 the base services and allow fo= r extensible services on top. There could be so many variants of the SaaS o= r even PaaS I am not sure how you would make every service inter-operate.

=A0

<= div>

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

Here we are trying to provide structure that al= lows easy extension, substitution, and innovation at the more service-speci= fic granular levels.

=A0

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

=A0

<= div>

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 too and not just between clouds.<= /u>

=A0

<= div>

Agree. =A0Internal to a cloud and from the custo= mer to the cloud are the simple cases. =A0

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

=A0=

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

=A0

Pr= obably needs more discussion. =A0I see content as a specific scenario. =A0T= here you don't care which copy of data is accessed so long as you reach= it. =A0In other types of services, a lot more control over who accesses wh= at is needed.

=A0

14. For Service disco= very. 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

=A0

=

=A0

=

=A0

<= /div>
--e89a8fb1ef182e08db04ba8536df-- From adalela@cisco.com Tue Mar 6 05:25: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 6B36C21F8656 for ; Tue, 6 Mar 2012 05:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.775 X-Spam-Level: X-Spam-Status: No, score=-7.775 tagged_above=-999 required=5 tests=[AWL=2.823, 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 AFrEbTcq0Kzy for ; Tue, 6 Mar 2012 05:24:50 -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 9C35E21F850C for ; Tue, 6 Mar 2012 05:24:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=78372; q=dns/txt; s=iport; t=1331040286; x=1332249886; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=dqG2QinRwWsBhp5VUzQ01n/iSW1K+M6sA5R+J1jEhX4=; b=CFa9MoyNbERJaIT+415FenRDikty61KDinUukFfMvFawfWemDETcKiA4 Kgba4fg7wlyVRVB84TvirlkvcY0wcKdIgkl385nCAwPv6+vMiFQKUcpzL S7Au1dNch1dqD9qLmQpUGVU5bao6W3Bsg84g+v8zirOXMew14bnkZn/dT Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8GAKcPVk9Io8UY/2dsb2JhbAA6CYJFhVmjSQGKB4F9AQEBAwEBAQEPAQcBAREDPQELEAIBCBEBAwEBCwIEEAEGAQYBIAYfAwYIAQEECwgIFwOHYAULmh8BnxSJO2cEBAUGhUZjBIJdhXOIQo9NhHaBNIE3gU0BBg X-IronPort-AV: E=Sophos;i="4.73,540,1325462400"; d="scan'208,217";a="7217344" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 06 Mar 2012 13:24:43 +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 q26DOfWE013917; Tue, 6 Mar 2012 13:24:41 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, 6 Mar 2012 18:54: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_01CCFB9C.7C8155F5" Date: Tue, 6 Mar 2012 18:54:38 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C51031BCFC2@XMB-BGL-416.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sop] SOP Requirements Thread-Index: Acz7Evy0pCtnLGa7TxuC4wgTcebMzQASjf5g References: <618BE8B40039924EB9AED233D4A09C51030E1263@XMB-BGL-416.cisco.com><618BE8B40039924EB9AED233D4A09C51031BC437@XMB-BGL-416.cisco.com><618BE8B40039924EB9AED233D4A09C51031BC9CC@XMB-BGL-416.cisco.com> From: "Ashish Dalela (adalela)" To: "Vishwas Manral" X-OriginalArrivalTime: 06 Mar 2012 13:24:41.0399 (UTC) FILETIME=[7CCA1470:01CCFB9C] 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: Tue, 06 Mar 2012 13:25:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFB9C.7C8155F5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Vishwas, =20 I'm supposing that you are talking about SSDP (http://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol)? Let me know if that is correct. =20 In any large network, multicast isn't the right way to scale. If every network element has to do a IGMP join to receive ADVERTISE then it becomes a scaling issue. It also becomes a security problem where some rogue element can start sending multicast ADVERTISE and hijack the orchestration sessions.=20 =20 Broadcast doesn't scale either, but we can convert it to a directed unicast (like DHCP for example). There are other reasons as well, such as if there are multiple service specific controllers then you have to choose different multicast groups for each. It seems like we should use broadcast for this to be light-weight, and multicast could be an option in case of L3 networks, but with additional access controls. =20 Regarding which existing protocol to extend, there are multiple options: =20 HTTP - has CRUD, but doesn't support ADVERTISE, DISCOVER, REGISTER, NOTIFY, SUBSCRIBE, COMMIT, CANCEL etc. So, just adding a NOTIFY, as you suggest through SSDP, is still not going to be enough. Orchestration also needs "identities" such as device@provider.com, which HTTP doesn't have. =20 XMPP - has PUBLISH, SUBSCRIBE, and identities, but not all of the above. Service requests will require a "VIA" and dynamic injection of path elements, especially when a request forks into multiple requests or is re-directed to a different provider / location. =20 AMQP - this is designed for messaging and again lacks many of the constructs. =20 So wherever we look, the extension curve is long. It seemed like the problem space is big enough to warrant a new protocol. =20 The other issue is how easily we can implement the security for orchestration. E.g. if we use IPSec end-to-end then how do hops in the middle route the request differently (the nearest location, the cheapest location, location with capacity, the location allowed by law, etc.). The right model seems to be that we embed integrity within the protocol rather than into IPSec. Privacy can be implemented separately between the edges using IPSec. That security model requires another set of issues to be solved in the current protocols (if we extend them). =20 Besides security, there are other types of issues. For instance, a network might use UDP internally to get broadcast but use TCP for unicast externally for higher reliability. That change between TCP and UDP causes loss of transaction identity, and transactions have to be built part of the protocol. Likewise, with overlays, and overlay translations, the location information could be easily lost. Hence, you need location in the orchestration protocol. NAT may obfuscate real topology, and we lose information about the actual distance between two end-points.=20 =20 Given these challenges, we choose to define a protocol that can be tweaked over time for orchestration specific needs without having to worry about backward compatibility, and/or how this gets broken by overlay, firewalls, or NAT'd networks. SIP already went over this hump and providers have learnt (somewhat painfully) on how to do this in a way that works. That entire learning can be leveraged for cloud. =20 In any case, not sure if you have seen it, but there is a draft for SOP that describes just what I'm talking about. =20 http://tools.ietf.org/html/draft-dalela-sop-00 http://tools.ietf.org/html/draft-dalela-sop-flows-00 =20 Look forward to your comments. =20 Thanks, Ashish =20 From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]=20 Sent: Tuesday, March 06, 2012 2:30 AM To: Ashish Dalela (adalela) Cc: sop@ietf.org; Michael Hammer Subject: Re: [sop] SOP Requirements =20 Hi Ashish, Thanks for the mail. So I looked at some of the reasons you mentioned you want to go in for SOP instead of HTTP. I however have worked in the past with the DLNA stack, where we extended HTTP and used protocols like SOAP to get behaviors you mention - like service discovery, transaction support etc. If that is what we want, we should look at the DLNA stack and see how we can leverage existing mechanisms for the same.=20 I however think finalizing the requirements is a good start. Thanks, Vishwas On Fri, Mar 2, 2012 at 7:26 PM, Ashish Dalela (adalela) wrote: Hi Vishwas, =20 It is better if you comment on the drafts because there is a section dedicated to this very topic. =20 http://tools.ietf.org/html/draft-dalela-orchestration-00#section-8=20 =20 This describes what you can't do with web-services (assuming that's what you mean by APIs). This is *not* the shortcoming of the APIs, but that of the underlying *protocol* (HTTP). So, if you changed the underlying protocol to fix issues with HTTP, then the APIs would be more powerful. That protocol we propose to be SOP. =20 You are mistaking me in pitching API against protocols. I'm pitching protocol (HTTP) against protocol (SOP). Unfortunately, application developers abuse the term API to mean HTTP web-services, and the discussion is then messed up into thinking protocol against API. =20 Thanks, Ashish =20 From: sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] On Behalf Of Vishwas Manral Sent: Saturday, March 03, 2012 12:19 AM To: Ashish Dalela (adalela) Cc: sop@ietf.org; Michael Hammer Subject: Re: [sop] SOP Requirements =20 Hi Ashish, My point was very simple.=20 You had talked about cases where protocol is more flexible than an API, and I was trying to help you understand that anything that can be done in an East West manner (with protocols), can be done in North-South manner with API's. If you say we can do something with protocols with only X packets, we can do the same with just X API's too. That was my point and not the fact that we have only 1 API or more. Also API's on which base services sit and ones which end users use could be different. Am I missing the point altogether? Thanks, Vishwas On Wed, Feb 29, 2012 at 6:51 PM, Ashish Dalela (adalela) wrote: 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 =20 =20 ------_=_NextPart_001_01CCFB9C.7C8155F5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Vishwas,

 =

I’m = supposing that you are talking about SSDP (h= ttp://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol)? Let = me know if that is correct.

 <= /p>

In any large network, = multicast isn’t the right way to scale. If every network element = has to do a IGMP join to receive ADVERTISE then it becomes a scaling = issue. It also becomes a security problem where some rogue element can = start sending multicast ADVERTISE and hijack the orchestration sessions. =

 <= /p>

Broadcast doesn’t = scale either, but we can convert it to a directed unicast (like DHCP for = example). There are other reasons as well, such as if there are multiple = service specific controllers then you have to choose different multicast = groups for each. It seems like we should use broadcast for this to be = light-weight, and multicast could be an option in case of L3 networks, = but with additional access controls.

 <= /p>

Regarding which existing = protocol to extend, there are multiple options:

 <= /p>

HTTP – has CRUD, = but doesn’t support ADVERTISE, DISCOVER, REGISTER, NOTIFY, = SUBSCRIBE, COMMIT, CANCEL etc. So, just adding a NOTIFY, as you suggest = through SSDP, is still not going to be enough. Orchestration also needs = “identities” such as device@provider.com, which HTTP = doesn’t have.

 <= /p>

XMPP – has = PUBLISH, SUBSCRIBE, and identities, but not all of the above. Service = requests will require a “VIA” and dynamic injection of path = elements, especially when a request forks into multiple requests or is = re-directed to a different provider / location.

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

AMQP – this is = designed for messaging and again lacks many of the = constructs.

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

So wherever we look, the = extension curve is long. It seemed like the problem space is big enough = to warrant a new protocol.

    &= nbsp;          =

The other issue is how = easily we can implement the security for orchestration. E.g. if we use = IPSec end-to-end then how do hops in the middle route the request = differently (the nearest location, the cheapest location, location with = capacity, the location allowed by law, etc.). The right model seems to = be that we embed integrity within the protocol rather than into IPSec. = Privacy can be implemented separately between the edges using IPSec. = That security model requires another set of issues to be solved in the = current protocols (if we extend them).

 <= /p>

Besides security, there = are other types of issues. For instance, a network might use UDP = internally to get broadcast but use TCP for unicast externally for = higher reliability. That change between TCP and UDP causes loss of = transaction identity, and transactions have to be built part of the = protocol. Likewise, with overlays, and overlay translations, the = location information could be easily lost. Hence, you need location in = the orchestration protocol. NAT may obfuscate real topology, and we lose = information about the actual distance between two end-points. =

 <= /p>

Given these challenges, = we choose to define a protocol that can be tweaked over time for = orchestration specific needs without having to worry about backward = compatibility, and/or how this gets broken by overlay, firewalls, or = NAT’d networks. SIP already went over this hump and providers have = learnt (somewhat painfully) on how to do this in a way that works. That = entire learning can be leveraged for cloud.

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

In any case, not sure if = you have seen it, but there is a draft for SOP that describes just what = I’m talking about.

 <= /p>

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

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

 =

Look = forward to your comments.

  = ;            =           =

Thanks, = Ashish

 

From:= = Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: Tuesday, = March 06, 2012 2:30 AM
To: Ashish Dalela = (adalela)
Cc: sop@ietf.org; Michael Hammer
Subject: = Re: [sop] SOP Requirements

 

Hi Ashish,

Thanks for the = mail.

So I looked at some of the reasons you mentioned you want = to go in for SOP instead of HTTP.

I however have worked in the = past with the DLNA stack, where we extended HTTP and used protocols like = SOAP to get behaviors you mention - like service discovery, transaction = support etc.

If that is what we want, we should look at the DLNA = stack and see how we can leverage existing mechanisms for the same. =

I however think finalizing the requirements is a good = start.

Thanks,
Vishwas

On Fri, Mar 2, 2012 at 7:26 PM, Ashish Dalela = (adalela) <adalela@cisco.com> = wrote:

Hi Vishwas,

 

It is better if you comment on the drafts because there is a section = dedicated to this very topic.

 

http://tools.ietf.org/html/draft-dalela-orchestration-0= 0#section-8

 

This describes what you can’t do with web-services (assuming = that’s what you mean by APIs). This is *not* the = shortcoming of the APIs, but that of the underlying *protocol* = (HTTP). So, if you changed the underlying protocol to fix issues with = HTTP, then the APIs would be more powerful. That protocol we propose to = be SOP.

 

You are mistaking me in pitching API against protocols. I’m = pitching protocol (HTTP) against protocol (SOP). Unfortunately, = application developers abuse the term API to mean HTTP web-services, and = the discussion is then messed up into thinking protocol against = API.

 

Thanks, Ashish

 

From:= = sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] On Behalf Of Vishwas = Manral
Sent: Saturday, March 03, 2012 12:19 AM
To: = Ashish Dalela (adalela)
Cc: sop@ietf.org; Michael = Hammer


Subject: Re: [sop] SOP = Requirements

 <= /o:p>

Hi = Ashish,

My point was very simple.

You had talked about = cases where protocol is more flexible than an API, and I was trying to = help you understand that anything that can be done in an East West = manner (with protocols), can be done in North-South manner with API's. = If you say we can do something with protocols with only X packets, we = can do the same with just X API's too. That was my point and not the = fact that we have only 1 API or more.

Also API's on which base = services sit and ones which end users use could be different.

Am = I missing the point = altogether?

Thanks,
Vishwas

On Wed, Feb = 29, 2012 at 6:51 PM, Ashish Dalela (adalela) <adalela@cisco.com> = wrote:

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


Subje= ct: Re: [sop] SOP = Requirements

 <= /o:p>

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>

 <= /o:p>

 <= /o:p>

 

------_=_NextPart_001_01CCFB9C.7C8155F5-- From vishwas.ietf@gmail.com Mon Mar 12 17:12: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 6449721E80CB for ; Mon, 12 Mar 2012 17:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.93 X-Spam-Level: X-Spam-Status: No, score=-3.93 tagged_above=-999 required=5 tests=[AWL=-0.332, 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 Rpsn+a0EJGkk for ; Mon, 12 Mar 2012 17:12:54 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 29C6C21E802A for ; Mon, 12 Mar 2012 17:12:54 -0700 (PDT) Received: by yenm5 with SMTP id m5so3635974yen.31 for ; Mon, 12 Mar 2012 17:12:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vGKhVZhR8n0orl0slPqjuS7q+rH7JPKtbTk0oAVAMNM=; b=yplwYL0qE31qWiotHGtZq8rcYUx2YrTNB6qwc/22r91m+bUAyS4RxyHF/EvQD6VG7f D5jRQDKKM57hPrYQKBXZ/ZyZV/F0w9PjZTAWydiSNuWpHdpr4kyDgO39YtoEHdALoVAn TXVpFwbRnXE1jaOO171rZOwZ9kuKYVY8sw2hq8mPvNJw6FeFUEi5DVFkmHzEIeCp2uBK 5sBGj6vH01XHCFPRCi5sBENIt6UqbfVySBQrBWXzA7rKFKLAb/y10+BfWqFCn8qffUsP UTG+KcYx+Vd67j6oHZEblAAXj/J/flWU3O+Ye+TOh8ZMoKcy8sbFIuHAW7UHdBE3VJd/ hztw== MIME-Version: 1.0 Received: by 10.182.1.104 with SMTP id 8mr9802538obl.19.1331597573721; Mon, 12 Mar 2012 17:12:53 -0700 (PDT) Received: by 10.182.134.73 with HTTP; Mon, 12 Mar 2012 17:12:53 -0700 (PDT) In-Reply-To: <618BE8B40039924EB9AED233D4A09C51031BCFC2@XMB-BGL-416.cisco.com> References: <618BE8B40039924EB9AED233D4A09C51030E1263@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BC437@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BC9CC@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BCFC2@XMB-BGL-416.cisco.com> Date: Mon, 12 Mar 2012 17:12:53 -0700 Message-ID: From: Vishwas Manral To: "Ashish Dalela (adalela)" Content-Type: multipart/alternative; boundary=f46d044631665d8f0904bb14b84b 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: Tue, 13 Mar 2012 00:12:57 -0000 --f46d044631665d8f0904bb14b84b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ashish, Yes, I was talking about UPnP/ SSDP. For hijacking prevention, we used a protocol like IKE called AKE (though I am sure we could use IKE too). I am not trying to say the protocol you invented is wrong, but based on the top level information, it looks similar to what is achievable now. So if the problem is multicast for discovery, can we optimize the discovery part instead of doing the whole protocol itself. I think we need to propose a tighter problem statement. Thanks, Vishwas On Tue, Mar 6, 2012 at 5:24 AM, Ashish Dalela (adalela) wrote: > Hi Vishwas,**** > > ** ** > > I=92m supposing that you are talking about SSDP ( > http://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol)? Let me > know if that is correct.**** > > ** ** > > In any large network, multicast isn=92t the right way to scale. If every > network element has to do a IGMP join to receive ADVERTISE then it become= s > a scaling issue. It also becomes a security problem where some rogue > element can start sending multicast ADVERTISE and hijack the orchestratio= n > sessions. **** > > ** ** > > Broadcast doesn=92t scale either, but we can convert it to a directed > unicast (like DHCP for example). There are other reasons as well, such as > if there are multiple service specific controllers then you have to choos= e > different multicast groups for each. It seems like we should use broadcas= t > for this to be light-weight, and multicast could be an option in case of = L3 > networks, but with additional access controls.**** > > ** ** > > Regarding which existing protocol to extend, there are multiple options:*= * > ** > > ** ** > > HTTP =96 has CRUD, but doesn=92t support ADVERTISE, DISCOVER, REGISTER, > NOTIFY, SUBSCRIBE, COMMIT, CANCEL etc. So, just adding a NOTIFY, as you > suggest through SSDP, is still not going to be enough. Orchestration also > needs =93identities=94 such as device@provider.com, which HTTP doesn=92t = have.** > ** > > ** ** > > XMPP =96 has PUBLISH, SUBSCRIBE, and identities, but not all of the above= . > Service requests will require a =93VIA=94 and dynamic injection of path > elements, especially when a request forks into multiple requests or is > re-directed to a different provider / location.**** > > **** > > AMQP =96 this is designed for messaging and again lacks many of the > constructs.**** > > > **** > > So wherever we look, the extension curve is long. It seemed like the > problem space is big enough to warrant a new protocol.**** > > **** > > The other issue is how easily we can implement the security for > orchestration. E.g. if we use IPSec end-to-end then how do hops in the > middle route the request differently (the nearest location, the cheapest > location, location with capacity, the location allowed by law, etc.). The > right model seems to be that we embed integrity within the protocol rathe= r > than into IPSec. Privacy can be implemented separately between the edges > using IPSec. That security model requires another set of issues to be > solved in the current protocols (if we extend them).**** > > ** ** > > Besides security, there are other types of issues. For instance, a networ= k > might use UDP internally to get broadcast but use TCP for unicast > externally for higher reliability. That change between TCP and UDP causes > loss of transaction identity, and transactions have to be built part of t= he > protocol. Likewise, with overlays, and overlay translations, the location > information could be easily lost. Hence, you need location in the > orchestration protocol. NAT may obfuscate real topology, and we lose > information about the actual distance between two end-points. **** > > ** ** > > Given these challenges, we choose to define a protocol that can be tweake= d > over time for orchestration specific needs without having to worry about > backward compatibility, and/or how this gets broken by overlay, firewalls= , > or NAT=92d networks. SIP already went over this hump and providers have > learnt (somewhat painfully) on how to do this in a way that works. That > entire learning can be leveraged for cloud.**** > > **** > > In any case, not sure if you have seen it, but there is a draft for SOP > that describes just what I=92m talking about.**** > > ** ** > > http://tools.ietf.org/html/draft-dalela-sop-00**** > > http://tools.ietf.org/html/draft-dalela-sop-flows-00**** > > ** ** > > Look forward to your comments.**** > > **** > > Thanks, Ashish**** > > ** ** > > *From:* Vishwas Manral [mailto:vishwas.ietf@gmail.com] > *Sent:* Tuesday, March 06, 2012 2:30 AM > > *To:* Ashish Dalela (adalela) > *Cc:* sop@ietf.org; Michael Hammer > *Subject:* Re: [sop] SOP Requirements**** > > ** ** > > Hi Ashish, > > Thanks for the mail. > > So I looked at some of the reasons you mentioned you want to go in for SO= P > instead of HTTP. > > I however have worked in the past with the DLNA stack, where we extended > HTTP and used protocols like SOAP to get behaviors you mention - like > service discovery, transaction support etc. > > If that is what we want, we should look at the DLNA stack and see how we > can leverage existing mechanisms for the same. > > I however think finalizing the requirements is a good start. > > Thanks, > Vishwas**** > > On Fri, Mar 2, 2012 at 7:26 PM, Ashish Dalela (adalela) > wrote:**** > > Hi Vishwas,**** > > **** > > It is better if you comment on the drafts because there is a section > dedicated to this very topic.**** > > **** > > http://tools.ietf.org/html/draft-dalela-orchestration-00#section-8 **** > > **** > > This describes what you can=92t do with web-services (assuming that=92s w= hat > you mean by APIs). This is **not** the shortcoming of the APIs, but that > of the underlying **protocol** (HTTP). So, if you changed the underlying > protocol to fix issues with HTTP, then the APIs would be more powerful. > That protocol we propose to be SOP.**** > > **** > > You are mistaking me in pitching API against protocols. I=92m pitching > protocol (HTTP) against protocol (SOP). Unfortunately, application > developers abuse the term API to mean HTTP web-services, and the discussi= on > is then messed up into thinking protocol against API.**** > > **** > > Thanks, Ashish**** > > **** > > *From:* sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] *On Behalf Of = *Vishwas > Manral > *Sent:* Saturday, March 03, 2012 12:19 AM > *To:* Ashish Dalela (adalela) > *Cc:* sop@ietf.org; Michael Hammer**** > > > *Subject:* Re: [sop] SOP Requirements**** > > **** > > Hi Ashish, > > My point was very simple. > > You had talked about cases where protocol is more flexible than an API, > and I was trying to help you understand that anything that can be done in > an East West manner (with protocols), can be done in North-South manner > with API's. If you say we can do something with protocols with only X > packets, we can do the same with just X API's too. That was my point and > not the fact that we have only 1 API or more. > > Also API's on which base services sit and ones which end users use could > be different. > > Am I missing the point altogether? > > Thanks, > Vishwas**** > > On Wed, Feb 29, 2012 at 6:51 PM, Ashish Dalela (adalela) < > adalela@cisco.com> wrote:**** > > Hi Vishwas,**** > > **** > > What everyone calls API today uses a protocol =96 HTTP. APIs survive on t= he > interoperability provided by that protocol, and I don=92t think anyone ca= n > get away from that. The real question is =96 what is the right protocol o= n > top of which to build APIs? That=92s the question SOP is raising. Once yo= u do > that, then we can talk of one or many APIs.**** > > **** > > Limitations of using HTTP as the underlying protocol for any API have bee= n > described in detail in the requirements draft. I would like to hear your > comments on that. That section describes what APIs can=92t do. Some of th= e > limitations are because API is always unicast, and there are many things > for which you need a manycast and broadcast. Other limitations because AP= Is > are synchronous and you need to be asynchronous in some cases. Yet other > issues because APIs are single complete transaction, but some transaction= s > 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 t= he > protocol header saves you having to reinvent them in the content for ever= y > type of service. In other words, a protocol saves you from increasing > information across various services. As an example in SIP, we put From an= d > 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 AP= I > increases. And yes, you can make that backward compatible in terms of > implementation. But, nobody does that =96 especially when the interface i= s > end-user facing. If this was an acceptable design, then we would not have > object inheritance and there won=92t be hundreds of APIs being opened up = by > cloud providers today. You might want to suggest one API to Amazon or oth= er > cloud providers. **** > > **** > > A practical operational issue with APIs is that users don=92t understand = all > the details. A user understands a server memory and CPU, but don=92t > understand VLAN and LUN, and zillions of other complicated things. Exposi= ng > them through APIs is useless because they can=92t use it. Why would a use= r > buy an expensive TV when they can=92t use most of the features, because t= he > 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=92s not a prevention. Once you > recognize a problem, you build a short-term cure and a long-term preventi= on > (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=92s APIs works with anot= her > vendor=92s 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,**** > > **** > > 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 mad= e > 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**** > > **** > > **** > > **** > > **** > > ** ** > --f46d044631665d8f0904bb14b84b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ashish,

Yes, I was talking about UPnP/ SSDP. For hijacking preven= tion, we used a protocol like IKE called AKE (though I am sure we could use= IKE too).

I am not trying to say the protocol you invented is wrong= , but based on the top level information, it looks similar to what is achie= vable now.

So if the problem is multicast for discovery, can we optimize the disco= very part instead of doing the whole protocol itself. I think we need to pr= opose a tighter problem statement.

Thanks,
Vishwas

On Tue, Mar 6, 2012 at 5:24 AM, Ashish Dalela (adalela) &= lt;adalela@cisco.com> wr= ote:

Hi = Vishwas,

=A0

I=92m supposing that you are talking about SSDP (http:/= /en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol)? Let me know = if that is correct.

=A0

In any large network, multicast isn=92t the= right way to scale. If every network element has to do a IGMP join to rece= ive ADVERTISE then it becomes a scaling issue. It also becomes a security p= roblem where some rogue element can start sending multicast ADVERTISE and h= ijack the orchestration sessions.

=A0

Broadcast doesn=92t scale either, but we ca= n convert it to a directed unicast (like DHCP for example). There are other= reasons as well, such as if there are multiple service specific controller= s then you have to choose different multicast groups for each. It seems lik= e we should use broadcast for this to be light-weight, and multicast could = be an option in case of L3 networks, but with additional access controls.

=A0

Regarding which existing protocol to extend= , there are multiple options:

=A0

HTTP =96 has CRUD, but doesn=92t support AD= VERTISE, DISCOVER, REGISTER, NOTIFY, SUBSCRIBE, COMMIT, CANCEL etc. So, jus= t adding a NOTIFY, as you suggest through SSDP, is still not going to be en= ough. Orchestration also needs =93identities=94 such as device@provider.com, which HTTP d= oesn=92t have.

=A0

XMPP =96 has PUBLISH, SUBSCRIBE, and identi= ties, but not all of the above. Service requests will require a =93VIA=94 a= nd dynamic injection of path elements, especially when a request forks into= multiple requests or is re-directed to a different provider / location.=

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

<= p class=3D"MsoNormal">AMQP =96 this is designed for messaging and again lacks many of the constr= ucts.

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

So wherever we look= , the extension curve is long. It seemed like the problem space is big enou= gh to warrant a new protocol.

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

The= other issue is how easily we can implement the security for orchestration.= E.g. if we use IPSec end-to-end then how do hops in the middle route the r= equest differently (the nearest location, the cheapest location, location w= ith capacity, the location allowed by law, etc.). The right model seems to = be that we embed integrity within the protocol rather than into IPSec. Priv= acy can be implemented separately between the edges using IPSec. That secur= ity model requires another set of issues to be solved in the current protoc= ols (if we extend them).

=A0

Besides security, there are other types of = issues. For instance, a network might use UDP internally to get broadcast b= ut use TCP for unicast externally for higher reliability. That change betwe= en TCP and UDP causes loss of transaction identity, and transactions have t= o be built part of the protocol. Likewise, with overlays, and overlay trans= lations, the location information could be easily lost. Hence, you need loc= ation in the orchestration protocol. NAT may obfuscate real topology, and w= e lose information about the actual distance between two end-points.

=A0

Given these challenges, we choose to define= a protocol that can be tweaked over time for orchestration specific needs = without having to worry about backward compatibility, and/or how this gets = broken by overlay, firewalls, or NAT=92d networks. SIP already went over th= is hump and providers have learnt (somewhat painfully) on how to do this in= a way that works. That entire learning can be leveraged for cloud.<= u>

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

<= p class=3D"MsoNormal">In any case, not sure if you have seen it, but there is a draft for SOP th= at describes just what I=92m talking about.

=A0

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

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

=A0

Look forward to your comments.

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

Thanks, Ashish<= u>

=A0<= /p>

From: Vishwas = Manral [mailto:= vishwas.ietf@gmail.com]
Sent: Tuesday, March 06, 2012 2:30 AM


To: Ashish Dalela (adalela)
Cc: sop@ietf.org; Michael Hammer
Subje= ct: Re: [sop] SOP Requirements

=A0=

Hi Ashish,=

Thanks for the mail.

So I looked at some of the reasons you = mentioned you want to go in for SOP instead of HTTP.

I however have worked in the past with the DLNA stack, where we extende= d HTTP and used protocols like SOAP to get behaviors you mention - like ser= vice discovery, transaction support etc.

If that is what we want, we= should look at the DLNA stack and see how we can leverage existing mechani= sms for the same.

I however think finalizing the requirements is a good start.

Tha= nks,
Vishwas

On Fri, Mar 2,= 2012 at 7:26 PM, Ashish Dalela (adalela) <adalela@cisco.com> wrote:

Hi Vishwas,

=A0<= /span>

It is better if you comme= nt on the drafts because there is a section dedicated to this very topic.

=A0<= /p>

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

=A0<= /p>

This describes what yo= u can=92t do with web-services (assuming that=92s what you mean by APIs). T= his is *not* the shortcoming of the APIs, but that of the underlying= *protocol* (HTTP). So, if you changed the underlying protocol to fi= x issues with HTTP, then the APIs would be more powerful. That protocol we = propose to be SOP.

=A0<= /p>

You are mistaking me i= n pitching API against protocols. I=92m pitching protocol (HTTP) against pr= otocol (SOP). Unfortunately, application developers abuse the term API to m= ean HTTP web-services, and the discussion is then messed up into thinking p= rotocol against API.

=A0<= /p>

Thanks, Ashish<= u>

=A0<= /p>

From: sop-bounces@ietf.org= [mailto:sop-boun= ces@ietf.org] On Behalf Of Vishwas Manral
Sent: Saturday, March 03, 2012 12:19 AM
To: Ashish Dalela = (adalela)
Cc: s= op@ietf.org; Michael Hammer


Subject: Re: [sop] SOP Requirements

=A0

Hi Ashish,

My point was very= simple.

You had talked about cases where protocol is more flexible than an API,= and I was trying to help you understand that anything that can be done in = an East West manner (with protocols), can be done in North-South manner wit= h API's. If you say we can do something with protocols with only X pack= ets, we can do the same with just X API's too. That was my point and no= t the fact that we have only 1 API or more.

Also API's on which base services sit and ones which end users use = could be different.

Am I missing the point altogether?

Thanks= ,
Vishwas

On Wed, Feb 29, 2= 012 at 6:51 PM, Ashish Dalela (adalela) <adalela@cisco.com> wrote:

Hi Vishwas,

=A0<= /span>

What everyone calls API t= oday uses a protocol =96 HTTP. APIs survive on the interoperability provide= d by that protocol, and I don=92t think anyone can get away from that. The = real question is =96 what is the right protocol on top of which to build AP= Is? That=92s the question SOP is raising. Once you do that, then we can tal= k of one or many APIs.

=A0<= /p>

Limitations of using H= TTP 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 s= ection describes what APIs can=92t do. Some of the limitations are because = API is always unicast, and there are many things for which you need a manyc= ast and broadcast. Other limitations because APIs are synchronous and you n= eed to be asynchronous in some cases. Yet other issues because APIs are sin= gle complete transaction, but some transactions will spread over multiple s= uch APIs.

=A0<= /p>

The total amount of in= formation in a message is unchanged whether you put it inside a protocol he= ader 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 ot= her 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 re= peating that for voice and video and chat content.

=A0<= /p>

To your point, you can= have a single API for doing anything. As the service evolves and complexit= y grows, the number of parameters to that API increases. And yes, you can m= ake that backward compatible in terms of implementation. But, nobody does t= hat =96 especially when the interface is end-user facing. If this was an ac= ceptable design, then we would not have object inheritance and there won=92= t be hundreds of APIs being opened up by cloud providers today. You might w= ant to suggest one API to Amazon or other cloud providers.

=A0<= /p>

A practical operationa= l issue with APIs is that users don=92t understand all the details. A user = understands a server memory and CPU, but don=92t understand VLAN and LUN, a= nd zillions of other complicated things. Exposing them through APIs is usel= ess because they can=92t use it. Why would a user buy an expensive TV when = they can=92t use most of the features, because the remote is too complicate= d? The need is to reduce complexity through automation, not expose it all t= o the user via APIs. In other words, you need a more sophisticated policy e= ngine not a sophisticated API system.

=A0<= /p>

For any problem there = is a cure and there is a prevention. Building API bridges is a cure to dive= rse APIs, it=92s not a prevention. Once you recognize a problem, you build = a short-term cure and a long-term prevention (at least ideally). Then, a si= ngle API is neither a cure nor prevention; its side-effects are so severe t= hat we might be living with the original problem as well. =

=A0<= /p>

APIs have always exist= ed and will continue to exist. The goal is to interoperate diverse APIs wit= hout a translation bridge. That happens all the time with network protocols= , when one vendor=92s APIs works with another vendor=92s APIs without a tra= nslation bridge. I think not having a bridge is always better than having a= bridge. Agree?

=A0<= /p>

Thanks, Ashish<= u>

=A0<= /p>

=A0

From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: Wednesday, February 29, 2012 10:45 PM
To: Ashish Dal= ela (adalela)
Cc: Michael Hammer; sop@ietf.org


Subject: Re: [sop] SOP Requirements

=A0

Hi Ashish,

=A0

As the number of services increas= e or the complexity in a given service grows, this becomes very hard. Assum= e there is a service with N tunable parameters. You need at least N APIs th= at modify these parameters individually. Then permutations 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 br= idges, it=92s just inviting more complexity. Another limitation is that whe= n APIs have semantic incompatibilities, it becomes even harder to interoper= ate (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 we= ll 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 oper= ational standpoint, every new API introduction requires software upgrades t= o the controllers. That eventually hinders the rate of service creation.

=A0

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

That won=92t happen= if we separate service-independent and service-dependent pieces. An exampl= e of that is SNMP. SNMP is device/service independent. MIB defines the spec= ific service/device. If you have a standard protocol to manage a device, th= en 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. <= /u>

=A0<= /p>

BTW, I=92m not advocat= ing SNMP here because SNMP has many shortcomings in terms of network discov= ery, capability discovery, advertisements, transactions, etc. But, we need = to keep in mind that API proliferation is inevitable as services proliferat= e. Protocol proliferation is not inevitable. Similar separation has been do= ne in the past in SIP/SDP, HTTP/HTML, SMTP/MIME. That separation allows any= one to send any content in email to anyone. Or download any web-page, or ha= ve any type of codec (voice or video) use the same protocol.<= u>

=A0<= /p>

If you compare the suc= cess and widespread use of above mentioned protocols the value of separatio= n between service-independent and service-dependent seems pretty convincing= .

=A0=

>> C= orrect but the draft seems to differ.

=A0<= /p>

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

=A0=

>> T= he requirement seems contradictory to what we agree. Similar for points bel= ow.

=A0<= /p>

The requirement = is really that services are portable across providers. I think it is fair t= o 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.

=A0<= /p>

Thanks, Ashish<= u>

=A0<= /p>

=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<= /p>

=A0

Hi Michael,

Sounds like we ag= ree on most of the things, though I see the draft contradicting what we agr= ee 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 ado= pted by most providers. From the little I know OpenStack based API's ma= y be the alternative way and companies have built bridging layers to inter-= operate between the same.

=A0

=A0

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 perh= aps 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 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" etc could be used. All I am s= aying is can we use standard terms here.

=A0

<= div>

We can settle on specific terms to use, just so = long as we keep the distinction between the entity (enterprise?) that provi= sions 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 = Service, the operator of the Proxy provisions it with a CREATE, but the use= r 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 orchestration about creating services (from th= e cloud providers perspective), or an instance of a service (for a particul= ar user)? I think it is the latter, but doesn't sound so from the defin= ition.

=A0

<= div>

Orchestration is about the on-demand provisionin= g of the compute/storage/network/XaaS in the cloud by the subscriber/custom= er. =A0Once provisioned, the service can provide services to the intended u= ser. =A0We are trying to be general here. =A0Need to keep provisioning and = operations distinct. =A0"Service" is occurring in levels.<= u>

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 instantiatio= ns of those services. =A0Either may be hierarchically named.<= /p>

Hmm.
=A0

=A0

5. Is Scenario -1 talking about all providers should= provide the same services? I guess not. I think the idea should be the sam= e 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 servic= es, as it seems from the requirement.

=A0

<= div>

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

Bu= t, if two providers offer the same service, it should not require a new cus= tomer 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 requ= irement seems contradictory to what we agree. Similar for points below.

Thanks,
Vishwas
=A0

=A0

<= p class=3D"MsoNormal"> 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.

=A0

<= div>

Agree, and we would like that to be true for mul= ti-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 sh= ould inter-operate with each other. That is a business decision. I think wh= at you mean here is that providers should have a clear interoperable means = should they wish to inter-operate.

=A0

<= div>

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-operatio= n for all models? I would have thought we are focusing on the IaaS alone.

=A0<= /p>

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 similar services to me. Ho= w are they different - vendor versus provider?

=A0

We were considering cases where multiple companies are involved in providin= g all the capabilities needed. =A0One involved coordination within an admin= istrative domain, while the other involves independent administrative domai= ns. =A0We didn't want to limit this to single company operations. =A0La= rge 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 the base services and allow fo= r extensible services on top. There could be so many variants of the SaaS o= r even PaaS I am not sure how you would make every service inter-operate.

=A0

<= div>

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

Here we are trying to provide structure that al= lows easy extension, substitution, and innovation at the more service-speci= fic granular levels.

=A0

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

=A0

<= div>

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 too and not just between clouds.<= /u>

=A0

<= div>

Agree. =A0Internal to a cloud and from the custo= mer to the cloud are the simple cases. =A0

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

=A0=

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

=A0

Pr= obably needs more discussion. =A0I see content as a specific scenario. =A0T= here you don't care which copy of data is accessed so long as you reach= it. =A0In other types of services, a lot more control over who accesses wh= at is needed.

=A0

14. For Service disco= very. 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

=A0

=

=A0

=

=A0

<= /div>

=A0


--f46d044631665d8f0904bb14b84b-- From adalela@cisco.com Mon Mar 12 22:45: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 999A121F88AB for ; Mon, 12 Mar 2012 22:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.808 X-Spam-Level: X-Spam-Status: No, score=-7.808 tagged_above=-999 required=5 tests=[AWL=2.790, 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 hcpYvE2sY+f6 for ; Mon, 12 Mar 2012 22:45:47 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id E0FD721F88AA for ; Mon, 12 Mar 2012 22:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=86321; q=dns/txt; s=iport; t=1331617544; x=1332827144; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=1Bniltk7nyXpxrNevNK8UP8LmL60Gt6l3x+8jJw+Sc4=; b=jeB6MOYkMuEcD3f0uywRrgxoSt8h66y1WGauQJgzGALdBJSM5uarAXxa N42Pz63hMINT+urm6NY/gmU5InX40Pj97PXYWTi4BfPrch+ma9I9/8SvD V84uW+yfnY3RP7px+JInABIj0Kjse8/hb/3akVTm4WDjIrDNM2Y34UFev 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIEADfeXk9Io8UY/2dsb2JhbAA6CYJFqh8BigOCCQEBAQMBAQEBDwEHAQERAz0BCxACAQgRAQMBAQsCBBABBgEGASAGHwMGCAEBBAsICBMEA4djBQudSgGfFIlEaQQEBQaFRmMEgl6FdIhIj12EeIJrgU0BBg X-IronPort-AV: E=Sophos;i="4.73,575,1325462400"; d="scan'208,217";a="7738203" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 13 Mar 2012 05:45: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 q2D5jfaH020280; Tue, 13 Mar 2012 05:45: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); Tue, 13 Mar 2012 11:15: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_01CD00DC.7B94C405" Date: Tue, 13 Mar 2012 11:15:11 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C510329FBF4@XMB-BGL-416.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sop] SOP Requirements Thread-Index: Ac0ArhENiHJL+ZEoREmx32BAEKBqKQALYn8w References: <618BE8B40039924EB9AED233D4A09C51030E1263@XMB-BGL-416.cisco.com><618BE8B40039924EB9AED233D4A09C51031BC437@XMB-BGL-416.cisco.com><618BE8B40039924EB9AED233D4A09C51031BC9CC@XMB-BGL-416.cisco.com><618BE8B40039924EB9AED233D4A09C51031BCFC2@XMB-BGL-416.cisco.com> From: "Ashish Dalela (adalela)" To: "Vishwas Manral" X-OriginalArrivalTime: 13 Mar 2012 05:45:23.0277 (UTC) FILETIME=[7BC29FD0:01CD00DC] 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: Tue, 13 Mar 2012 05:45:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD00DC.7B94C405 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Vishwas, =20 There are multiple problems. IKE is only key exchange. You can't use it to encrypt packets because it will break policy routing (described in my email). =20 The multicast / discovery problem can be solved by moving from TCP to UDP. That alone isn't enough because moving away from TCP means you lost transaction identity.=20 =20 Sometimes what seems like a solution brings some other problems, which also need to be solved. =20 If you want, we can draft up a list of enhancements needed to existing protocols. I'm open to enhancing existing protocols.=20 =20 Thanks, Ashish =20 From: sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] On Behalf Of Vishwas Manral Sent: Tuesday, March 13, 2012 5:43 AM To: Ashish Dalela (adalela) Cc: sop@ietf.org; Michael Hammer Subject: Re: [sop] SOP Requirements =20 Hi Ashish, Yes, I was talking about UPnP/ SSDP. For hijacking prevention, we used a protocol like IKE called AKE (though I am sure we could use IKE too). I am not trying to say the protocol you invented is wrong, but based on the top level information, it looks similar to what is achievable now. So if the problem is multicast for discovery, can we optimize the discovery part instead of doing the whole protocol itself. I think we need to propose a tighter problem statement. Thanks, Vishwas On Tue, Mar 6, 2012 at 5:24 AM, Ashish Dalela (adalela) wrote: Hi Vishwas, =20 I'm supposing that you are talking about SSDP (http://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol)? Let me know if that is correct. =20 In any large network, multicast isn't the right way to scale. If every network element has to do a IGMP join to receive ADVERTISE then it becomes a scaling issue. It also becomes a security problem where some rogue element can start sending multicast ADVERTISE and hijack the orchestration sessions.=20 =20 Broadcast doesn't scale either, but we can convert it to a directed unicast (like DHCP for example). There are other reasons as well, such as if there are multiple service specific controllers then you have to choose different multicast groups for each. It seems like we should use broadcast for this to be light-weight, and multicast could be an option in case of L3 networks, but with additional access controls. =20 Regarding which existing protocol to extend, there are multiple options: =20 HTTP - has CRUD, but doesn't support ADVERTISE, DISCOVER, REGISTER, NOTIFY, SUBSCRIBE, COMMIT, CANCEL etc. So, just adding a NOTIFY, as you suggest through SSDP, is still not going to be enough. Orchestration also needs "identities" such as device@provider.com, which HTTP doesn't have. =20 XMPP - has PUBLISH, SUBSCRIBE, and identities, but not all of the above. Service requests will require a "VIA" and dynamic injection of path elements, especially when a request forks into multiple requests or is re-directed to a different provider / location. =20 AMQP - this is designed for messaging and again lacks many of the constructs. =20 So wherever we look, the extension curve is long. It seemed like the problem space is big enough to warrant a new protocol. =20 The other issue is how easily we can implement the security for orchestration. E.g. if we use IPSec end-to-end then how do hops in the middle route the request differently (the nearest location, the cheapest location, location with capacity, the location allowed by law, etc.). The right model seems to be that we embed integrity within the protocol rather than into IPSec. Privacy can be implemented separately between the edges using IPSec. That security model requires another set of issues to be solved in the current protocols (if we extend them). =20 Besides security, there are other types of issues. For instance, a network might use UDP internally to get broadcast but use TCP for unicast externally for higher reliability. That change between TCP and UDP causes loss of transaction identity, and transactions have to be built part of the protocol. Likewise, with overlays, and overlay translations, the location information could be easily lost. Hence, you need location in the orchestration protocol. NAT may obfuscate real topology, and we lose information about the actual distance between two end-points.=20 =20 Given these challenges, we choose to define a protocol that can be tweaked over time for orchestration specific needs without having to worry about backward compatibility, and/or how this gets broken by overlay, firewalls, or NAT'd networks. SIP already went over this hump and providers have learnt (somewhat painfully) on how to do this in a way that works. That entire learning can be leveraged for cloud. =20 In any case, not sure if you have seen it, but there is a draft for SOP that describes just what I'm talking about. =20 http://tools.ietf.org/html/draft-dalela-sop-00 http://tools.ietf.org/html/draft-dalela-sop-flows-00 =20 Look forward to your comments. =20 Thanks, Ashish =20 From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]=20 Sent: Tuesday, March 06, 2012 2:30 AM To: Ashish Dalela (adalela) Cc: sop@ietf.org; Michael Hammer Subject: Re: [sop] SOP Requirements =20 Hi Ashish, Thanks for the mail. So I looked at some of the reasons you mentioned you want to go in for SOP instead of HTTP. I however have worked in the past with the DLNA stack, where we extended HTTP and used protocols like SOAP to get behaviors you mention - like service discovery, transaction support etc. If that is what we want, we should look at the DLNA stack and see how we can leverage existing mechanisms for the same.=20 I however think finalizing the requirements is a good start. Thanks, Vishwas On Fri, Mar 2, 2012 at 7:26 PM, Ashish Dalela (adalela) wrote: Hi Vishwas, =20 It is better if you comment on the drafts because there is a section dedicated to this very topic. =20 http://tools.ietf.org/html/draft-dalela-orchestration-00#section-8=20 =20 This describes what you can't do with web-services (assuming that's what you mean by APIs). This is *not* the shortcoming of the APIs, but that of the underlying *protocol* (HTTP). So, if you changed the underlying protocol to fix issues with HTTP, then the APIs would be more powerful. That protocol we propose to be SOP. =20 You are mistaking me in pitching API against protocols. I'm pitching protocol (HTTP) against protocol (SOP). Unfortunately, application developers abuse the term API to mean HTTP web-services, and the discussion is then messed up into thinking protocol against API. =20 Thanks, Ashish =20 From: sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] On Behalf Of Vishwas Manral Sent: Saturday, March 03, 2012 12:19 AM To: Ashish Dalela (adalela) Cc: sop@ietf.org; Michael Hammer Subject: Re: [sop] SOP Requirements =20 Hi Ashish, My point was very simple.=20 You had talked about cases where protocol is more flexible than an API, and I was trying to help you understand that anything that can be done in an East West manner (with protocols), can be done in North-South manner with API's. If you say we can do something with protocols with only X packets, we can do the same with just X API's too. That was my point and not the fact that we have only 1 API or more. Also API's on which base services sit and ones which end users use could be different. Am I missing the point altogether? Thanks, Vishwas On Wed, Feb 29, 2012 at 6:51 PM, Ashish Dalela (adalela) wrote: 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 =20 =20 =20 ------_=_NextPart_001_01CD00DC.7B94C405 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Vishwas,

 

There are multiple problems. IKE is only key exchange. You = can’t use it to encrypt packets because it will break policy = routing (described in my email).

 

The multicast / discovery problem can be solved by moving from TCP to = UDP. That alone isn’t enough because moving away from TCP means = you lost transaction identity.

 

Sometimes what seems like a solution brings some other problems, = which also need to be solved.

 

If you want, we can draft up a list of enhancements needed to = existing protocols. I’m open to enhancing existing protocols. =

 

Thanks, Ashish

 

From:= = sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] On Behalf Of = Vishwas Manral
Sent: Tuesday, March 13, 2012 5:43 = AM
To: Ashish Dalela (adalela)
Cc: sop@ietf.org; = Michael Hammer
Subject: Re: [sop] SOP = Requirements

 

Hi Ashish,

Yes, I was talking = about UPnP/ SSDP. For hijacking prevention, we used a protocol like IKE = called AKE (though I am sure we could use IKE too).

I am not = trying to say the protocol you invented is wrong, but based on the top = level information, it looks similar to what is achievable now.

So = if the problem is multicast for discovery, can we optimize the discovery = part instead of doing the whole protocol itself. I think we need to = propose a tighter problem = statement.

Thanks,
Vishwas

On Tue, Mar 6, 2012 at 5:24 AM, Ashish Dalela = (adalela) <adalela@cisco.com> = wrote:

Hi = Vishwas,

 

I’m = supposing that you are talking about SSDP (http://en.wikipedia.org/wiki/Simple_Service_Discovery_P= rotocol)? Let me know if that is correct.

 <= /p>

In any large network, = multicast isn’t the right way to scale. If every network element = has to do a IGMP join to receive ADVERTISE then it becomes a scaling = issue. It also becomes a security problem where some rogue element can = start sending multicast ADVERTISE and hijack the orchestration sessions. =

 <= /p>

Broadcast doesn’t = scale either, but we can convert it to a directed unicast (like DHCP for = example). There are other reasons as well, such as if there are multiple = service specific controllers then you have to choose different multicast = groups for each. It seems like we should use broadcast for this to be = light-weight, and multicast could be an option in case of L3 networks, = but with additional access controls.

 <= /p>

Regarding which existing = protocol to extend, there are multiple options:

 <= /p>

HTTP – has CRUD, = but doesn’t support ADVERTISE, DISCOVER, REGISTER, NOTIFY, = SUBSCRIBE, COMMIT, CANCEL etc. So, just adding a NOTIFY, as you suggest = through SSDP, is still not going to be enough. Orchestration also needs = “identities” such as device@provider.com, which HTTP doesn’t = have.

 <= /p>

XMPP – has = PUBLISH, SUBSCRIBE, and identities, but not all of the above. Service = requests will require a “VIA” and dynamic injection of path = elements, especially when a request forks into multiple requests or is = re-directed to a different provider / location.

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

AMQP – this is = designed for messaging and again lacks many of the = constructs.

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

So wherever we look, the = extension curve is long. It seemed like the problem space is big enough = to warrant a new protocol.

    &= nbsp;          =

The other issue is how = easily we can implement the security for orchestration. E.g. if we use = IPSec end-to-end then how do hops in the middle route the request = differently (the nearest location, the cheapest location, location with = capacity, the location allowed by law, etc.). The right model seems to = be that we embed integrity within the protocol rather than into IPSec. = Privacy can be implemented separately between the edges using IPSec. = That security model requires another set of issues to be solved in the = current protocols (if we extend them).

 <= /p>

Besides security, there = are other types of issues. For instance, a network might use UDP = internally to get broadcast but use TCP for unicast externally for = higher reliability. That change between TCP and UDP causes loss of = transaction identity, and transactions have to be built part of the = protocol. Likewise, with overlays, and overlay translations, the = location information could be easily lost. Hence, you need location in = the orchestration protocol. NAT may obfuscate real topology, and we lose = information about the actual distance between two end-points. =

 <= /p>

Given these challenges, = we choose to define a protocol that can be tweaked over time for = orchestration specific needs without having to worry about backward = compatibility, and/or how this gets broken by overlay, firewalls, or = NAT’d networks. SIP already went over this hump and providers have = learnt (somewhat painfully) on how to do this in a way that works. That = entire learning can be leveraged for cloud.

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

In any case, not sure if = you have seen it, but there is a draft for SOP that describes just what = I’m talking about.

 <= /p>

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

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

Thanks, = Ashish

 

From:= = Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: Tuesday, = March 06, 2012 2:30 AM


To: Ashish Dalela (adalela)
Cc: = sop@ietf.org; = Michael Hammer
Subject: Re: [sop] SOP = Requirements

 <= /o:p>

Hi = Ashish,

Thanks for the mail.

So I looked at some of the = reasons you mentioned you want to go in for SOP instead of = HTTP.

I however have worked in the past with the DLNA stack, = where we extended HTTP and used protocols like SOAP to get behaviors you = mention - like service discovery, transaction support etc.

If = that is what we want, we should look at the DLNA stack and see how we = can leverage existing mechanisms for the same.

I however think = finalizing the requirements is a good = start.

Thanks,
Vishwas

On Fri, Mar = 2, 2012 at 7:26 PM, Ashish Dalela (adalela) <adalela@cisco.com> = wrote:

Hi Vishwas,

 

It is better if you comment on the drafts because there is a section = dedicated to this very topic.

 

http://tools.ietf.org/html/draft-dalela-orchestration-0= 0#section-8

 

This describes what you can’t do with web-services (assuming = that’s what you mean by APIs). This is *not* the = shortcoming of the APIs, but that of the underlying *protocol* = (HTTP). So, if you changed the underlying protocol to fix issues with = HTTP, then the APIs would be more powerful. That protocol we propose to = be SOP.

 

You are mistaking me in pitching API against protocols. I’m = pitching protocol (HTTP) against protocol (SOP). Unfortunately, = application developers abuse the term API to mean HTTP web-services, and = the discussion is then messed up into thinking protocol against = API.

 

Thanks, Ashish

 

From:= = sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] On Behalf Of Vishwas = Manral
Sent: Saturday, March 03, 2012 12:19 AM
To: = Ashish Dalela (adalela)
Cc: sop@ietf.org; Michael = Hammer


Subje= ct: Re: [sop] SOP = Requirements

 <= /o:p>

Hi = Ashish,

My point was very simple.

You had talked about = cases where protocol is more flexible than an API, and I was trying to = help you understand that anything that can be done in an East West = manner (with protocols), can be done in North-South manner with API's. = If you say we can do something with protocols with only X packets, we = can do the same with just X API's too. That was my point and not the = fact that we have only 1 API or more.

Also API's on which base = services sit and ones which end users use could be different.

Am = I missing the point = altogether?

Thanks,
Vishwas

On Wed, Feb = 29, 2012 at 6:51 PM, Ashish Dalela (adalela) <adalela@cisco.com> = wrote:

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


Subje= ct: Re: [sop] SOP = Requirements

 <= /o:p>

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>

 <= /o:p>

 <= /o:p>

 <= /o:p>

 

------_=_NextPart_001_01CD00DC.7B94C405-- From mphmmr@gmail.com Tue Mar 13 06:15: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 CD69221F867E for ; Tue, 13 Mar 2012 06:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.493 X-Spam-Level: X-Spam-Status: No, score=-3.493 tagged_above=-999 required=5 tests=[AWL=0.105, 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 pNj9yqI89dSR for ; Tue, 13 Mar 2012 06:15:21 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A314A21F869A for ; Tue, 13 Mar 2012 06:15:20 -0700 (PDT) Received: by lagj5 with SMTP id j5so523477lag.31 for ; Tue, 13 Mar 2012 06:15:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KjbhqVcgQu+wZvmwixECKTybiIRNuRzeZs9m2qk44vk=; b=O78gcNUY2Y2NK6KQ8BBgZsDtvAPYG2kHMD7GIRz0ZmLqE6k/ot5UyIclVNcb8ziI0O LSyABnTVieXuIF/GXR63qwPzs94wJfAcjwIPx6B0PTyWfIyqddxhkcIXN8ypzXIrhx6w W6kuMPy0QdKFZuXyRk4LN4d0JAhAWnTVQheTAHNmAmEnpaxS/Rf4O3us3sF8XyhWII09 +cj3KcQnqj7BQqEf5DvyppmJWQzPK3XB3jc4oGfmtDWU6LRIJEuiplI8BpaegYCiRjnO +msSMLHczfy7eNxT+RSyJTWV4c1vvzHbR63bSnj5+EURlF5PTLhL/AVs0ZRzdx+yYMU5 wtHw== MIME-Version: 1.0 Received: by 10.112.40.163 with SMTP id y3mr6372145lbk.19.1331644515849; Tue, 13 Mar 2012 06:15:15 -0700 (PDT) Received: by 10.112.76.196 with HTTP; Tue, 13 Mar 2012 06:15:15 -0700 (PDT) In-Reply-To: <618BE8B40039924EB9AED233D4A09C510329FBF4@XMB-BGL-416.cisco.com> References: <618BE8B40039924EB9AED233D4A09C51030E1263@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BC437@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BC9CC@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BCFC2@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C510329FBF4@XMB-BGL-416.cisco.com> Date: Tue, 13 Mar 2012 09:15:15 -0400 Message-ID: From: Michael Hammer To: "Ashish Dalela (adalela)" Content-Type: multipart/alternative; boundary=e0cb4efe2be855986a04bb1fa661 Cc: Vishwas Manral , 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, 13 Mar 2012 13:15:25 -0000 --e0cb4efe2be855986a04bb1fa661 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable But, if you start with an existing protocol and add methods and tweaks for every problem, you may end up with SOP again in the end. :) Mike On Tue, Mar 13, 2012 at 1:45 AM, Ashish Dalela (adalela) wrote: > Vishwas,**** > > ** ** > > There are multiple problems. IKE is only key exchange. You can=92t use it= to > encrypt packets because it will break policy routing (described in my > email).**** > > ** ** > > The multicast / discovery problem can be solved by moving from TCP to UDP= . > That alone isn=92t enough because moving away from TCP means you lost > transaction identity. **** > > ** ** > > Sometimes what seems like a solution brings some other problems, which > also need to be solved.**** > > ** ** > > If you want, we can draft up a list of enhancements needed to existing > protocols. I=92m open to enhancing existing protocols. **** > > ** ** > > Thanks, Ashish**** > > ** ** > > *From:* sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] *On Behalf Of = *Vishwas > Manral > *Sent:* Tuesday, March 13, 2012 5:43 AM > > *To:* Ashish Dalela (adalela) > *Cc:* sop@ietf.org; Michael Hammer > *Subject:* Re: [sop] SOP Requirements**** > > ** ** > > Hi Ashish, > > Yes, I was talking about UPnP/ SSDP. For hijacking prevention, we used a > protocol like IKE called AKE (though I am sure we could use IKE too). > > I am not trying to say the protocol you invented is wrong, but based on > the top level information, it looks similar to what is achievable now. > > So if the problem is multicast for discovery, can we optimize the > discovery part instead of doing the whole protocol itself. I think we nee= d > to propose a tighter problem statement. > > Thanks, > Vishwas**** > > On Tue, Mar 6, 2012 at 5:24 AM, Ashish Dalela (adalela) > wrote:**** > > Hi Vishwas,**** > > **** > > I=92m supposing that you are talking about SSDP ( > http://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol)? Let me > know if that is correct.**** > > **** > > In any large network, multicast isn=92t the right way to scale. If every > network element has to do a IGMP join to receive ADVERTISE then it become= s > a scaling issue. It also becomes a security problem where some rogue > element can start sending multicast ADVERTISE and hijack the orchestratio= n > sessions. **** > > **** > > Broadcast doesn=92t scale either, but we can convert it to a directed > unicast (like DHCP for example). There are other reasons as well, such as > if there are multiple service specific controllers then you have to choos= e > different multicast groups for each. It seems like we should use broadcas= t > for this to be light-weight, and multicast could be an option in case of = L3 > networks, but with additional access controls.**** > > **** > > Regarding which existing protocol to extend, there are multiple options:*= * > ** > > **** > > HTTP =96 has CRUD, but doesn=92t support ADVERTISE, DISCOVER, REGISTER, > NOTIFY, SUBSCRIBE, COMMIT, CANCEL etc. So, just adding a NOTIFY, as you > suggest through SSDP, is still not going to be enough. Orchestration also > needs =93identities=94 such as device@provider.com, which HTTP doesn=92t = have.** > ** > > **** > > XMPP =96 has PUBLISH, SUBSCRIBE, and identities, but not all of the above= . > Service requests will require a =93VIA=94 and dynamic injection of path > elements, especially when a request forks into multiple requests or is > re-directed to a different provider / location.**** > > **** > > AMQP =96 this is designed for messaging and again lacks many of the > constructs.**** > > > **** > > So wherever we look, the extension curve is long. It seemed like the > problem space is big enough to warrant a new protocol.**** > > **** > > The other issue is how easily we can implement the security for > orchestration. E.g. if we use IPSec end-to-end then how do hops in the > middle route the request differently (the nearest location, the cheapest > location, location with capacity, the location allowed by law, etc.). The > right model seems to be that we embed integrity within the protocol rathe= r > than into IPSec. Privacy can be implemented separately between the edges > using IPSec. That security model requires another set of issues to be > solved in the current protocols (if we extend them).**** > > **** > > Besides security, there are other types of issues. For instance, a networ= k > might use UDP internally to get broadcast but use TCP for unicast > externally for higher reliability. That change between TCP and UDP causes > loss of transaction identity, and transactions have to be built part of t= he > protocol. Likewise, with overlays, and overlay translations, the location > information could be easily lost. Hence, you need location in the > orchestration protocol. NAT may obfuscate real topology, and we lose > information about the actual distance between two end-points. **** > > **** > > Given these challenges, we choose to define a protocol that can be tweake= d > over time for orchestration specific needs without having to worry about > backward compatibility, and/or how this gets broken by overlay, firewalls= , > or NAT=92d networks. SIP already went over this hump and providers have > learnt (somewhat painfully) on how to do this in a way that works. That > entire learning can be leveraged for cloud.**** > > **** > > In any case, not sure if you have seen it, but there is a draft for SOP > that describes just what I=92m talking about.**** > > **** > > http://tools.ietf.org/html/draft-dalela-sop-00**** > > http://tools.ietf.org/html/draft-dalela-sop-flows-00**** > > **** > > Look forward to your comments.**** > > **** > > Thanks, Ashish**** > > **** > > *From:* Vishwas Manral [mailto:vishwas.ietf@gmail.com] > *Sent:* Tuesday, March 06, 2012 2:30 AM**** > > > *To:* Ashish Dalela (adalela) > *Cc:* sop@ietf.org; Michael Hammer > *Subject:* Re: [sop] SOP Requirements**** > > **** > > Hi Ashish, > > Thanks for the mail. > > So I looked at some of the reasons you mentioned you want to go in for SO= P > instead of HTTP. > > I however have worked in the past with the DLNA stack, where we extended > HTTP and used protocols like SOAP to get behaviors you mention - like > service discovery, transaction support etc. > > If that is what we want, we should look at the DLNA stack and see how we > can leverage existing mechanisms for the same. > > I however think finalizing the requirements is a good start. > > Thanks, > Vishwas**** > > On Fri, Mar 2, 2012 at 7:26 PM, Ashish Dalela (adalela) > wrote:**** > > Hi Vishwas,**** > > **** > > It is better if you comment on the drafts because there is a section > dedicated to this very topic.**** > > **** > > http://tools.ietf.org/html/draft-dalela-orchestration-00#section-8 **** > > **** > > This describes what you can=92t do with web-services (assuming that=92s w= hat > you mean by APIs). This is **not** the shortcoming of the APIs, but that > of the underlying **protocol** (HTTP). So, if you changed the underlying > protocol to fix issues with HTTP, then the APIs would be more powerful. > That protocol we propose to be SOP.**** > > **** > > You are mistaking me in pitching API against protocols. I=92m pitching > protocol (HTTP) against protocol (SOP). Unfortunately, application > developers abuse the term API to mean HTTP web-services, and the discussi= on > is then messed up into thinking protocol against API.**** > > **** > > Thanks, Ashish**** > > **** > > *From:* sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] *On Behalf Of = *Vishwas > Manral > *Sent:* Saturday, March 03, 2012 12:19 AM > *To:* Ashish Dalela (adalela) > *Cc:* sop@ietf.org; Michael Hammer**** > > > *Subject:* Re: [sop] SOP Requirements**** > > **** > > Hi Ashish, > > My point was very simple. > > You had talked about cases where protocol is more flexible than an API, > and I was trying to help you understand that anything that can be done in > an East West manner (with protocols), can be done in North-South manner > with API's. If you say we can do something with protocols with only X > packets, we can do the same with just X API's too. That was my point and > not the fact that we have only 1 API or more. > > Also API's on which base services sit and ones which end users use could > be different. > > Am I missing the point altogether? > > Thanks, > Vishwas**** > > On Wed, Feb 29, 2012 at 6:51 PM, Ashish Dalela (adalela) < > adalela@cisco.com> wrote:**** > > Hi Vishwas,**** > > **** > > What everyone calls API today uses a protocol =96 HTTP. APIs survive on t= he > interoperability provided by that protocol, and I don=92t think anyone ca= n > get away from that. The real question is =96 what is the right protocol o= n > top of which to build APIs? That=92s the question SOP is raising. Once yo= u do > that, then we can talk of one or many APIs.**** > > **** > > Limitations of using HTTP as the underlying protocol for any API have bee= n > described in detail in the requirements draft. I would like to hear your > comments on that. That section describes what APIs can=92t do. Some of th= e > limitations are because API is always unicast, and there are many things > for which you need a manycast and broadcast. Other limitations because AP= Is > are synchronous and you need to be asynchronous in some cases. Yet other > issues because APIs are single complete transaction, but some transaction= s > 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 t= he > protocol header saves you having to reinvent them in the content for ever= y > type of service. In other words, a protocol saves you from increasing > information across various services. As an example in SIP, we put From an= d > 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 AP= I > increases. And yes, you can make that backward compatible in terms of > implementation. But, nobody does that =96 especially when the interface i= s > end-user facing. If this was an acceptable design, then we would not have > object inheritance and there won=92t be hundreds of APIs being opened up = by > cloud providers today. You might want to suggest one API to Amazon or oth= er > cloud providers. **** > > **** > > A practical operational issue with APIs is that users don=92t understand = all > the details. A user understands a server memory and CPU, but don=92t > understand VLAN and LUN, and zillions of other complicated things. Exposi= ng > them through APIs is useless because they can=92t use it. Why would a use= r > buy an expensive TV when they can=92t use most of the features, because t= he > 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=92s not a prevention. Once you > recognize a problem, you build a short-term cure and a long-term preventi= on > (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=92s APIs works with anot= her > vendor=92s 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,**** > > **** > > 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 mad= e > 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**** > > **** > > **** > > **** > > **** > > **** > > ** ** > --e0cb4efe2be855986a04bb1fa661 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable But, if you start with an existing protocol and add methods and tweaks for = every problem,=A0
you may end up with SOP again in the end. =A0:)
<= br>
Mike


On Tue, Mar= 13, 2012 at 1:45 AM, Ashish Dalela (adalela) <adalela@cisco.com> wrote:

Vishwas,

=A0<= /p>

There are multiple pro= blems. IKE is only key exchange. You can=92t use it to encrypt packets beca= use it will break policy routing (described in my email).

=A0<= /p>

The multicast / discov= ery problem can be solved by moving from TCP to UDP. That alone isn=92t eno= ugh because moving away from TCP means you lost transaction identity.

=A0<= /p>

Sometimes what seems l= ike a solution brings some other problems, which also need to be solved.=

=A0<= /p>

If you want, we can dr= aft up a list of enhancements needed to existing protocols. I=92m open to e= nhancing existing protocols.

=A0<= /p>

Thanks, Ashish<= u>

=A0<= /p>

From: sop-bounces@ietf.org= [mailto:sop-boun= ces@ietf.org] On Behalf Of Vishwas Manral
Sent: Tuesday, March 13, 2012 5:43 AM


To: Ashish Dalela (adalela)
Cc: sop@ietf.org; Michael Hammer
Subje= ct: Re: [sop] SOP Requirements

=A0=

Hi Ashish,=

Yes, I was talking about UPnP/ SSDP. For hijacking prevention, we u= sed a protocol like IKE called AKE (though I am sure we could use IKE too).=

I am not trying to say the protocol you invented is wrong, but based on= the top level information, it looks similar to what is achievable now.
=
So if the problem is multicast for discovery, can we optimize the disco= very part instead of doing the whole protocol itself. I think we need to pr= opose a tighter problem statement.

Thanks,
Vishwas

On Tue,= Mar 6, 2012 at 5:24 AM, Ashish Dalela (adalela) <adalela@cisco.com> wrote:=

Hi Vishwas,

=A0

I=92m supposing that you are talking about SSDP (http:/= /en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol)? Let me know = if that is correct.

=A0

In any large network, multicast isn=92t the= right way to scale. If every network element has to do a IGMP join to rece= ive ADVERTISE then it becomes a scaling issue. It also becomes a security p= roblem where some rogue element can start sending multicast ADVERTISE and h= ijack the orchestration sessions.

=A0

Broadcast doesn=92t scale either, but we ca= n convert it to a directed unicast (like DHCP for example). There are other= reasons as well, such as if there are multiple service specific controller= s then you have to choose different multicast groups for each. It seems lik= e we should use broadcast for this to be light-weight, and multicast could = be an option in case of L3 networks, but with additional access controls.

=A0

Regarding which existing protocol to extend= , there are multiple options:

=A0

HTTP =96 has CRUD, but doesn=92t support AD= VERTISE, DISCOVER, REGISTER, NOTIFY, SUBSCRIBE, COMMIT, CANCEL etc. So, jus= t adding a NOTIFY, as you suggest through SSDP, is still not going to be en= ough. Orchestration also needs =93identities=94 such as device@provider.com, which HTTP d= oesn=92t have.

=A0

XMPP =96 has PUBLISH, SUBSCRIBE, and identi= ties, but not all of the above. Service requests will require a =93VIA=94 a= nd dynamic injection of path elements, especially when a request forks into= multiple requests or is re-directed to a different provider / location.

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

<= p class=3D"MsoNormal">AMQP =96 this is designed for messaging and again lacks many of the constr= ucts.

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

So wherever we look= , the extension curve is long. It seemed like the problem space is big enou= gh to warrant a new protocol.

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

The= other issue is how easily we can implement the security for orchestration.= E.g. if we use IPSec end-to-end then how do hops in the middle route the r= equest differently (the nearest location, the cheapest location, location w= ith capacity, the location allowed by law, etc.). The right model seems to = be that we embed integrity within the protocol rather than into IPSec. Priv= acy can be implemented separately between the edges using IPSec. That secur= ity model requires another set of issues to be solved in the current protoc= ols (if we extend them).

=A0

Besides security, there are other types of = issues. For instance, a network might use UDP internally to get broadcast b= ut use TCP for unicast externally for higher reliability. That change betwe= en TCP and UDP causes loss of transaction identity, and transactions have t= o be built part of the protocol. Likewise, with overlays, and overlay trans= lations, the location information could be easily lost. Hence, you need loc= ation in the orchestration protocol. NAT may obfuscate real topology, and w= e lose information about the actual distance between two end-points.

=A0

Given these challenges, we choose to define= a protocol that can be tweaked over time for orchestration specific needs = without having to worry about backward compatibility, and/or how this gets = broken by overlay, firewalls, or NAT=92d networks. SIP already went over th= is hump and providers have learnt (somewhat painfully) on how to do this in= a way that works. That entire learning can be leveraged for cloud.<= u>

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

<= p class=3D"MsoNormal">In any case, not sure if you have seen it, but there is a draft for SOP th= at describes just what I=92m talking about.

=A0

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

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

=A0

Look forwa= rd to your comments.

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

Thanks, Ashish<= /span>

=A0<= /p>

From: Vishwas = Manral [mailto:= vishwas.ietf@gmail.com]
Sent: Tuesday, March 06, 2012 2:30 AM

<= div>


To: Ashish Dalela (adalela)
Cc:= sop@ietf.org; Mi= chael Hammer
Subject: Re: [sop] SOP Requirements

=A0

Hi Ashish,

Thanks for the mail.<= br>
So I looked at some of the reasons you mentioned you want to go in for SOP = instead of HTTP.

I however have worked in the past with the DLNA sta= ck, where we extended HTTP and used protocols like SOAP to get behaviors yo= u mention - like service discovery, transaction support etc.

If that is what we want, we should look at the DLNA stack and see how w= e can leverage existing mechanisms for the same.

I however think fi= nalizing the requirements is a good start.

Thanks,
Vishwas=

On Fri, Mar 2, 2012 at 7:26 PM, Ashish Dalela (= adalela) <adalela= @cisco.com> wrote:

Hi Vishwas,

=A0<= /p>

It is better if you co= mment on the drafts because there is a section dedicated to this very topic= .

=A0<= /p>

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

=A0<= /p>

This describes what yo= u can=92t do with web-services (assuming that=92s what you mean by APIs). T= his is *not* the shortcoming of the APIs, but that of the underlying= *protocol* (HTTP). So, if you changed the underlying protocol to fi= x issues with HTTP, then the APIs would be more powerful. That protocol we = propose to be SOP.

=A0<= /p>

You are mistaking me i= n pitching API against protocols. I=92m pitching protocol (HTTP) against pr= otocol (SOP). Unfortunately, application developers abuse the term API to m= ean HTTP web-services, and the discussion is then messed up into thinking p= rotocol against API.

=A0<= /p>

Thanks, Ashish<= u>

=A0<= /p>

From: sop-bounces@ietf.org= [mailto:sop-boun= ces@ietf.org] On Behalf Of Vishwas Manral
Sent: Saturday, March 03, 2012 12:19 AM
To: Ashish Dalela = (adalela)
Cc: s= op@ietf.org; Michael Hammer


Subject: Re: [sop] SOP Requirements

=A0

Hi Ashish,

My point was very= simple.

You had talked about cases where protocol is more flexible than an API,= and I was trying to help you understand that anything that can be done in = an East West manner (with protocols), can be done in North-South manner wit= h API's. If you say we can do something with protocols with only X pack= ets, we can do the same with just X API's too. That was my point and no= t the fact that we have only 1 API or more.

Also API's on which base services sit and ones which end users use = could be different.

Am I missing the point altogether?

Thanks= ,
Vishwas

On Wed, Feb 29, 2= 012 at 6:51 PM, Ashish Dalela (adalela) <adalela@cisco.com> wrote:

Hi Vishwas,

=A0<= /span>

What everyone calls API t= oday uses a protocol =96 HTTP. APIs survive on the interoperability provide= d by that protocol, and I don=92t think anyone can get away from that. The = real question is =96 what is the right protocol on top of which to build AP= Is? That=92s the question SOP is raising. Once you do that, then we can tal= k of one or many APIs.

=A0<= /p>

Limitations of using H= TTP 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 s= ection describes what APIs can=92t do. Some of the limitations are because = API is always unicast, and there are many things for which you need a manyc= ast and broadcast. Other limitations because APIs are synchronous and you n= eed to be asynchronous in some cases. Yet other issues because APIs are sin= gle complete transaction, but some transactions will spread over multiple s= uch APIs.

=A0<= /p>

The total amount of in= formation in a message is unchanged whether you put it inside a protocol he= ader 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 ot= her 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 re= peating that for voice and video and chat content.

=A0<= /p>

To your point, you can= have a single API for doing anything. As the service evolves and complexit= y grows, the number of parameters to that API increases. And yes, you can m= ake that backward compatible in terms of implementation. But, nobody does t= hat =96 especially when the interface is end-user facing. If this was an ac= ceptable design, then we would not have object inheritance and there won=92= t be hundreds of APIs being opened up by cloud providers today. You might w= ant to suggest one API to Amazon or other cloud providers.

=A0<= /p>

A practical operationa= l issue with APIs is that users don=92t understand all the details. A user = understands a server memory and CPU, but don=92t understand VLAN and LUN, a= nd zillions of other complicated things. Exposing them through APIs is usel= ess because they can=92t use it. Why would a user buy an expensive TV when = they can=92t use most of the features, because the remote is too complicate= d? The need is to reduce complexity through automation, not expose it all t= o the user via APIs. In other words, you need a more sophisticated policy e= ngine not a sophisticated API system.

=A0<= /p>

For any problem there = is a cure and there is a prevention. Building API bridges is a cure to dive= rse APIs, it=92s not a prevention. Once you recognize a problem, you build = a short-term cure and a long-term prevention (at least ideally). Then, a si= ngle API is neither a cure nor prevention; its side-effects are so severe t= hat we might be living with the original problem as well. =

=A0<= /p>

APIs have always exist= ed and will continue to exist. The goal is to interoperate diverse APIs wit= hout a translation bridge. That happens all the time with network protocols= , when one vendor=92s APIs works with another vendor=92s APIs without a tra= nslation bridge. I think not having a bridge is always better than having a= bridge. Agree?

=A0<= /p>

Thanks, Ashish<= u>

=A0<= /p>

=A0

From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: Wednesday, February 29, 2012 10:45 PM
To: Ashish Dal= ela (adalela)
Cc: Michael Hammer; sop@ietf.org


Subject: Re: [sop] SOP Requirements

=A0

Hi Ashish,

=A0

As the number of services increas= e or the complexity in a given service grows, this becomes very hard. Assum= e there is a service with N tunable parameters. You need at least N APIs th= at modify these parameters individually. Then permutations 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 br= idges, it=92s just inviting more complexity. Another limitation is that whe= n APIs have semantic incompatibilities, it becomes even harder to interoper= ate (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 we= ll 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 oper= ational standpoint, every new API introduction requires software upgrades t= o the controllers. That eventually hinders the rate of service creation.

=A0

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

That won=92t happen= if we separate service-independent and service-dependent pieces. An exampl= e of that is SNMP. SNMP is device/service independent. MIB defines the spec= ific service/device. If you have a standard protocol to manage a device, th= en 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. <= /u>

=A0<= /p>

BTW, I=92m not advocat= ing SNMP here because SNMP has many shortcomings in terms of network discov= ery, capability discovery, advertisements, transactions, etc. But, we need = to keep in mind that API proliferation is inevitable as services proliferat= e. Protocol proliferation is not inevitable. Similar separation has been do= ne in the past in SIP/SDP, HTTP/HTML, SMTP/MIME. That separation allows any= one to send any content in email to anyone. Or download any web-page, or ha= ve any type of codec (voice or video) use the same protocol.<= u>

=A0<= /p>

If you compare the suc= cess and widespread use of above mentioned protocols the value of separatio= n between service-independent and service-dependent seems pretty convincing= .

=A0=

>> C= orrect but the draft seems to differ.

=A0<= /p>

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

=A0=

>> T= he requirement seems contradictory to what we agree. Similar for points bel= ow.

=A0<= /p>

The requirement = is really that services are portable across providers. I think it is fair t= o 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.

=A0<= /p>

Thanks, Ashish<= u>

=A0<= /p>

=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<= /p>

=A0

Hi Michael,

Sounds like we ag= ree on most of the things, though I see the draft contradicting what we agr= ee 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 ado= pted by most providers. From the little I know OpenStack based API's ma= y be the alternative way and companies have built bridging layers to inter-= operate between the same.

=A0

=A0

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 perh= aps 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 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" etc could be used. All I am s= aying is can we use standard terms here.

=A0

<= div>

We can settle on specific terms to use, just so = long as we keep the distinction between the entity (enterprise?) that provi= sions 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 = Service, the operator of the Proxy provisions it with a CREATE, but the use= r 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 orchestration about creating services (from th= e cloud providers perspective), or an instance of a service (for a particul= ar user)? I think it is the latter, but doesn't sound so from the defin= ition.

=A0

<= div>

Orchestration is about the on-demand provisionin= g of the compute/storage/network/XaaS in the cloud by the subscriber/custom= er. =A0Once provisioned, the service can provide services to the intended u= ser. =A0We are trying to be general here. =A0Need to keep provisioning and = operations distinct. =A0"Service" is occurring in levels.<= u>

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 instantiatio= ns of those services. =A0Either may be hierarchically named.<= /p>

Hmm.
=A0

=A0

5. Is Scenario -1 talking about all providers should= provide the same services? I guess not. I think the idea should be the sam= e 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 servic= es, as it seems from the requirement.

=A0

<= div>

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

Bu= t, if two providers offer the same service, it should not require a new cus= tomer 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 requ= irement seems contradictory to what we agree. Similar for points below.

Thanks,
Vishwas
=A0

=A0

<= p class=3D"MsoNormal"> 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.

=A0

<= div>

Agree, and we would like that to be true for mul= ti-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 sh= ould inter-operate with each other. That is a business decision. I think wh= at you mean here is that providers should have a clear interoperable means = should they wish to inter-operate.

=A0

<= div>

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-operatio= n for all models? I would have thought we are focusing on the IaaS alone.

=A0<= /p>

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 similar services to me. Ho= w are they different - vendor versus provider?

=A0

We were considering cases where multiple companies are involved in providin= g all the capabilities needed. =A0One involved coordination within an admin= istrative domain, while the other involves independent administrative domai= ns. =A0We didn't want to limit this to single company operations. =A0La= rge 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 the base services and allow fo= r extensible services on top. There could be so many variants of the SaaS o= r even PaaS I am not sure how you would make every service inter-operate.

=A0

<= div>

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

Here we are trying to provide structure that al= lows easy extension, substitution, and innovation at the more service-speci= fic granular levels.

=A0

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

=A0

<= div>

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 too and not just between clouds.<= /u>

=A0

<= div>

Agree. =A0Internal to a cloud and from the custo= mer to the cloud are the simple cases. =A0

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

=A0=

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

=A0

Pr= obably needs more discussion. =A0I see content as a specific scenario. =A0T= here you don't care which copy of data is accessed so long as you reach= it. =A0In other types of services, a lot more control over who accesses wh= at is needed.

=A0

14. For Service disco= very. 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

=A0

=

=A0

=

=A0

<= /div>

=A0

=A0


--e0cb4efe2be855986a04bb1fa661-- From vishwas.ietf@gmail.com Wed Mar 14 15:06:54 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 AF5B811E8075 for ; Wed, 14 Mar 2012 15:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.921 X-Spam-Level: X-Spam-Status: No, score=-3.921 tagged_above=-999 required=5 tests=[AWL=-0.323, 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 BW3uU1rma6mG for ; Wed, 14 Mar 2012 15:06:51 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2C73921F8862 for ; Wed, 14 Mar 2012 15:06:43 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2693363ggm.31 for ; Wed, 14 Mar 2012 15:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y72CmHkkftszxGuksSUauH1MerfnPB1BPpiOiTesPKA=; b=Y6pUBpL6MA44cVUqUo3yzQuEBkXVgwRBFzwSdO40To+SfwZ4XDn0rG1X8tdKIXoSK+ /ZwSQctFdWDUuYjPY7O5tT8KlQjICp65G5+U4Vqks/idnNqPv62p1xzZIsS43aDVwDDU /HsdlB0K84Vt+nRI40fDZvEGzVlcrE41RFHBsPOpfh5MyijSvHkpx/VVN/fN3DGJWA/R jhU6a1FwXvGyxdIM4UCF944RSWS3xKb5VbNrcSou8GcMupC8SHHdYEfTznJepq6FTTao h1pXPb7ublghLcAEfaO7X1umnDkTZD16Wx9fshxpCPffDph69fcaj9bkakyrMDIX8zMK yqng== MIME-Version: 1.0 Received: by 10.60.7.7 with SMTP id f7mr5598966oea.19.1331762802193; Wed, 14 Mar 2012 15:06:42 -0700 (PDT) Received: by 10.182.134.73 with HTTP; Wed, 14 Mar 2012 15:06:42 -0700 (PDT) In-Reply-To: References: <618BE8B40039924EB9AED233D4A09C51030E1263@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BC437@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BC9CC@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BCFC2@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C510329FBF4@XMB-BGL-416.cisco.com> Date: Wed, 14 Mar 2012 15:06:42 -0700 Message-ID: From: Vishwas Manral To: Michael Hammer Content-Type: multipart/alternative; boundary=e89a8fb1f2fcbff6f404bb3b30ae Cc: sop@ietf.org, "Ashish Dalela \(adalela\)" 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, 14 Mar 2012 22:06:54 -0000 --e89a8fb1f2fcbff6f404bb3b30ae Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks Mike. I am just eager that we have a clear cut set of requirements and problem statement defined, before we go ahead and write a solution. Ashish, sure let us look at the options and see what makes sense. On the DTCP/IP front we have both an encryption as well as a control plane AKE, which serves the purpose for digital content. -Vishwas On Tue, Mar 13, 2012 at 6:15 AM, Michael Hammer wrote: > But, if you start with an existing protocol and add methods and tweaks fo= r > every problem, > you may end up with SOP again in the end. :) > > Mike > > > On Tue, Mar 13, 2012 at 1:45 AM, Ashish Dalela (adalela) < > adalela@cisco.com> wrote: > >> Vishwas,**** >> >> ** ** >> >> There are multiple problems. IKE is only key exchange. You can=92t use i= t >> to encrypt packets because it will break policy routing (described in my >> email).**** >> >> ** ** >> >> The multicast / discovery problem can be solved by moving from TCP to >> UDP. That alone isn=92t enough because moving away from TCP means you lo= st >> transaction identity. **** >> >> ** ** >> >> Sometimes what seems like a solution brings some other problems, which >> also need to be solved.**** >> >> ** ** >> >> If you want, we can draft up a list of enhancements needed to existing >> protocols. I=92m open to enhancing existing protocols. **** >> >> ** ** >> >> Thanks, Ashish**** >> >> ** ** >> >> *From:* sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] *On Behalf Of >> *Vishwas Manral >> *Sent:* Tuesday, March 13, 2012 5:43 AM >> >> *To:* Ashish Dalela (adalela) >> *Cc:* sop@ietf.org; Michael Hammer >> *Subject:* Re: [sop] SOP Requirements**** >> >> ** ** >> >> Hi Ashish, >> >> Yes, I was talking about UPnP/ SSDP. For hijacking prevention, we used a >> protocol like IKE called AKE (though I am sure we could use IKE too). >> >> I am not trying to say the protocol you invented is wrong, but based on >> the top level information, it looks similar to what is achievable now. >> >> So if the problem is multicast for discovery, can we optimize the >> discovery part instead of doing the whole protocol itself. I think we ne= ed >> to propose a tighter problem statement. >> >> Thanks, >> Vishwas**** >> >> On Tue, Mar 6, 2012 at 5:24 AM, Ashish Dalela (adalela) < >> adalela@cisco.com> wrote:**** >> >> Hi Vishwas,**** >> >> **** >> >> I=92m supposing that you are talking about SSDP ( >> http://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol)? Let me >> know if that is correct.**** >> >> **** >> >> In any large network, multicast isn=92t the right way to scale. If every >> network element has to do a IGMP join to receive ADVERTISE then it becom= es >> a scaling issue. It also becomes a security problem where some rogue >> element can start sending multicast ADVERTISE and hijack the orchestrati= on >> sessions. **** >> >> **** >> >> Broadcast doesn=92t scale either, but we can convert it to a directed >> unicast (like DHCP for example). There are other reasons as well, such a= s >> if there are multiple service specific controllers then you have to choo= se >> different multicast groups for each. It seems like we should use broadca= st >> for this to be light-weight, and multicast could be an option in case of= L3 >> networks, but with additional access controls.**** >> >> **** >> >> Regarding which existing protocol to extend, there are multiple options:= * >> *** >> >> **** >> >> HTTP =96 has CRUD, but doesn=92t support ADVERTISE, DISCOVER, REGISTER, >> NOTIFY, SUBSCRIBE, COMMIT, CANCEL etc. So, just adding a NOTIFY, as you >> suggest through SSDP, is still not going to be enough. Orchestration als= o >> needs =93identities=94 such as device@provider.com, which HTTP doesn=92t= have.* >> *** >> >> **** >> >> XMPP =96 has PUBLISH, SUBSCRIBE, and identities, but not all of the abov= e. >> Service requests will require a =93VIA=94 and dynamic injection of path >> elements, especially when a request forks into multiple requests or is >> re-directed to a different provider / location.**** >> >> **** >> >> AMQP =96 this is designed for messaging and again lacks many of the >> constructs.**** >> >> >> **** >> >> So wherever we look, the extension curve is long. It seemed like the >> problem space is big enough to warrant a new protocol.**** >> >> **** >> >> The other issue is how easily we can implement the security for >> orchestration. E.g. if we use IPSec end-to-end then how do hops in the >> middle route the request differently (the nearest location, the cheapest >> location, location with capacity, the location allowed by law, etc.). Th= e >> right model seems to be that we embed integrity within the protocol rath= er >> than into IPSec. Privacy can be implemented separately between the edges >> using IPSec. That security model requires another set of issues to be >> solved in the current protocols (if we extend them).**** >> >> **** >> >> Besides security, there are other types of issues. For instance, a >> network might use UDP internally to get broadcast but use TCP for unicas= t >> externally for higher reliability. That change between TCP and UDP cause= s >> loss of transaction identity, and transactions have to be built part of = the >> protocol. Likewise, with overlays, and overlay translations, the locatio= n >> information could be easily lost. Hence, you need location in the >> orchestration protocol. NAT may obfuscate real topology, and we lose >> information about the actual distance between two end-points. **** >> >> **** >> >> Given these challenges, we choose to define a protocol that can be >> tweaked over time for orchestration specific needs without having to wor= ry >> about backward compatibility, and/or how this gets broken by overlay, >> firewalls, or NAT=92d networks. SIP already went over this hump and prov= iders >> have learnt (somewhat painfully) on how to do this in a way that works. >> That entire learning can be leveraged for cloud.**** >> >> **** >> >> In any case, not sure if you have seen it, but there is a draft for SOP >> that describes just what I=92m talking about.**** >> >> **** >> >> http://tools.ietf.org/html/draft-dalela-sop-00**** >> >> http://tools.ietf.org/html/draft-dalela-sop-flows-00**** >> >> **** >> >> Look forward to your comments.**** >> >> **** >> >> Thanks, Ashish**** >> >> **** >> >> *From:* Vishwas Manral [mailto:vishwas.ietf@gmail.com] >> *Sent:* Tuesday, March 06, 2012 2:30 AM**** >> >> >> *To:* Ashish Dalela (adalela) >> *Cc:* sop@ietf.org; Michael Hammer >> *Subject:* Re: [sop] SOP Requirements**** >> >> **** >> >> Hi Ashish, >> >> Thanks for the mail. >> >> So I looked at some of the reasons you mentioned you want to go in for >> SOP instead of HTTP. >> >> I however have worked in the past with the DLNA stack, where we extended >> HTTP and used protocols like SOAP to get behaviors you mention - like >> service discovery, transaction support etc. >> >> If that is what we want, we should look at the DLNA stack and see how we >> can leverage existing mechanisms for the same. >> >> I however think finalizing the requirements is a good start. >> >> Thanks, >> Vishwas**** >> >> On Fri, Mar 2, 2012 at 7:26 PM, Ashish Dalela (adalela) < >> adalela@cisco.com> wrote:**** >> >> Hi Vishwas,**** >> >> **** >> >> It is better if you comment on the drafts because there is a section >> dedicated to this very topic.**** >> >> **** >> >> http://tools.ietf.org/html/draft-dalela-orchestration-00#section-8 **** >> >> **** >> >> This describes what you can=92t do with web-services (assuming that=92s = what >> you mean by APIs). This is **not** the shortcoming of the APIs, but that >> of the underlying **protocol** (HTTP). So, if you changed the underlying >> protocol to fix issues with HTTP, then the APIs would be more powerful. >> That protocol we propose to be SOP.**** >> >> **** >> >> You are mistaking me in pitching API against protocols. I=92m pitching >> protocol (HTTP) against protocol (SOP). Unfortunately, application >> developers abuse the term API to mean HTTP web-services, and the discuss= ion >> is then messed up into thinking protocol against API.**** >> >> **** >> >> Thanks, Ashish**** >> >> **** >> >> *From:* sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] *On Behalf Of >> *Vishwas Manral >> *Sent:* Saturday, March 03, 2012 12:19 AM >> *To:* Ashish Dalela (adalela) >> *Cc:* sop@ietf.org; Michael Hammer**** >> >> >> *Subject:* Re: [sop] SOP Requirements**** >> >> **** >> >> Hi Ashish, >> >> My point was very simple. >> >> You had talked about cases where protocol is more flexible than an API, >> and I was trying to help you understand that anything that can be done i= n >> an East West manner (with protocols), can be done in North-South manner >> with API's. If you say we can do something with protocols with only X >> packets, we can do the same with just X API's too. That was my point and >> not the fact that we have only 1 API or more. >> >> Also API's on which base services sit and ones which end users use could >> be different. >> >> Am I missing the point altogether? >> >> Thanks, >> Vishwas**** >> >> On Wed, Feb 29, 2012 at 6:51 PM, Ashish Dalela (adalela) < >> adalela@cisco.com> wrote:**** >> >> Hi Vishwas,**** >> >> **** >> >> What everyone calls API today uses a protocol =96 HTTP. APIs survive on = the >> interoperability provided by that protocol, and I don=92t think anyone c= an >> get away from that. The real question is =96 what is the right protocol = on >> top of which to build APIs? That=92s the question SOP is raising. Once y= ou 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=92t 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 cas= es. >> 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 pu= t >> 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 eve= ry >> type of service. In other words, a protocol saves you from increasing >> information across various services. As an example in SIP, we put From a= nd >> To in the protocol header. Could we not put it in the body? Sure we coul= d. >> 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 A= PI >> increases. And yes, you can make that backward compatible in terms of >> implementation. But, nobody does that =96 especially when the interface = is >> end-user facing. If this was an acceptable design, then we would not hav= e >> object inheritance and there won=92t be hundreds of APIs being opened up= by >> cloud providers today. You might want to suggest one API to Amazon or ot= her >> cloud providers. **** >> >> **** >> >> A practical operational issue with APIs is that users don=92t understand >> all the details. A user understands a server memory and CPU, but don=92t >> understand VLAN and LUN, and zillions of other complicated things. Expos= ing >> them through APIs is useless because they can=92t use it. Why would a us= er >> buy an expensive TV when they can=92t 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=92s not a prevention. Once you >> recognize a problem, you build a short-term cure and a long-term prevent= ion >> (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=92s APIs works with ano= ther >> vendor=92s APIs without a translation bridge. I think not having a bridg= e 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,**** >> >> **** >> >> 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 crea= te >> hundreds of more APIs. That=92s just API bloat. And if you have to >> interoperate multiple instances of these APIs through bridges, it=92s ju= st >> inviting more complexity. Another limitation is that when APIs have >> semantic incompatibilities, it becomes even harder to interoperate (synt= ax >> 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 worke= d >> 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 a= n >> 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 o= f >> 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-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=92t need to upgrade all the >> intermediate systems =96 hardware or software. **** >> >> **** >> >> BTW, I=92m not advocating SNMP here because SNMP has many shortcomings i= n >> terms of network discovery, capability discovery, advertisements, >> transactions, etc. But, we need to keep in mind that API proliferation i= s >> 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 (vo= ice >> 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. I= s >> 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? Th= e >> AWS API's seem to be the default standard adopted by most providers. Fro= m >> 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 t= hat >> 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 laye= r >> 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 a= m >> 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 softwar= e >> 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 opera= tor >> of the Proxy provisions it with a CREATE, but the user is the one sendin= g >> 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 thi= nk >> 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. O= nce >> 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 servic= es >> 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 see= ms >> 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 ne= w >> 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 demarcati= on >> 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 wel= l. >> **** >> >> 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 t= hat >> 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 administrati= ve >> domains. We didn't want to limit this to single company operations. La= rge >> 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 Paa= S I >> am not sure how you would make every service inter-operate.**** >> >> **** >> >> There needs to be several layers of standards involved. This is an onio= n >> 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 level= s. >> **** >> >> **** >> >> 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 wors= t >> 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 reac= h >> it. In other types of services, a lot more control over who accesses wh= at >> is needed.**** >> >> **** >> >> 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**** >> >> **** >> >> Thanks, >> Vishwas >> >> _______________________________________________ >> sop mailing list >> sop@ietf.org >> https://www.ietf.org/mailman/listinfo/sop**** >> >> **** >> >> **** >> >> **** >> >> **** >> >> **** >> >> ** ** >> > > --e89a8fb1f2fcbff6f404bb3b30ae Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks Mike.

I am just eager that we have a clear cut set of require= ments and problem statement defined, before we go ahead and write a solutio= n.

Ashish, sure let us look at the options and see what makes sense.=

On the DTCP/IP front we have both an encryption as well as a control pl= ane AKE, which serves the purpose for digital content.

-Vishwas
<= br>
On Tue, Mar 13, 2012 at 6:15 AM, Michael Hamm= er <mphmmr@gmail.c= om> wrote:
But, if you start with an existing protocol = and add methods and tweaks for every problem,=A0
you may end up with SO= P again in the end. =A0:)

Mike


On Tue, Mar 13, 2012 at 1:45 AM, Ashish Dalela (adalela) <ada= lela@cisco.com> wrote:

Vishwas,

=A0<= /p>

There are multiple pro= blems. IKE is only key exchange. You can=92t use it to encrypt packets beca= use it will break policy routing (described in my email).

=A0<= /p>

The multicast / discov= ery problem can be solved by moving from TCP to UDP. That alone isn=92t eno= ugh because moving away from TCP means you lost transaction identity.

=A0<= /p>

Sometimes what seems l= ike a solution brings some other problems, which also need to be solved.=

=A0<= /p>

If you want, we can dr= aft up a list of enhancements needed to existing protocols. I=92m open to e= nhancing existing protocols.

=A0<= /p>

Thanks, Ashish<= u>

=A0<= /p>

From: sop-bounces@ietf.org= [mailto:sop-boun= ces@ietf.org] On Behalf Of Vishwas Manral
Sent: Tuesday, March 13, 2012 5:43 AM


To:= Ashish Dalela (adalela)
Cc: sop@ietf.org; Michael Hammer
Subject: Re: [= sop] SOP Requirements

=A0

Hi Ashish,

Yes, = I was talking about UPnP/ SSDP. For hijacking prevention, we used a protoco= l like IKE called AKE (though I am sure we could use IKE too).

I am not trying to say the protocol you invented is wrong, but based on= the top level information, it looks similar to what is achievable now.
=
So if the problem is multicast for discovery, can we optimize the disco= very part instead of doing the whole protocol itself. I think we need to pr= opose a tighter problem statement.

Thanks,
Vishwas

On Tue,= Mar 6, 2012 at 5:24 AM, Ashish Dalela (adalela) <adalela@cisco.com> wrote:=

Hi Vishwas,

=A0

I=92m supposing that you are talking about SSDP (http:/= /en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol)? Let me know = if that is correct.

=A0

In any large network, multicast isn=92t the= right way to scale. If every network element has to do a IGMP join to rece= ive ADVERTISE then it becomes a scaling issue. It also becomes a security p= roblem where some rogue element can start sending multicast ADVERTISE and h= ijack the orchestration sessions.

=A0

Broadcast doesn=92t scale either, but we ca= n convert it to a directed unicast (like DHCP for example). There are other= reasons as well, such as if there are multiple service specific controller= s then you have to choose different multicast groups for each. It seems lik= e we should use broadcast for this to be light-weight, and multicast could = be an option in case of L3 networks, but with additional access controls.

=A0

Regarding which existing protocol to extend= , there are multiple options:

=A0

HTTP =96 has CRUD, but doesn=92t support AD= VERTISE, DISCOVER, REGISTER, NOTIFY, SUBSCRIBE, COMMIT, CANCEL etc. So, jus= t adding a NOTIFY, as you suggest through SSDP, is still not going to be en= ough. Orchestration also needs =93identities=94 such as device@provider.com, which HTTP d= oesn=92t have.

=A0

XMPP =96 has PUBLISH, SUBSCRIBE, and identi= ties, but not all of the above. Service requests will require a =93VIA=94 a= nd dynamic injection of path elements, especially when a request forks into= multiple requests or is re-directed to a different provider / location.

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

<= p class=3D"MsoNormal">AMQP =96 this is designed for messaging and again lacks many of the constr= ucts.

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

So wherever we look= , the extension curve is long. It seemed like the problem space is big enou= gh to warrant a new protocol.

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

The= other issue is how easily we can implement the security for orchestration.= E.g. if we use IPSec end-to-end then how do hops in the middle route the r= equest differently (the nearest location, the cheapest location, location w= ith capacity, the location allowed by law, etc.). The right model seems to = be that we embed integrity within the protocol rather than into IPSec. Priv= acy can be implemented separately between the edges using IPSec. That secur= ity model requires another set of issues to be solved in the current protoc= ols (if we extend them).

=A0

Besides security, there are other types of = issues. For instance, a network might use UDP internally to get broadcast b= ut use TCP for unicast externally for higher reliability. That change betwe= en TCP and UDP causes loss of transaction identity, and transactions have t= o be built part of the protocol. Likewise, with overlays, and overlay trans= lations, the location information could be easily lost. Hence, you need loc= ation in the orchestration protocol. NAT may obfuscate real topology, and w= e lose information about the actual distance between two end-points.

=A0

Given these challenges, we choose to define= a protocol that can be tweaked over time for orchestration specific needs = without having to worry about backward compatibility, and/or how this gets = broken by overlay, firewalls, or NAT=92d networks. SIP already went over th= is hump and providers have learnt (somewhat painfully) on how to do this in= a way that works. That entire learning can be leveraged for cloud.<= u>

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

<= p class=3D"MsoNormal">In any case, not sure if you have seen it, but there is a draft for SOP th= at describes just what I=92m talking about.

=A0

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

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

=A0

Look forwa= rd to your comments.

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

Thanks, Ashish<= /span>

=A0<= /p>

From: Vishwas = Manral [mailto:= vishwas.ietf@gmail.com]
Sent: Tuesday, March 06, 2012 2:30 AM

<= div>


To: Ashish Dalela (adalela)
Cc:= sop@ietf.org; Mi= chael Hammer
Subject: Re: [sop] SOP Requirements

=A0

Hi Ashish,

Thanks for the mail.<= br>
So I looked at some of the reasons you mentioned you want to go in for SOP = instead of HTTP.

I however have worked in the past with the DLNA sta= ck, where we extended HTTP and used protocols like SOAP to get behaviors yo= u mention - like service discovery, transaction support etc.

If that is what we want, we should look at the DLNA stack and see how w= e can leverage existing mechanisms for the same.

I however think fi= nalizing the requirements is a good start.

Thanks,
Vishwas=

On Fri, Mar 2, 2012 at 7:26 PM, Ashish Dalela (= adalela) <adalela= @cisco.com> wrote:

Hi Vishwas,

=A0<= /p>

It is better if you co= mment on the drafts because there is a section dedicated to this very topic= .

=A0<= /p>

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

=A0<= /p>

This describes what yo= u can=92t do with web-services (assuming that=92s what you mean by APIs). T= his is *not* the shortcoming of the APIs, but that of the underlying= *protocol* (HTTP). So, if you changed the underlying protocol to fi= x issues with HTTP, then the APIs would be more powerful. That protocol we = propose to be SOP.

=A0<= /p>

You are mistaking me i= n pitching API against protocols. I=92m pitching protocol (HTTP) against pr= otocol (SOP). Unfortunately, application developers abuse the term API to m= ean HTTP web-services, and the discussion is then messed up into thinking p= rotocol against API.

=A0<= /p>

Thanks, Ashish<= u>

=A0<= /p>

From: sop-bounces@ietf.org= [mailto:sop-boun= ces@ietf.org] On Behalf Of Vishwas Manral
Sent: Saturday, March 03, 2012 12:19 AM
To: Ashish Dalela = (adalela)
Cc: s= op@ietf.org; Michael Hammer


Subject: Re: [sop] SOP Requirements

=A0

Hi Ashish,

My point was very= simple.

You had talked about cases where protocol is more flexible than an API,= and I was trying to help you understand that anything that can be done in = an East West manner (with protocols), can be done in North-South manner wit= h API's. If you say we can do something with protocols with only X pack= ets, we can do the same with just X API's too. That was my point and no= t the fact that we have only 1 API or more.

Also API's on which base services sit and ones which end users use = could be different.

Am I missing the point altogether?

Thanks= ,
Vishwas

On Wed, Feb 29, 2= 012 at 6:51 PM, Ashish Dalela (adalela) <adalela@cisco.com> wrote:

Hi Vishwas,

=A0<= /span>

What everyone calls API t= oday uses a protocol =96 HTTP. APIs survive on the interoperability provide= d by that protocol, and I don=92t think anyone can get away from that. The = real question is =96 what is the right protocol on top of which to build AP= Is? That=92s the question SOP is raising. Once you do that, then we can tal= k of one or many APIs.

=A0<= /p>

Limitations of using H= TTP 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 s= ection describes what APIs can=92t do. Some of the limitations are because = API is always unicast, and there are many things for which you need a manyc= ast and broadcast. Other limitations because APIs are synchronous and you n= eed to be asynchronous in some cases. Yet other issues because APIs are sin= gle complete transaction, but some transactions will spread over multiple s= uch APIs.

=A0<= /p>

The total amount of in= formation in a message is unchanged whether you put it inside a protocol he= ader 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 ot= her 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 re= peating that for voice and video and chat content.

=A0<= /p>

To your point, you can= have a single API for doing anything. As the service evolves and complexit= y grows, the number of parameters to that API increases. And yes, you can m= ake that backward compatible in terms of implementation. But, nobody does t= hat =96 especially when the interface is end-user facing. If this was an ac= ceptable design, then we would not have object inheritance and there won=92= t be hundreds of APIs being opened up by cloud providers today. You might w= ant to suggest one API to Amazon or other cloud providers.

=A0<= /p>

A practical operationa= l issue with APIs is that users don=92t understand all the details. A user = understands a server memory and CPU, but don=92t understand VLAN and LUN, a= nd zillions of other complicated things. Exposing them through APIs is usel= ess because they can=92t use it. Why would a user buy an expensive TV when = they can=92t use most of the features, because the remote is too complicate= d? The need is to reduce complexity through automation, not expose it all t= o the user via APIs. In other words, you need a more sophisticated policy e= ngine not a sophisticated API system.

=A0<= /p>

For any problem there = is a cure and there is a prevention. Building API bridges is a cure to dive= rse APIs, it=92s not a prevention. Once you recognize a problem, you build = a short-term cure and a long-term prevention (at least ideally). Then, a si= ngle API is neither a cure nor prevention; its side-effects are so severe t= hat we might be living with the original problem as well. =

=A0<= /p>

APIs have always exist= ed and will continue to exist. The goal is to interoperate diverse APIs wit= hout a translation bridge. That happens all the time with network protocols= , when one vendor=92s APIs works with another vendor=92s APIs without a tra= nslation bridge. I think not having a bridge is always better than having a= bridge. Agree?

=A0<= /p>

Thanks, Ashish<= u>

=A0<= /p>

=A0

From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: Wednesday, February 29, 2012 10:45 PM
To: Ashish Dal= ela (adalela)
Cc: Michael Hammer; sop@ietf.org


Subject: Re: [sop] SOP Requirements

=A0

Hi Ashish,

=A0

As the number of services increas= e or the complexity in a given service grows, this becomes very hard. Assum= e there is a service with N tunable parameters. You need at least N APIs th= at modify these parameters individually. Then permutations 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 br= idges, it=92s just inviting more complexity. Another limitation is that whe= n APIs have semantic incompatibilities, it becomes even harder to interoper= ate (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 we= ll 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 oper= ational standpoint, every new API introduction requires software upgrades t= o the controllers. That eventually hinders the rate of service creation.

=A0

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

That won=92t happen= if we separate service-independent and service-dependent pieces. An exampl= e of that is SNMP. SNMP is device/service independent. MIB defines the spec= ific service/device. If you have a standard protocol to manage a device, th= en 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. <= /u>

=A0<= /p>

BTW, I=92m not advocat= ing SNMP here because SNMP has many shortcomings in terms of network discov= ery, capability discovery, advertisements, transactions, etc. But, we need = to keep in mind that API proliferation is inevitable as services proliferat= e. Protocol proliferation is not inevitable. Similar separation has been do= ne in the past in SIP/SDP, HTTP/HTML, SMTP/MIME. That separation allows any= one to send any content in email to anyone. Or download any web-page, or ha= ve any type of codec (voice or video) use the same protocol.<= u>

=A0<= /p>

If you compare the suc= cess and widespread use of above mentioned protocols the value of separatio= n between service-independent and service-dependent seems pretty convincing= .

=A0=

>> C= orrect but the draft seems to differ.

=A0<= /p>

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

=A0=

>> T= he requirement seems contradictory to what we agree. Similar for points bel= ow.

=A0<= /p>

The requirement = is really that services are portable across providers. I think it is fair t= o 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.

=A0<= /p>

Thanks, Ashish<= u>

=A0<= /p>

=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<= /p>

=A0

Hi Michael,

Sounds like we ag= ree on most of the things, though I see the draft contradicting what we agr= ee 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 ado= pted by most providers. From the little I know OpenStack based API's ma= y be the alternative way and companies have built bridging layers to inter-= operate between the same.

=A0

=A0

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 perh= aps 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 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" etc could be used. All I am s= aying is can we use standard terms here.

=A0

<= div>

We can settle on specific terms to use, just so = long as we keep the distinction between the entity (enterprise?) that provi= sions 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 = Service, the operator of the Proxy provisions it with a CREATE, but the use= r 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 orchestration about creating services (from th= e cloud providers perspective), or an instance of a service (for a particul= ar user)? I think it is the latter, but doesn't sound so from the defin= ition.

=A0

<= div>

Orchestration is about the on-demand provisionin= g of the compute/storage/network/XaaS in the cloud by the subscriber/custom= er. =A0Once provisioned, the service can provide services to the intended u= ser. =A0We are trying to be general here. =A0Need to keep provisioning and = operations distinct. =A0"Service" is occurring in levels.<= u>

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 instantiatio= ns of those services. =A0Either may be hierarchically named.<= /p>

Hmm.
=A0

=A0

5. Is Scenario -1 talking about all providers should= provide the same services? I guess not. I think the idea should be the sam= e 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 servic= es, as it seems from the requirement.

=A0

<= div>

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

Bu= t, if two providers offer the same service, it should not require a new cus= tomer 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 requ= irement seems contradictory to what we agree. Similar for points below.

Thanks,
Vishwas
=A0

=A0

<= p class=3D"MsoNormal"> 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.

=A0

<= div>

Agree, and we would like that to be true for mul= ti-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 sh= ould inter-operate with each other. That is a business decision. I think wh= at you mean here is that providers should have a clear interoperable means = should they wish to inter-operate.

=A0

<= div>

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-operatio= n for all models? I would have thought we are focusing on the IaaS alone.

=A0<= /p>

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 similar services to me. Ho= w are they different - vendor versus provider?

=A0

We were considering cases where multiple companies are involved in providin= g all the capabilities needed. =A0One involved coordination within an admin= istrative domain, while the other involves independent administrative domai= ns. =A0We didn't want to limit this to single company operations. =A0La= rge 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 the base services and allow fo= r extensible services on top. There could be so many variants of the SaaS o= r even PaaS I am not sure how you would make every service inter-operate.

=A0

<= div>

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

Here we are trying to provide structure that al= lows easy extension, substitution, and innovation at the more service-speci= fic granular levels.

=A0

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

=A0

<= div>

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 too and not just between clouds.<= /u>

=A0

<= div>

Agree. =A0Internal to a cloud and from the custo= mer to the cloud are the simple cases. =A0

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

=A0=

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

=A0

Pr= obably needs more discussion. =A0I see content as a specific scenario. =A0T= here you don't care which copy of data is accessed so long as you reach= it. =A0In other types of services, a lot more control over who accesses wh= at is needed.

=A0

14. For Service disco= very. 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

=A0

=

=A0

=

=A0

<= /div>

=A0

=A0



--e89a8fb1f2fcbff6f404bb3b30ae-- From adalela@cisco.com Wed Mar 14 18:55:00 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 A23D121F8681 for ; Wed, 14 Mar 2012 18:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.84 X-Spam-Level: X-Spam-Status: No, score=-7.84 tagged_above=-999 required=5 tests=[AWL=2.758, 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 qAatYoulJluN for ; Wed, 14 Mar 2012 18:54:47 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id AA4E421F8683 for ; Wed, 14 Mar 2012 18:54:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=96100; q=dns/txt; s=iport; t=1331776482; x=1332986082; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=enqjuSMVetpWOwwPLodG3xkEc0dZzV5CrHAwUj2/OBg=; b=UJvFRyUKjVOngPSKc0JdvbvRbwX9XgTWEn1LO1kRv80+GEp9+PGmIDpU Gz2JEmrziax2oKSYpZD1IvvazxDWtVrvDCUWsjhzipDhlamfDvEdfl3ij iwbRcDV9N/gYQZ8mgljM4x0BFSURMg6FrodaiOtcueuDTIueBECqDvyUW o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8EAKNLYU9Io8UY/2dsb2JhbAA6CYJFql8BihGCCQEBAQMBAQEBDwEHAQERAz0BCxACAQgRAQMBAQsCBBABBgEGASAGHwMGCAEBBAEKCAgTBAOHYwULmwifLYlKZwQEBQaFWGMEgl6Fd4hNj2KDEoFogm6BTQEG X-IronPort-AV: E=Sophos;i="4.73,587,1325462400"; d="scan'208,217";a="7892687" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 15 Mar 2012 01:54:38 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2F1sc2O027859; Thu, 15 Mar 2012 01:54:38 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, 15 Mar 2012 07:24:38 +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_01CD024E.9433C809" Date: Thu, 15 Mar 2012 07:24:34 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C51033839D0@XMB-BGL-416.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sop] SOP Requirements Thread-Index: Ac0CLsZ+OZ3sAbvJRT2iUUWPC/RotAAHZOuw References: <618BE8B40039924EB9AED233D4A09C51030E1263@XMB-BGL-416.cisco.com><618BE8B40039924EB9AED233D4A09C51031BC437@XMB-BGL-416.cisco.com><618BE8B40039924EB9AED233D4A09C51031BC9CC@XMB-BGL-416.cisco.com><618BE8B40039924EB9AED233D4A09C51031BCFC2@XMB-BGL-416.cisco.com><618BE8B40039924EB9AED233D4A09C510329FBF4@XMB-BGL-416.cisco.com> From: "Ashish Dalela (adalela)" To: "Vishwas Manral" , "Michael Hammer" X-OriginalArrivalTime: 15 Mar 2012 01:54:38.0505 (UTC) FILETIME=[94759190:01CD024E] 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: Thu, 15 Mar 2012 01:55:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD024E.9433C809 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Vishwas, =20 IETF works with specific problem statements, and we made the problem statement for cloud control plane w.r.t. HTTP, given that it is hugely deployed and used. There are other things that are far less deployed and used for a variety of reasons, so we did not add the problem statements w.r.t. those things. =20 There are two things we can do:=20 =20 1. Complete the problem statement with respect to HTTP (there are missing things - e.g. the need to separate identity and privacy, which are not addressed by TLS and HTTPS).=20 2. Add modified problem statements with respect to other HTTP enhancements or other protocols (XMPP ..). Will you be willing to write that section? =20 Once we have a complete list of problem statements from different reference points, it will become clear whether to enhance existing solutions or go for new solutions. W.r.t. existing solution enhancements, an additional problem to keep in mind is what happens when firewalls and NAT are used. Lots of solutions are designed to operate within the firewall. =20 Thanks, Ashish =20 =20 From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]=20 Sent: Thursday, March 15, 2012 3:37 AM To: Michael Hammer Cc: Ashish Dalela (adalela); sop@ietf.org Subject: Re: [sop] SOP Requirements =20 Thanks Mike. I am just eager that we have a clear cut set of requirements and problem statement defined, before we go ahead and write a solution. Ashish, sure let us look at the options and see what makes sense. On the DTCP/IP front we have both an encryption as well as a control plane AKE, which serves the purpose for digital content. -Vishwas On Tue, Mar 13, 2012 at 6:15 AM, Michael Hammer wrote: But, if you start with an existing protocol and add methods and tweaks for every problem,=20 you may end up with SOP again in the end. :) =20 Mike =20 On Tue, Mar 13, 2012 at 1:45 AM, Ashish Dalela (adalela) wrote: Vishwas, =20 There are multiple problems. IKE is only key exchange. You can't use it to encrypt packets because it will break policy routing (described in my email). =20 The multicast / discovery problem can be solved by moving from TCP to UDP. That alone isn't enough because moving away from TCP means you lost transaction identity.=20 =20 Sometimes what seems like a solution brings some other problems, which also need to be solved. =20 If you want, we can draft up a list of enhancements needed to existing protocols. I'm open to enhancing existing protocols.=20 =20 Thanks, Ashish =20 From: sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] On Behalf Of Vishwas Manral Sent: Tuesday, March 13, 2012 5:43 AM To: Ashish Dalela (adalela) Cc: sop@ietf.org; Michael Hammer Subject: Re: [sop] SOP Requirements =20 Hi Ashish, Yes, I was talking about UPnP/ SSDP. For hijacking prevention, we used a protocol like IKE called AKE (though I am sure we could use IKE too). I am not trying to say the protocol you invented is wrong, but based on the top level information, it looks similar to what is achievable now. So if the problem is multicast for discovery, can we optimize the discovery part instead of doing the whole protocol itself. I think we need to propose a tighter problem statement. Thanks, Vishwas On Tue, Mar 6, 2012 at 5:24 AM, Ashish Dalela (adalela) wrote: Hi Vishwas, =20 I'm supposing that you are talking about SSDP (http://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol)? Let me know if that is correct. =20 In any large network, multicast isn't the right way to scale. If every network element has to do a IGMP join to receive ADVERTISE then it becomes a scaling issue. It also becomes a security problem where some rogue element can start sending multicast ADVERTISE and hijack the orchestration sessions.=20 =20 Broadcast doesn't scale either, but we can convert it to a directed unicast (like DHCP for example). There are other reasons as well, such as if there are multiple service specific controllers then you have to choose different multicast groups for each. It seems like we should use broadcast for this to be light-weight, and multicast could be an option in case of L3 networks, but with additional access controls. =20 Regarding which existing protocol to extend, there are multiple options: =20 HTTP - has CRUD, but doesn't support ADVERTISE, DISCOVER, REGISTER, NOTIFY, SUBSCRIBE, COMMIT, CANCEL etc. So, just adding a NOTIFY, as you suggest through SSDP, is still not going to be enough. Orchestration also needs "identities" such as device@provider.com, which HTTP doesn't have. =20 XMPP - has PUBLISH, SUBSCRIBE, and identities, but not all of the above. Service requests will require a "VIA" and dynamic injection of path elements, especially when a request forks into multiple requests or is re-directed to a different provider / location. =20 AMQP - this is designed for messaging and again lacks many of the constructs. =20 So wherever we look, the extension curve is long. It seemed like the problem space is big enough to warrant a new protocol. =20 The other issue is how easily we can implement the security for orchestration. E.g. if we use IPSec end-to-end then how do hops in the middle route the request differently (the nearest location, the cheapest location, location with capacity, the location allowed by law, etc.). The right model seems to be that we embed integrity within the protocol rather than into IPSec. Privacy can be implemented separately between the edges using IPSec. That security model requires another set of issues to be solved in the current protocols (if we extend them). =20 Besides security, there are other types of issues. For instance, a network might use UDP internally to get broadcast but use TCP for unicast externally for higher reliability. That change between TCP and UDP causes loss of transaction identity, and transactions have to be built part of the protocol. Likewise, with overlays, and overlay translations, the location information could be easily lost. Hence, you need location in the orchestration protocol. NAT may obfuscate real topology, and we lose information about the actual distance between two end-points.=20 =20 Given these challenges, we choose to define a protocol that can be tweaked over time for orchestration specific needs without having to worry about backward compatibility, and/or how this gets broken by overlay, firewalls, or NAT'd networks. SIP already went over this hump and providers have learnt (somewhat painfully) on how to do this in a way that works. That entire learning can be leveraged for cloud. =20 In any case, not sure if you have seen it, but there is a draft for SOP that describes just what I'm talking about. =20 http://tools.ietf.org/html/draft-dalela-sop-00 http://tools.ietf.org/html/draft-dalela-sop-flows-00 =20 Look forward to your comments. =20 Thanks, Ashish =20 From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]=20 Sent: Tuesday, March 06, 2012 2:30 AM To: Ashish Dalela (adalela) Cc: sop@ietf.org; Michael Hammer Subject: Re: [sop] SOP Requirements =20 Hi Ashish, Thanks for the mail. So I looked at some of the reasons you mentioned you want to go in for SOP instead of HTTP. I however have worked in the past with the DLNA stack, where we extended HTTP and used protocols like SOAP to get behaviors you mention - like service discovery, transaction support etc. If that is what we want, we should look at the DLNA stack and see how we can leverage existing mechanisms for the same.=20 I however think finalizing the requirements is a good start. Thanks, Vishwas On Fri, Mar 2, 2012 at 7:26 PM, Ashish Dalela (adalela) wrote: Hi Vishwas, =20 It is better if you comment on the drafts because there is a section dedicated to this very topic. =20 http://tools.ietf.org/html/draft-dalela-orchestration-00#section-8=20 =20 This describes what you can't do with web-services (assuming that's what you mean by APIs). This is *not* the shortcoming of the APIs, but that of the underlying *protocol* (HTTP). So, if you changed the underlying protocol to fix issues with HTTP, then the APIs would be more powerful. That protocol we propose to be SOP. =20 You are mistaking me in pitching API against protocols. I'm pitching protocol (HTTP) against protocol (SOP). Unfortunately, application developers abuse the term API to mean HTTP web-services, and the discussion is then messed up into thinking protocol against API. =20 Thanks, Ashish =20 From: sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] On Behalf Of Vishwas Manral Sent: Saturday, March 03, 2012 12:19 AM To: Ashish Dalela (adalela) Cc: sop@ietf.org; Michael Hammer Subject: Re: [sop] SOP Requirements =20 Hi Ashish, My point was very simple.=20 You had talked about cases where protocol is more flexible than an API, and I was trying to help you understand that anything that can be done in an East West manner (with protocols), can be done in North-South manner with API's. If you say we can do something with protocols with only X packets, we can do the same with just X API's too. That was my point and not the fact that we have only 1 API or more. Also API's on which base services sit and ones which end users use could be different. Am I missing the point altogether? Thanks, Vishwas On Wed, Feb 29, 2012 at 6:51 PM, Ashish Dalela (adalela) wrote: 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 =20 =20 =20 =20 =20 ------_=_NextPart_001_01CD024E.9433C809 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Vishwas,

 

IETF works with specific problem statements, and we made the problem = statement for cloud control plane w.r.t. HTTP, given that it is hugely = deployed and used. There are other things that are far less deployed and = used for a variety of reasons, so we did not add the problem statements = w.r.t. those things.

 

There are two things we can do:

 

1.       = Complete the problem statement with respect to HTTP (there are = missing things – e.g. the need to separate identity and privacy, = which are not addressed by TLS and HTTPS).

2.       = Add modified problem statements with respect to other HTTP = enhancements or other protocols (XMPP ..). Will you be willing to write = that section?

 

Once we have a complete list of problem statements from different = reference points, it will become clear whether to enhance existing = solutions or go for new solutions. W.r.t. existing solution = enhancements, an additional problem to keep in mind is what happens when = firewalls and NAT are used. Lots of solutions are designed to operate = within the firewall.

 

Thanks, Ashish

 

 

From:= = Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: = Thursday, March 15, 2012 3:37 AM
To: Michael = Hammer
Cc: Ashish Dalela (adalela); = sop@ietf.org
Subject: Re: [sop] SOP = Requirements

 

Thanks Mike.

I am just eager that = we have a clear cut set of requirements and problem statement defined, = before we go ahead and write a solution.

Ashish, sure let us look = at the options and see what makes sense.

On the DTCP/IP front we = have both an encryption as well as a control plane AKE, which serves the = purpose for digital content.

-Vishwas

On Tue, Mar 13, 2012 at 6:15 AM, Michael Hammer <mphmmr@gmail.com> = wrote:

But, if you start with an = existing protocol and add methods and tweaks for every = problem, 

you may end up = with SOP again in the end.  :)

 

Mike

 

On Tue, Mar 13, 2012 at 1:45 AM, Ashish Dalela = (adalela) <adalela@cisco.com> = wrote:

Vishwas,

 

There are multiple problems. IKE is only key exchange. You = can’t use it to encrypt packets because it will break policy = routing (described in my email).

 

The multicast / discovery problem can be solved by moving from TCP to = UDP. That alone isn’t enough because moving away from TCP means = you lost transaction identity.

 

Sometimes what seems like a solution brings some other problems, = which also need to be solved.

 

If you want, we can draft up a list of enhancements needed to = existing protocols. I’m open to enhancing existing protocols. =

 

Thanks, Ashish

 

From:= = sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] On Behalf Of Vishwas = Manral
Sent: Tuesday, March 13, 2012 5:43 = AM


To: = Ashish Dalela (adalela)
Cc: sop@ietf.org; Michael Hammer
Subject: = Re: [sop] SOP Requirements

 <= /o:p>

Hi = Ashish,

Yes, I was talking about UPnP/ SSDP. For hijacking = prevention, we used a protocol like IKE called AKE (though I am sure we = could use IKE too).

I am not trying to say the protocol you = invented is wrong, but based on the top level information, it looks = similar to what is achievable now.

So if the problem is multicast = for discovery, can we optimize the discovery part instead of doing the = whole protocol itself. I think we need to propose a tighter problem = statement.

Thanks,
Vishwas

On Tue, Mar = 6, 2012 at 5:24 AM, Ashish Dalela (adalela) <adalela@cisco.com> = wrote:

Hi = Vishwas,

 

I’m = supposing that you are talking about SSDP (http://en.wikipedia.org/wiki/Simple_Service_Discovery_P= rotocol)? Let me know if that is correct.

 <= /p>

In any large network, = multicast isn’t the right way to scale. If every network element = has to do a IGMP join to receive ADVERTISE then it becomes a scaling = issue. It also becomes a security problem where some rogue element can = start sending multicast ADVERTISE and hijack the orchestration sessions. =

 <= /p>

Broadcast doesn’t = scale either, but we can convert it to a directed unicast (like DHCP for = example). There are other reasons as well, such as if there are multiple = service specific controllers then you have to choose different multicast = groups for each. It seems like we should use broadcast for this to be = light-weight, and multicast could be an option in case of L3 networks, = but with additional access controls.

 <= /p>

Regarding which existing = protocol to extend, there are multiple options:

 <= /p>

HTTP – has CRUD, = but doesn’t support ADVERTISE, DISCOVER, REGISTER, NOTIFY, = SUBSCRIBE, COMMIT, CANCEL etc. So, just adding a NOTIFY, as you suggest = through SSDP, is still not going to be enough. Orchestration also needs = “identities” such as device@provider.com, which HTTP doesn’t = have.

 <= /p>

XMPP – has = PUBLISH, SUBSCRIBE, and identities, but not all of the above. Service = requests will require a “VIA” and dynamic injection of path = elements, especially when a request forks into multiple requests or is = re-directed to a different provider / location.

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

AMQP – this is = designed for messaging and again lacks many of the = constructs.

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

So wherever we look, the = extension curve is long. It seemed like the problem space is big enough = to warrant a new protocol.

    &= nbsp;          =

The other issue is how = easily we can implement the security for orchestration. E.g. if we use = IPSec end-to-end then how do hops in the middle route the request = differently (the nearest location, the cheapest location, location with = capacity, the location allowed by law, etc.). The right model seems to = be that we embed integrity within the protocol rather than into IPSec. = Privacy can be implemented separately between the edges using IPSec. = That security model requires another set of issues to be solved in the = current protocols (if we extend them).

 <= /p>

Besides security, there = are other types of issues. For instance, a network might use UDP = internally to get broadcast but use TCP for unicast externally for = higher reliability. That change between TCP and UDP causes loss of = transaction identity, and transactions have to be built part of the = protocol. Likewise, with overlays, and overlay translations, the = location information could be easily lost. Hence, you need location in = the orchestration protocol. NAT may obfuscate real topology, and we lose = information about the actual distance between two end-points. =

 <= /p>

Given these challenges, = we choose to define a protocol that can be tweaked over time for = orchestration specific needs without having to worry about backward = compatibility, and/or how this gets broken by overlay, firewalls, or = NAT’d networks. SIP already went over this hump and providers have = learnt (somewhat painfully) on how to do this in a way that works. That = entire learning can be leveraged for cloud.

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

In any case, not sure if = you have seen it, but there is a draft for SOP that describes just what = I’m talking about.

 <= /p>

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

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

Thanks, = Ashish

 

From:= = Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: Tuesday, = March 06, 2012 2:30 AM


To: Ashish Dalela (adalela)
Cc: sop@ietf.org; Michael Hammer
Subject: = Re: [sop] SOP Requirements

 <= /o:p>

Hi = Ashish,

Thanks for the mail.

So I looked at some of the = reasons you mentioned you want to go in for SOP instead of = HTTP.

I however have worked in the past with the DLNA stack, = where we extended HTTP and used protocols like SOAP to get behaviors you = mention - like service discovery, transaction support etc.

If = that is what we want, we should look at the DLNA stack and see how we = can leverage existing mechanisms for the same.

I however think = finalizing the requirements is a good = start.

Thanks,
Vishwas

On Fri, Mar = 2, 2012 at 7:26 PM, Ashish Dalela (adalela) <adalela@cisco.com> = wrote:

Hi Vishwas,

 

It is better if you comment on the drafts because there is a section = dedicated to this very topic.

 

http://tools.ietf.org/html/draft-dalela-orchestration-0= 0#section-8

 

This describes what you can’t do with web-services (assuming = that’s what you mean by APIs). This is *not* the = shortcoming of the APIs, but that of the underlying *protocol* = (HTTP). So, if you changed the underlying protocol to fix issues with = HTTP, then the APIs would be more powerful. That protocol we propose to = be SOP.

 

You are mistaking me in pitching API against protocols. I’m = pitching protocol (HTTP) against protocol (SOP). Unfortunately, = application developers abuse the term API to mean HTTP web-services, and = the discussion is then messed up into thinking protocol against = API.

 

Thanks, Ashish

 

From:= = sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] On Behalf Of Vishwas = Manral
Sent: Saturday, March 03, 2012 12:19 AM
To: = Ashish Dalela (adalela)
Cc: sop@ietf.org; Michael = Hammer


Subje= ct: Re: [sop] SOP = Requirements

 <= /o:p>

Hi = Ashish,

My point was very simple.

You had talked about = cases where protocol is more flexible than an API, and I was trying to = help you understand that anything that can be done in an East West = manner (with protocols), can be done in North-South manner with API's. = If you say we can do something with protocols with only X packets, we = can do the same with just X API's too. That was my point and not the = fact that we have only 1 API or more.

Also API's on which base = services sit and ones which end users use could be different.

Am = I missing the point = altogether?

Thanks,
Vishwas

On Wed, Feb = 29, 2012 at 6:51 PM, Ashish Dalela (adalela) <adalela@cisco.com> = wrote:

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


Subje= ct: Re: [sop] SOP = Requirements

 <= /o:p>

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>

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

 

 

------_=_NextPart_001_01CD024E.9433C809-- From vishwas.ietf@gmail.com Wed Mar 14 21:44: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 AB66E21F8495 for ; Wed, 14 Mar 2012 21:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.912 X-Spam-Level: X-Spam-Status: No, score=-3.912 tagged_above=-999 required=5 tests=[AWL=-0.314, 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 FSaTdZrDUPPm for ; Wed, 14 Mar 2012 21:44:01 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA9E21F845C for ; Wed, 14 Mar 2012 21:44:00 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2993710ghb.31 for ; Wed, 14 Mar 2012 21:43:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ur6ksAFsvuCRfA/S6gdlPbiay8BSVokrf9qpeEjIk0Q=; b=0HOp03tt1usFuOdzqNwjrFjc3ck6KCwi9yvYfxUyyYtyNhnbv7LytEllpxOe+kYcbH u//RG9g5HrWGxPCx7Z1lwmQrT1rviwjEUQKva4ivWyU7UNDERRfHIb4h49kR+bx5JNY6 +zcbRFMRwe2IMKlUrY9cTqrpWRKSgATToAofxvX3p0R0cXtCvz2XPQXxqo3mHGW7AQ6H sZ4+1gGaAq4F7d3FS5M1M8KFek0u0O+Btm8QimNfz+yt9K9LxDIcJ4Qs7Liv1BIdpnpX S9r8VU5q2JqWJAFOm1mMvfRc5b7zZD7kpFNS5HQ0m7eOuY5zCshhYGFRCk2baTYB1McU FTfQ== MIME-Version: 1.0 Received: by 10.182.147.35 with SMTP id th3mr4425834obb.29.1331786639518; Wed, 14 Mar 2012 21:43:59 -0700 (PDT) Received: by 10.182.134.73 with HTTP; Wed, 14 Mar 2012 21:43:59 -0700 (PDT) In-Reply-To: <618BE8B40039924EB9AED233D4A09C51033839D0@XMB-BGL-416.cisco.com> References: <618BE8B40039924EB9AED233D4A09C51030E1263@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BC437@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BC9CC@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51031BCFC2@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C510329FBF4@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C51033839D0@XMB-BGL-416.cisco.com> Date: Wed, 14 Mar 2012 21:43:59 -0700 Message-ID: From: Vishwas Manral To: "Ashish Dalela (adalela)" Content-Type: multipart/alternative; boundary=f46d0444005490abe304bb40bdd8 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, 15 Mar 2012 04:44:06 -0000 --f46d0444005490abe304bb40bdd8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ashish, I think we are on the same page now. I agree we need the steps you define below. Thanks, Vishwas On Wed, Mar 14, 2012 at 6:54 PM, Ashish Dalela (adalela) wrote: > Vishwas,**** > > ** ** > > IETF works with specific problem statements, and we made the problem > statement for cloud control plane w.r.t. HTTP, given that it is hugely > deployed and used. There are other things that are far less deployed and > used for a variety of reasons, so we did not add the problem statements > w.r.t. those things.**** > > ** ** > > There are two things we can do: **** > > ** ** > > **1. **Complete the problem statement with respect to HTTP (there > are missing things =96 e.g. the need to separate identity and privacy, wh= ich > are not addressed by TLS and HTTPS). **** > > **2. **Add modified problem statements with respect to other HTTP > enhancements or other protocols (XMPP ..). Will you be willing to write > that section?**** > > ** ** > > Once we have a complete list of problem statements from different > reference points, it will become clear whether to enhance existing > solutions or go for new solutions. W.r.t. existing solution enhancements, > an additional problem to keep in mind is what happens when firewalls and > NAT are used. Lots of solutions are designed to operate within the firewa= ll. > **** > > ** ** > > Thanks, Ashish**** > > ** ** > > ** ** > > *From:* Vishwas Manral [mailto:vishwas.ietf@gmail.com] > *Sent:* Thursday, March 15, 2012 3:37 AM > *To:* Michael Hammer > *Cc:* Ashish Dalela (adalela); sop@ietf.org > > *Subject:* Re: [sop] SOP Requirements**** > > ** ** > > Thanks Mike. > > I am just eager that we have a clear cut set of requirements and problem > statement defined, before we go ahead and write a solution. > > Ashish, sure let us look at the options and see what makes sense. > > On the DTCP/IP front we have both an encryption as well as a control plan= e > AKE, which serves the purpose for digital content. > > -Vishwas**** > > On Tue, Mar 13, 2012 at 6:15 AM, Michael Hammer wrote:= * > *** > > But, if you start with an existing protocol and add methods and tweaks fo= r > every problem, **** > > you may end up with SOP again in the end. :)**** > > ** ** > > Mike**** > > ** ** > > On Tue, Mar 13, 2012 at 1:45 AM, Ashish Dalela (adalela) < > adalela@cisco.com> wrote:**** > > Vishwas,**** > > **** > > There are multiple problems. IKE is only key exchange. You can=92t use it= to > encrypt packets because it will break policy routing (described in my > email).**** > > **** > > The multicast / discovery problem can be solved by moving from TCP to UDP= . > That alone isn=92t enough because moving away from TCP means you lost > transaction identity. **** > > **** > > Sometimes what seems like a solution brings some other problems, which > also need to be solved.**** > > **** > > If you want, we can draft up a list of enhancements needed to existing > protocols. I=92m open to enhancing existing protocols. **** > > **** > > Thanks, Ashish**** > > **** > > *From:* sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] *On Behalf Of = *Vishwas > Manral > *Sent:* Tuesday, March 13, 2012 5:43 AM**** > > > *To:* Ashish Dalela (adalela) > *Cc:* sop@ietf.org; Michael Hammer > *Subject:* Re: [sop] SOP Requirements**** > > **** > > Hi Ashish, > > Yes, I was talking about UPnP/ SSDP. For hijacking prevention, we used a > protocol like IKE called AKE (though I am sure we could use IKE too). > > I am not trying to say the protocol you invented is wrong, but based on > the top level information, it looks similar to what is achievable now. > > So if the problem is multicast for discovery, can we optimize the > discovery part instead of doing the whole protocol itself. I think we nee= d > to propose a tighter problem statement. > > Thanks, > Vishwas**** > > On Tue, Mar 6, 2012 at 5:24 AM, Ashish Dalela (adalela) > wrote:**** > > Hi Vishwas,**** > > **** > > I=92m supposing that you are talking about SSDP ( > http://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol)? Let me > know if that is correct.**** > > **** > > In any large network, multicast isn=92t the right way to scale. If every > network element has to do a IGMP join to receive ADVERTISE then it become= s > a scaling issue. It also becomes a security problem where some rogue > element can start sending multicast ADVERTISE and hijack the orchestratio= n > sessions. **** > > **** > > Broadcast doesn=92t scale either, but we can convert it to a directed > unicast (like DHCP for example). There are other reasons as well, such as > if there are multiple service specific controllers then you have to choos= e > different multicast groups for each. It seems like we should use broadcas= t > for this to be light-weight, and multicast could be an option in case of = L3 > networks, but with additional access controls.**** > > **** > > Regarding which existing protocol to extend, there are multiple options:*= * > ** > > **** > > HTTP =96 has CRUD, but doesn=92t support ADVERTISE, DISCOVER, REGISTER, > NOTIFY, SUBSCRIBE, COMMIT, CANCEL etc. So, just adding a NOTIFY, as you > suggest through SSDP, is still not going to be enough. Orchestration also > needs =93identities=94 such as device@provider.com, which HTTP doesn=92t = have.** > ** > > **** > > XMPP =96 has PUBLISH, SUBSCRIBE, and identities, but not all of the above= . > Service requests will require a =93VIA=94 and dynamic injection of path > elements, especially when a request forks into multiple requests or is > re-directed to a different provider / location.**** > > **** > > AMQP =96 this is designed for messaging and again lacks many of the > constructs.**** > > > **** > > So wherever we look, the extension curve is long. It seemed like the > problem space is big enough to warrant a new protocol.**** > > **** > > The other issue is how easily we can implement the security for > orchestration. E.g. if we use IPSec end-to-end then how do hops in the > middle route the request differently (the nearest location, the cheapest > location, location with capacity, the location allowed by law, etc.). The > right model seems to be that we embed integrity within the protocol rathe= r > than into IPSec. Privacy can be implemented separately between the edges > using IPSec. That security model requires another set of issues to be > solved in the current protocols (if we extend them).**** > > **** > > Besides security, there are other types of issues. For instance, a networ= k > might use UDP internally to get broadcast but use TCP for unicast > externally for higher reliability. That change between TCP and UDP causes > loss of transaction identity, and transactions have to be built part of t= he > protocol. Likewise, with overlays, and overlay translations, the location > information could be easily lost. Hence, you need location in the > orchestration protocol. NAT may obfuscate real topology, and we lose > information about the actual distance between two end-points. **** > > **** > > Given these challenges, we choose to define a protocol that can be tweake= d > over time for orchestration specific needs without having to worry about > backward compatibility, and/or how this gets broken by overlay, firewalls= , > or NAT=92d networks. SIP already went over this hump and providers have > learnt (somewhat painfully) on how to do this in a way that works. That > entire learning can be leveraged for cloud.**** > > **** > > In any case, not sure if you have seen it, but there is a draft for SOP > that describes just what I=92m talking about.**** > > **** > > http://tools.ietf.org/html/draft-dalela-sop-00**** > > http://tools.ietf.org/html/draft-dalela-sop-flows-00**** > > **** > > Look forward to your comments.**** > > **** > > Thanks, Ashish**** > > **** > > *From:* Vishwas Manral [mailto:vishwas.ietf@gmail.com] > *Sent:* Tuesday, March 06, 2012 2:30 AM**** > > > *To:* Ashish Dalela (adalela) > *Cc:* sop@ietf.org; Michael Hammer > *Subject:* Re: [sop] SOP Requirements**** > > **** > > Hi Ashish, > > Thanks for the mail. > > So I looked at some of the reasons you mentioned you want to go in for SO= P > instead of HTTP. > > I however have worked in the past with the DLNA stack, where we extended > HTTP and used protocols like SOAP to get behaviors you mention - like > service discovery, transaction support etc. > > If that is what we want, we should look at the DLNA stack and see how we > can leverage existing mechanisms for the same. > > I however think finalizing the requirements is a good start. > > Thanks, > Vishwas**** > > On Fri, Mar 2, 2012 at 7:26 PM, Ashish Dalela (adalela) > wrote:**** > > Hi Vishwas,**** > > **** > > It is better if you comment on the drafts because there is a section > dedicated to this very topic.**** > > **** > > http://tools.ietf.org/html/draft-dalela-orchestration-00#section-8 **** > > **** > > This describes what you can=92t do with web-services (assuming that=92s w= hat > you mean by APIs). This is **not** the shortcoming of the APIs, but that > of the underlying **protocol** (HTTP). So, if you changed the underlying > protocol to fix issues with HTTP, then the APIs would be more powerful. > That protocol we propose to be SOP.**** > > **** > > You are mistaking me in pitching API against protocols. I=92m pitching > protocol (HTTP) against protocol (SOP). Unfortunately, application > developers abuse the term API to mean HTTP web-services, and the discussi= on > is then messed up into thinking protocol against API.**** > > **** > > Thanks, Ashish**** > > **** > > *From:* sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] *On Behalf Of = *Vishwas > Manral > *Sent:* Saturday, March 03, 2012 12:19 AM > *To:* Ashish Dalela (adalela) > *Cc:* sop@ietf.org; Michael Hammer**** > > > *Subject:* Re: [sop] SOP Requirements**** > > **** > > Hi Ashish, > > My point was very simple. > > You had talked about cases where protocol is more flexible than an API, > and I was trying to help you understand that anything that can be done in > an East West manner (with protocols), can be done in North-South manner > with API's. If you say we can do something with protocols with only X > packets, we can do the same with just X API's too. That was my point and > not the fact that we have only 1 API or more. > > Also API's on which base services sit and ones which end users use could > be different. > > Am I missing the point altogether? > > Thanks, > Vishwas**** > > On Wed, Feb 29, 2012 at 6:51 PM, Ashish Dalela (adalela) < > adalela@cisco.com> wrote:**** > > Hi Vishwas,**** > > **** > > What everyone calls API today uses a protocol =96 HTTP. APIs survive on t= he > interoperability provided by that protocol, and I don=92t think anyone ca= n > get away from that. The real question is =96 what is the right protocol o= n > top of which to build APIs? That=92s the question SOP is raising. Once yo= u do > that, then we can talk of one or many APIs.**** > > **** > > Limitations of using HTTP as the underlying protocol for any API have bee= n > described in detail in the requirements draft. I would like to hear your > comments on that. That section describes what APIs can=92t do. Some of th= e > limitations are because API is always unicast, and there are many things > for which you need a manycast and broadcast. Other limitations because AP= Is > are synchronous and you need to be asynchronous in some cases. Yet other > issues because APIs are single complete transaction, but some transaction= s > 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 t= he > protocol header saves you having to reinvent them in the content for ever= y > type of service. In other words, a protocol saves you from increasing > information across various services. As an example in SIP, we put From an= d > 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 AP= I > increases. And yes, you can make that backward compatible in terms of > implementation. But, nobody does that =96 especially when the interface i= s > end-user facing. If this was an acceptable design, then we would not have > object inheritance and there won=92t be hundreds of APIs being opened up = by > cloud providers today. You might want to suggest one API to Amazon or oth= er > cloud providers. **** > > **** > > A practical operational issue with APIs is that users don=92t understand = all > the details. A user understands a server memory and CPU, but don=92t > understand VLAN and LUN, and zillions of other complicated things. Exposi= ng > them through APIs is useless because they can=92t use it. Why would a use= r > buy an expensive TV when they can=92t use most of the features, because t= he > 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=92s not a prevention. Once you > recognize a problem, you build a short-term cure and a long-term preventi= on > (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=92s APIs works with anot= her > vendor=92s 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,**** > > **** > > 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 mad= e > 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**** > > **** > > **** > > **** > > **** > > **** > > **** > > ** ** > > ** ** > --f46d0444005490abe304bb40bdd8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ashish,

I think we are on the same page now. I agree we need the = steps you define below.

Thanks,
Vishwas

<= div>

Orchestration is about the on-demand provisionin= g of the compute/storage/network/XaaS in the cloud by the subscriber/custom= er. =A0Once provisioned, the service can provide services to the intended u= ser. =A0We are trying to be general here. =A0Need to keep provisioning and = operations distinct. =A0"Service" is occurring in levels.<= u>

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 instantiatio= ns of those services. =A0Either may be hierarchically named.<= /p>

Hmm.
=A0

=A0

5. Is Scenario -1 talking about all providers should= provide the same services? I guess not. I think the idea should be the sam= e 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 servic= es, as it seems from the requirement.

=A0

<= div>

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

Bu= t, if two providers offer the same service, it should not require a new cus= tomer 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 requ= irement seems contradictory to what we agree. Similar for points below.

Thanks,
Vishwas
=A0

=A0

<= p class=3D"MsoNormal"> 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.

=A0

<= div>

Agree, and we would like that to be true for mul= ti-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 sh= ould inter-operate with each other. That is a business decision. I think wh= at you mean here is that providers should have a clear interoperable means = should they wish to inter-operate.

=A0

<= div>

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-operatio= n for all models? I would have thought we are focusing on the IaaS alone.

=A0<= /p>

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 similar services to me. Ho= w are they different - vendor versus provider?

=A0

We were considering cases where multiple companies are involved in providin= g all the capabilities needed. =A0One involved coordination within an admin= istrative domain, while the other involves independent administrative domai= ns. =A0We didn't want to limit this to single company operations. =A0La= rge 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 the base services and allow fo= r extensible services on top. There could be so many variants of the SaaS o= r even PaaS I am not sure how you would make every service inter-operate.

=A0

<= div>

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

Here we are trying to provide structure that al= lows easy extension, substitution, and innovation at the more service-speci= fic granular levels.

=A0

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

=A0

<= div>

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 too and not just between clouds.<= /u>

=A0

<= div>

Agree. =A0Internal to a cloud and from the custo= mer to the cloud are the simple cases. =A0

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

=A0=

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

=A0

Pr= obably needs more discussion. =A0I see content as a specific scenario. =A0T= here you don't care which copy of data is accessed so long as you reach= it. =A0In other types of services, a lot more control over who accesses wh= at is needed.

=A0

14. For Service disco= very. 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

=A0

=

=A0

=

=A0

<= /div>

=A0

=A0

=A0

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


--f46d0444005490abe304bb40bdd8-- From adalela@cisco.com Tue Mar 20 00:24:48 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 B51D511E8076 for ; Tue, 20 Mar 2012 00:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.872 X-Spam-Level: X-Spam-Status: No, score=-7.872 tagged_above=-999 required=5 tests=[AWL=2.726, 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 WYAXDonSo1jb for ; Tue, 20 Mar 2012 00:24:47 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 74ADF21F8721 for ; Tue, 20 Mar 2012 00:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=20650; q=dns/txt; s=iport; t=1332228285; x=1333437885; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=UzfJzEIlOiVjV5pDvAHdgdHtglX6MrSXWoy5U4aZnY4=; b=UC5D3SbvVNSeDCkPBHTFOvnyZkPeGL3e1/nBuHNG2JV4OGUaU2LXWehv ko8NpXk3RYN4l0xhiqm7yW/xSPCcF3qKzG+GqBdY6Zi6uIp71fHMu+NEP eGKyeI7GygD13Qk8xA/U6MeAhi/fr8lXEfLFHZx6yOhyjorD380G7Vp8c o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAD8waE9Io8UY/2dsb2JhbABBgkaCeLASggiCCQEBAQMBEgEJBwoDSQULAgEIEQEDAQEBCgYXAQICAgEBHyUDBggBAQQBCggIGodjBZh2jQSSEYlQbwqFAjNjBIhUmDmDEYFogm6BTAEH X-IronPort-AV: E=Sophos;i="4.73,617,1325462400"; d="scan'208,217";a="8208666" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 20 Mar 2012 07:24:43 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2K7Oh58014339; Tue, 20 Mar 2012 07:24:43 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); Tue, 20 Mar 2012 12:54: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_01CD066A.85140BDB" Date: Tue, 20 Mar 2012 12:54:42 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C51033844D0@XMB-BGL-416.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sdnp] updated SDN problem statement draft Thread-Index: Ac0CE4i3DNIM8VxBScK8Y1oqgcOaNAEU38PQ References: <6448D413-BD2C-4774-88CC-030E58F1B6DD@lucidvision.com><4F5F5B26.6030303@kot-begemot.co.uk> From: "Ashish Dalela (adalela)" To: "Ping Pan" , "Tina TSOU" X-OriginalArrivalTime: 20 Mar 2012 07:24:43.0512 (UTC) FILETIME=[853A8F80:01CD066A] Cc: sdnp@lucidvision.com, sop@ietf.org Subject: Re: [sop] [Sdnp] updated SDN problem statement draft 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, 20 Mar 2012 07:24:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD066A.85140BDB Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 VGluYSwgDQoNCiANCg0KTGF0ZSByZXNwb25zZSwganVzdCBjYXRjaGluZyB1cCB3aXRoIGVtYWls IGJhY2tsb2cuIFRoZSBzaG9ydCBhbnN3ZXIgdG8geW91ciBxdWVzdGlvbiBpcyDigJx5ZXPigJ0u IFRoZSBsb25nIGFuc3dlciBpcyBiZWxvdy4NCg0KIA0KDQpTRE4gaW4gdGhlIE9ORiBzZW5zZSBp cyBuZXR3b3JraW5nIHNwZWNpZmljLiBJbiB0aGUgU0ROUCBkcmFmdHMsIEkgaGF2ZSBzZWVuIGNv bXB1dGUsIHN0b3JhZ2UgYW5kIHNlY3VyaXR5IGFsc28gbWVudGlvbmVkIGFzIHdpdGhpbiB0aGUg c2NvcGUgb2YgU0ROUC4gVGhhdCBtYWtlcyBtZSB0aGluayDigJMgaG93IGFyZSB3ZSBjcm9zc2lu ZyB0aGVzZSBkb21haW5zIHdoaWxlIHN0aWxsIGNhbGxpbmcgdGhpcyBTRE4/IEl0IGhhcyB0byBi ZSBhIHdpZGVyIGRlZmluaXRpb24gb2YgU0ROIHdoZXJlIFNETiBpcyBub3QgbGltaXRlZCB0byBu ZXR3b3JraW5nLg0KDQogDQoNClRoZSBvdGhlciBpc3N1ZSBpcyBpZiBTRE4gaXMgbGltaXRlZCB0 byBhIOKAnGRldmljZSBkcml2ZXLigJ0gbGV2ZWwgYWJzdHJhY3Rpb24gb2YgYSBkZXZpY2UgYXMg T0YgcG9ydHJheXMgaXQuIEl0IG1heSBub3QgYmUuIFdpdGhpbiBhIG5ldHdvcmtpbmcgZGV2aWNl LCB5b3UgY2FuIGFic3RyYWN0IGEgc3dpdGNoIGF0IHRoZSBsZXZlbCBvZiBkZXZpY2UgZHJpdmVy LCBSSUIsIHJvdXRpbmcgcHJvdG9jb2xzIG9yIG1nbXQgaW50ZXJmYWNlcy4gSW4gc29tZSBjYXNl cywgYWxsIG9mIHRoZXNlIG1heSBiZSBuZWVkZWQgY29uY3VycmVudGx5LiBJIHRoaW5rIGluIG1v c3QgcHJhY3RpY2FsIGNhc2VzIHlvdSBuZWVkIGFsbCBvZiB0aGVtLiBBbiBleGFtcGxlIG9mIHRo aXMgaXMgT0YtQ29uZmlnIHdoaWNoIGhhcyB0byBkZWZpbmUgYSByb3V0aW5nIGNvbmZpZ3VyYXRp b24gdXNpbmcgWE1MIHdoaWNoIGFic3RyYWN0cyBvbiBDTEkgZm9yIE9GIHBhY2tldHMgdG8gZXZl biByZWFjaCB0aGUgZGV2aWNlLiBTbywgeW91IGNhbuKAmXQgZ2V0IGF3YXkgd2l0aCBtdWx0aXBs ZSBsZXZlbHMgYW55d2F5Lg0KDQogDQoNCldoZW4geW91IHdhbnQgbXVsdGktZG9tYWluIGFuZCBt dWx0aS10aWVyIFNETiwgdGhlbiB5b3UgbmVlZCBzb21ldGhpbmcgbW9yZSBnZW5lcmljIHRoYW4g d2hhdCBPRiBpcyBnaXZpbmcgdG9kYXkuIE9uZSBvZiB0aGluZ3MgeW91IHdpbGwgZmluZCBpcyB0 aGUgbmVlZCB0byBzZXBhcmF0ZSB0aGUgdHJhbnNhY3Rpb24gcGllY2VzIGZyb20gdGhlIHNlcnZp Y2UgcGllY2VzLiBQZW9wbGUgb2Z0ZW4gc2F5IHRoYXQgd2UgY2FuIHRpZXIgc2VwYXJhdGUgZG9t YWluIGNvbnRyb2xsZXJzIGFuZCBpbnRlZ3JhdGUgdGhlbSBhdCBhIGhpZ2hlciBsZXZlbCBjb250 cm9sbGVyLiBJIGRvbuKAmXQgdGhpbmsgdGhhdCBpcyB0cml2aWFsLiBIb3cgZG8geW91IGludGVn cmF0ZSB0d28gZGlmZmVyZW50IGRvbWFpbnMsIHVubGVzcyB0aGV5IHNwZWFrIGluIHRoZSBzYW1l IGxhbmd1YWdlPyAgV2UgbmVlZCB0byBkcml2ZSBjb21tb24gYXBwcm9hY2hlcyB0byByZWR1Y2Ug Y29tcGxleGl0eS4NCg0KIA0KDQpXZSBkb27igJl0IHdhbnQgdG8gYmUgcmVwbGFjaW5nIHRoZSBo b3Jpem9udGFsIGNvbXBsZXhpdHkgd2l0aCBhIHZlcnRpY2FsIGNvbXBsZXhpdHkuIA0KDQogDQoN ClRoYW5rcywgQXNoaXNoDQoNCiANCg0KIA0KDQpGcm9tOiBzZG5wLWJvdW5jZXNAbHVjaWR2aXNp b24uY29tIFttYWlsdG86c2RucC1ib3VuY2VzQGx1Y2lkdmlzaW9uLmNvbV0gT24gQmVoYWxmIE9m IFBpbmcgUGFuDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMTUsIDIwMTIgMTI6MjAgQU0NClRvOiBU aW5hIFRTT1UNCkNjOiBzZG5wQGx1Y2lkdmlzaW9uLmNvbQ0KU3ViamVjdDogUmU6IFtTZG5wXSB1 cGRhdGVkIFNETiBwcm9ibGVtIHN0YXRlbWVudCBkcmFmdA0KDQogDQoNCldyb25nIGxpc3QgdG8g YXNrIHRoZSBxdWVzdGlvbi4gDQoNCk9uIFdlZCwgTWFyIDE0LCAyMDEyIGF0IDExOjQxIEFNLCBU aW5hIFRTT1UgPFRpbmEuVHNvdS5ab3V0aW5nQGh1YXdlaS5jb20+IHdyb3RlOg0KDQoNCg0KU2Vu dCBmcm9tIG15IGlQYWQNCg0KDQpPbiBNYXIgMTQsIDIwMTIsIGF0IDY6MjcgQU0sICJQaW5nIFBh biIgPHBpbmdAcGluZ3Bhbi5vcmc+IHdyb3RlOg0KDQoJT24gV2VkLCBNYXIgMTQsIDIwMTIgYXQg NToyMyBBTSwgU2NvdHQgQnJpbSA8c2NvdHQuYnJpbUBnbWFpbC5jb20+IHdyb3RlOg0KDQoJT24g VHVlLCBNYXIgMTMsIDIwMTIgYXQgMTE6NDgsIERhdmlkIE1leWVyIDxkbW1AMS00LTUubmV0PiB3 cm90ZToNCgk+IFRoYW5rcyBQaW5nLiBTZWFyY2ggZm9yIGRtbT4gaW4tbGluZS4NCg0KCT4gICAg U29mdHdhcmUgRGVmaW5lZCBOZXR3b3JrIChTRE4pIGlzIGFuIG92ZXJsYXkgYXJjaGl0ZWN0dXJl IHRoYXQNCgk+ICAgIHByZXNlbnRzIHRoZSB1bmRlcmx5aW5nIHRyYW5zcG9ydCBuZXR3b3JrIHRv IHRoZSBhcHBsaWNhdGlvbnMgYW5kDQoJPiAgICBzZXJ2aWNlcyBmb3IgbW9uaXRvcmluZywgYW5k IHByb3Zpc2lvbmluZyBhdCBhYnN0cmFjdGlvbiBsZXZlbC4NCgk+DQoJPg0KCT4gZG1tPiBJcyBp dCB0cnVlIHRoYXQgU0ROIGFuIG92ZXJsYXkgYXJjaGl0ZWN0dXJlLCBvciBpcyB0aGlzIFNETg0K CT4gZG1tPiBzb21ldGhpbmcgZGlmZmVyZW50IHRoYW4gd2hhdCBpcyBiZWluZyB0ZXJtZWQgU0RO IGluIHRoZQ0KCT4gZG1tPiBpbmR1c3RyeT8gSWYgc28gbWF5YmUgd2Ugc2hvdWxkIHVzZSBhIGRp ZmZlcmVudCB0ZXJtPw0KCQ0KCUZyb20gYSBkaXN0YW5jZSBJJ20gc3RpbGwgd29uZGVyaW5nIGFi b3V0IHRoaXMgZ3JvdXAncyAiU0ROIiBhbmQgb3RoZXINCgkiU0ROcyIuICBUaGlzIGRlZmluaXRp b24gZG9lc24ndCBzb3VuZCBsaWtlIGFuIG92ZXJsYXkgYXJjaGl0ZWN0dXJlLA0KCXJhdGhlciBp dCBzb3VuZHMgbGlrZSBlbGVtZW50IG1hbmFnZW1lbnQuDQoNCgkgDQoNCglZZWFoLCBJIGhlYXIg eW91LiBMZXQncyBmb3JnZXQgYWJvdXQgT05GIFNETiwgSUVURiBTRE4gYW5kIG90aGVyIGZsYXZv cnMgb2YgU0ROJ3MgYW5kIG5hbWVzLiBMZXQncyBqdXN0IGZvY3VzIG9uIGl0cyBvcmlnaW5hbCBj b25jZXB0IHRoYXQgZmlyc3QgYWR2b2NhdGVkIGJ5IFNjb3R0IFNoZW5rZXIgYW5kIG90aGVycyAt IHdlIG1heSBoYXZlIG1pc2ludGVycHJldGVkIGl0IHF1aXRlIGEgYml0LiBIb3dldmVyLCBvdmVy IHRoZSBwYXN0IG1hbnkgbW9udGhzLCB3ZSBrZWVwIGFza2luZzogd2hhdCBpcyBpdD8gd2h5IHVz PyBob3cgZG9lcyBpdCByZWFsbHkgd29yayBhdCBlbmdpbmVlcmluZyBsZXZlbD8gd2hhdCBidXNp bmVzcyB3aWxsIGl0IHNlcnZlPw0KDQoJIA0KDQoJRm9yIGEgbG9uZyB0aW1lLCB3ZSBoYXZlIGJl ZW4gdHJ5aW5nIHRvIGdvIHRocm91Z2ggYWxsIHRoZSBtYXRlcmlhbCwgcHJvZHVjdHMgYW5kIHVz ZSBjYXNlcyB0aGF0IHdlIGNhbiBnZXQgb3VyIGhhbmRzIG9uLCBhbmQgbWV0IG1hbnkgd2hvIGFy ZSB3b3JraW5nIGluIHRoaXMgYXJlYS4gVGhlcmUgYXJlIGEgY291cGxlIG9mIGVubGlnaHRlbiBt b21lbnRzLCBlc3BlY2lhbGx5LCB3aGVuIEkgc2F3IHRoZSBjYW1wdXMgZGVwbG95bWVudCBpbiBJ bmRpYW5hIFVuaXZlcnNpdHkuIFRocm91Z2ggdGhlIHVzZSBvZiByb3V0ZXJzIHBsdXMgT3BlbkZs b3ctZW5hYmxlZCBPRU0gYm94ZXMsIHRoZSB2aXJ0dWFsIE5PQyBjYW4gY29udHJvbCBhbmQgYWxs b2NhdGUgYmFuZHdpZHRoIHRvIGRpZmZlcmVudCB1c2Vycy4gVGhlIHVzZXJzIGNhbiBydW4gYSB0 b3RhbGx5IGluZGVwZW5kZW50IG5ldHdvcmsgb2ZmIHNlcnZlcnMsIGFuZCBydW4gc29tZSB2ZXJ5 IHNpbXBsZSBhcHBsaWNhdGlvbnMuIFRoZSB0b3RhbCBjb3N0IG9mIG93bmVyc2hpcCBpcyB0aW55 LCB0aGUgbWFuYWdlbWVudCBvZiB0aGUgdmlydHVhbCBOT0MgaXMgZ2V0dGluZyBjcmF6eSwgYnV0 IHRoZSBwb3RlbnRpYWwgaXQgcHJlc2VudHMgaXMgYW1hemluZy4gIChUaGUgZ3V5IHdhcyB0ZWxs aW5nIG1lIHRoYXQgdGhlIGV4Y2l0ZW1lbnQsIHRoZSBjcmF6aW5lc3MgYW5kIHRoZSB1bmtub3du cyBhcmUgdmVyeSBtdWNoIGxpa2Ugd2hlbiB3ZSB3ZXJlIGRvaW5nIE5GU25ldCA6LSkpDQoNCgkg DQoNCglUaGlzICJ2aXJ0dWFsIiBuZXR3b3JrIGlzIHByZXNlbnRpbmcgaXRzZWxmIHdpdGggYSBy ZWFsIGVuZ2luZWVyaW5nIGNoYWxsZW5nZSB0byBvdmVyY29tZS4gVXNlciByZWdpc3RyYXRpb24g aXMgYSBwcm9ibGVtLiBUaGUgZXhpc3RpbmcgcHJvdmlzaW9uaW5nIG1ldGhvZG9sb2d5IGlzIHdh eSB0b28gdHJpdmlhbCB2aWEgT3BlbkZsb3csIG9uIHRoZSBvdGhlciBoYW5kLCB0aGUgYm94IGl0 c2VsZiBpcyBkaXJ0IGNoZWFwLiBUaGUgYmFzaWMgbmV0d29yayBtYW5hZ2VtZW50LCBpbmNsdWRp bmcgY29vcmRpbmF0aW5nIG5ldHdvcmsgYWxhcm1zIHRvIHRoZSB2aXJ0dWFsIHVzZXJzL2FwcGxp Y2F0aW9ucywgaXMgbm90IGluIHBsYWNlLiBSZWR1bmRhbmN5IGFuZCBwcm90ZWN0aW9uIC0gd2hh dCBhcmUgdGhleT8gOy0pIFllcywgdGhlIG5vcnRoLWJvdW5kIEFQSSdzIGRvIG5vdCBleGlzdCBp biBhbnkgc3RhbmRhcmQgZm9ybS4uLi4NCg0KRG9lc24ndCBTT1AgZG8gdGhpcyBqb2I/DQoNCg0K DQoNCg0KIA0KDQpXZSBjYW4gY2FsbCB3aGF0ZXZlciB0aGUgbmFtZSB3ZSB3YW50LCBidXQgSSB0 aGluayB0aGlzIGlzIGFuIGFyZWEgdGhhdCBJRVRGIGNhbiBhZGRyZXNzIGFuZCBjb250cmlidXRl Lg0KDQogDQoNClJlZ2FyZHMsDQoNCiANCg0KUGluZw0KDQogDQoNCg== ------_=_NextPart_001_01CD066A.85140BDB Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxp bms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGluYSwgPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5M YXRlIHJlc3BvbnNlLCBqdXN0IGNhdGNoaW5nIHVwIHdpdGggZW1haWwgYmFja2xvZy4gVGhlIHNo b3J0IGFuc3dlciB0byB5b3VyIHF1ZXN0aW9uIGlzIOKAnHllc+KAnS4gVGhlIGxvbmcgYW5zd2Vy IGlzIGJlbG93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+U0ROIGluIHRoZSBPTkYgc2Vuc2UgaXMgbmV0 d29ya2luZyBzcGVjaWZpYy4gSW4gdGhlIFNETlAgZHJhZnRzLCBJIGhhdmUgc2VlbiBjb21wdXRl LCBzdG9yYWdlIGFuZCBzZWN1cml0eSBhbHNvIG1lbnRpb25lZCBhcyB3aXRoaW4gdGhlIHNjb3Bl IG9mIFNETlAuIFRoYXQgbWFrZXMgbWUgdGhpbmsg4oCTIGhvdyBhcmUgd2UgY3Jvc3NpbmcgdGhl c2UgZG9tYWlucyB3aGlsZSBzdGlsbCBjYWxsaW5nIHRoaXMgU0ROPyBJdCBoYXMgdG8gYmUgYSB3 aWRlciBkZWZpbml0aW9uIG9mIFNETiB3aGVyZSBTRE4gaXMgbm90IGxpbWl0ZWQgdG8gbmV0d29y a2luZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSBvdGhlciBpc3N1ZSBpcyBpZiBTRE4gaXMgbGlt aXRlZCB0byBhIOKAnGRldmljZSBkcml2ZXLigJ0gbGV2ZWwgYWJzdHJhY3Rpb24gb2YgYSBkZXZp Y2UgYXMgT0YgcG9ydHJheXMgaXQuIEl0IG1heSBub3QgYmUuIFdpdGhpbiBhIG5ldHdvcmtpbmcg ZGV2aWNlLCB5b3UgY2FuIGFic3RyYWN0IGEgc3dpdGNoIGF0IHRoZSBsZXZlbCBvZiBkZXZpY2Ug ZHJpdmVyLCBSSUIsIHJvdXRpbmcgcHJvdG9jb2xzIG9yIG1nbXQgaW50ZXJmYWNlcy4gSW4gc29t ZSBjYXNlcywgYWxsIG9mIHRoZXNlIG1heSBiZSBuZWVkZWQgY29uY3VycmVudGx5LiBJIHRoaW5r IGluIG1vc3QgcHJhY3RpY2FsIGNhc2VzIHlvdSBuZWVkIGFsbCBvZiB0aGVtLiBBbiBleGFtcGxl IG9mIHRoaXMgaXMgT0YtQ29uZmlnIHdoaWNoIGhhcyB0byBkZWZpbmUgYSByb3V0aW5nIGNvbmZp Z3VyYXRpb24gdXNpbmcgWE1MIHdoaWNoIGFic3RyYWN0cyBvbiBDTEkgZm9yIE9GIHBhY2tldHMg dG8gZXZlbiByZWFjaCB0aGUgZGV2aWNlLiBTbywgeW91IGNhbuKAmXQgZ2V0IGF3YXkgd2l0aCBt dWx0aXBsZSBsZXZlbHMgYW55d2F5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+V2hlbiB5b3Ugd2FudCBt dWx0aS1kb21haW4gYW5kIG11bHRpLXRpZXIgU0ROLCB0aGVuIHlvdSBuZWVkIHNvbWV0aGluZyBt b3JlIGdlbmVyaWMgdGhhbiB3aGF0IE9GIGlzIGdpdmluZyB0b2RheS4gT25lIG9mIHRoaW5ncyB5 b3Ugd2lsbCBmaW5kIGlzIHRoZSBuZWVkIHRvIHNlcGFyYXRlIHRoZSB0cmFuc2FjdGlvbiBwaWVj ZXMgZnJvbSB0aGUgc2VydmljZSBwaWVjZXMuIFBlb3BsZSBvZnRlbiBzYXkgdGhhdCB3ZSBjYW4g dGllciBzZXBhcmF0ZSBkb21haW4gY29udHJvbGxlcnMgYW5kIGludGVncmF0ZSB0aGVtIGF0IGEg aGlnaGVyIGxldmVsIGNvbnRyb2xsZXIuIEkgZG9u4oCZdCB0aGluayB0aGF0IGlzIHRyaXZpYWwu IEhvdyBkbyB5b3UgaW50ZWdyYXRlIHR3byBkaWZmZXJlbnQgZG9tYWlucywgdW5sZXNzIHRoZXkg c3BlYWsgaW4gdGhlIHNhbWUgbGFuZ3VhZ2U/IMKgV2UgbmVlZCB0byBkcml2ZSBjb21tb24gYXBw cm9hY2hlcyB0byByZWR1Y2UgY29tcGxleGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPldlIGRvbuKA mXQgd2FudCB0byBiZSByZXBsYWNpbmcgdGhlIGhvcml6b250YWwgY29tcGxleGl0eSB3aXRoIGEg dmVydGljYWwgY29tcGxleGl0eS4gPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGFua3MsIEFzaGlzaDxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9 J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiJz4gc2RucC1ib3VuY2VzQGx1Y2lkdmlzaW9uLmNvbSBbbWFpbHRvOnNkbnAtYm91 bmNlc0BsdWNpZHZpc2lvbi5jb21dIDxiPk9uIEJlaGFsZiBPZiA8L2I+UGluZyBQYW48YnI+PGI+ U2VudDo8L2I+IFRodXJzZGF5LCBNYXJjaCAxNSwgMjAxMiAxMjoyMCBBTTxicj48Yj5Ubzo8L2I+ IFRpbmEgVFNPVTxicj48Yj5DYzo8L2I+IHNkbnBAbHVjaWR2aXNpb24uY29tPGJyPjxiPlN1Ympl Y3Q6PC9iPiBSZTogW1NkbnBdIHVwZGF0ZWQgU0ROIHByb2JsZW0gc3RhdGVtZW50IGRyYWZ0PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwv bzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz5X cm9uZyBsaXN0IHRvIGFzayB0aGUgcXVlc3Rpb24uJm5ic3A7PG86cD48L286cD48L3A+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+T24gV2VkLCBNYXIgMTQsIDIwMTIgYXQgMTE6NDEgQU0sIFRpbmEg VFNPVSAmbHQ7PGEgaHJlZj0ibWFpbHRvOlRpbmEuVHNvdS5ab3V0aW5nQGh1YXdlaS5jb20iPlRp bmEuVHNvdS5ab3V0aW5nQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48 ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxicj48YnI+U2VudCBmcm9tIG15IGlQYWQ8bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21hcmdpbi1ib3R0b206MTIuMHB0Jz48YnI+T24gTWFyIDE0LCAyMDEyLCBhdCA2OjI3IEFNLCAm cXVvdDtQaW5nIFBhbiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBpbmdAcGluZ3Bhbi5vcmci IHRhcmdldD0iX2JsYW5rIj5waW5nQHBpbmdwYW4ub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCc+PGRpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk9uIFdlZCwgTWFy IDE0LCAyMDEyIGF0IDU6MjMgQU0sIFNjb3R0IEJyaW0gJmx0OzxhIGhyZWY9Im1haWx0bzpzY290 dC5icmltQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNjb3R0LmJyaW1AZ21haWwuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21hcmdpbi1ib3R0b206MTIuMHB0Jz5PbiBUdWUsIE1hciAxMywgMjAxMiBhdCAxMTo0OCwgRGF2 aWQgTWV5ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpkbW1AMS00LTUubmV0IiB0YXJnZXQ9Il9ibGFu ayI+ZG1tQDEtNC01Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxicj4mZ3Q7IFRoYW5rcyBQaW5nLiBTZWFy Y2ggZm9yIGRtbSZndDsgaW4tbGluZS48bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29O b3JtYWw+Jmd0OyAmbmJzcDsgJm5ic3A7U29mdHdhcmUgRGVmaW5lZCBOZXR3b3JrIChTRE4pIGlz IGFuIG92ZXJsYXkgYXJjaGl0ZWN0dXJlIHRoYXQ8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7cHJlc2Vu dHMgdGhlIHVuZGVybHlpbmcgdHJhbnNwb3J0IG5ldHdvcmsgdG8gdGhlIGFwcGxpY2F0aW9ucyBh bmQ8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7c2VydmljZXMgZm9yIG1vbml0b3JpbmcsIGFuZCBwcm92 aXNpb25pbmcgYXQgYWJzdHJhY3Rpb24gbGV2ZWwuPGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7IGRt bSZndDsgSXMgaXQgdHJ1ZSB0aGF0IFNETiBhbiBvdmVybGF5IGFyY2hpdGVjdHVyZSwgb3IgaXMg dGhpcyBTRE48YnI+Jmd0OyBkbW0mZ3Q7IHNvbWV0aGluZyBkaWZmZXJlbnQgdGhhbiB3aGF0IGlz IGJlaW5nIHRlcm1lZCBTRE4gaW4gdGhlPGJyPiZndDsgZG1tJmd0OyBpbmR1c3RyeT8gSWYgc28g bWF5YmUgd2Ugc2hvdWxkIHVzZSBhIGRpZmZlcmVudCB0ZXJtPzxicj48YnI+RnJvbSBhIGRpc3Rh bmNlIEknbSBzdGlsbCB3b25kZXJpbmcgYWJvdXQgdGhpcyBncm91cCdzICZxdW90O1NETiZxdW90 OyBhbmQgb3RoZXI8YnI+JnF1b3Q7U0ROcyZxdW90Oy4gJm5ic3A7VGhpcyBkZWZpbml0aW9uIGRv ZXNuJ3Qgc291bmQgbGlrZSBhbiBvdmVybGF5IGFyY2hpdGVjdHVyZSw8YnI+cmF0aGVyIGl0IHNv dW5kcyBsaWtlIGVsZW1lbnQgbWFuYWdlbWVudC48bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+WWVhaCwgSSBoZWFyIHlvdS4gTGV0J3MgZm9yZ2V0IGFib3V0IE9ORiBTRE4sIElFVEYg U0ROIGFuZCBvdGhlciBmbGF2b3JzIG9mIFNETidzIGFuZCBuYW1lcy4gTGV0J3MganVzdCBmb2N1 cyBvbiBpdHMgb3JpZ2luYWwgY29uY2VwdCB0aGF0IGZpcnN0IGFkdm9jYXRlZCBieSBTY290dCBT aGVua2VyIGFuZCBvdGhlcnMgLSB3ZSBtYXkgaGF2ZSBtaXNpbnRlcnByZXRlZCZuYnNwO2l0IHF1 aXRlIGEgYml0LiBIb3dldmVyLCBvdmVyIHRoZSBwYXN0IG1hbnkgbW9udGhzLCZuYnNwO3dlIGtl ZXAgYXNraW5nOiB3aGF0IGlzIGl0PyB3aHkgdXM/IGhvdyBkb2VzIGl0IHJlYWxseSB3b3JrIGF0 Jm5ic3A7ZW5naW5lZXJpbmcmbmJzcDtsZXZlbD8gd2hhdCBidXNpbmVzcyB3aWxsIGl0IHNlcnZl PzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkZvciBhIGxvbmcgdGltZSwg d2UgaGF2ZSBiZWVuIHRyeWluZyB0byBnbyB0aHJvdWdoIGFsbCB0aGUgbWF0ZXJpYWwsIHByb2R1 Y3RzIGFuZCB1c2UgY2FzZXMgdGhhdCB3ZSBjYW4gZ2V0IG91ciBoYW5kcyBvbiwgYW5kIG1ldCBt YW55IHdobyBhcmUgd29ya2luZyBpbiB0aGlzIGFyZWEuJm5ic3A7VGhlcmUgYXJlIGEgY291cGxl IG9mIGVubGlnaHRlbiBtb21lbnRzLCBlc3BlY2lhbGx5LCB3aGVuIEkgc2F3IHRoZSBjYW1wdXMg ZGVwbG95bWVudCBpbiBJbmRpYW5hIFVuaXZlcnNpdHkuIFRocm91Z2ggdGhlIHVzZSBvZiByb3V0 ZXJzIHBsdXMgT3BlbkZsb3ctZW5hYmxlZCBPRU0gYm94ZXMsIHRoZSB2aXJ0dWFsIE5PQyBjYW4g Y29udHJvbCBhbmQgYWxsb2NhdGUgYmFuZHdpZHRoIHRvIGRpZmZlcmVudCB1c2Vycy4gVGhlIHVz ZXJzIGNhbiBydW4gYSB0b3RhbGx5Jm5ic3A7aW5kZXBlbmRlbnQmbmJzcDtuZXR3b3JrIG9mZiBz ZXJ2ZXJzLCBhbmQgcnVuIHNvbWUgdmVyeSBzaW1wbGUgYXBwbGljYXRpb25zLiBUaGUgdG90YWwg Y29zdCBvZiBvd25lcnNoaXAgaXMgdGlueSwgdGhlIG1hbmFnZW1lbnQgb2YgdGhlIHZpcnR1YWwg Tk9DIGlzIGdldHRpbmcgY3JhenksIGJ1dCB0aGUgcG90ZW50aWFsIGl0IHByZXNlbnRzIGlzIGFt YXppbmcuJm5ic3A7Jm5ic3A7KFRoZSBndXkgd2FzIHRlbGxpbmcgbWUgdGhhdCB0aGUmbmJzcDtl eGNpdGVtZW50LCB0aGUgY3JhemluZXNzIGFuZCB0aGUgdW5rbm93bnMgYXJlIHZlcnkgbXVjaCBs aWtlIHdoZW4gd2Ugd2VyZSBkb2luZyBORlNuZXQgOi0pKTxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPlRoaXMgJnF1b3Q7dmlydHVhbCZxdW90OyBuZXR3b3JrIGlzIHByZXNl bnRpbmcgaXRzZWxmIHdpdGggYSByZWFsIGVuZ2luZWVyaW5nIGNoYWxsZW5nZSB0byBvdmVyY29t ZS4gVXNlciByZWdpc3RyYXRpb24gaXMgYSBwcm9ibGVtLiBUaGUgZXhpc3RpbmcgcHJvdmlzaW9u aW5nIG1ldGhvZG9sb2d5IGlzIHdheSB0b28mbmJzcDt0cml2aWFsIHZpYSBPcGVuRmxvdywgb24g dGhlIG90aGVyIGhhbmQsIHRoZSBib3ggaXRzZWxmIGlzIGRpcnQgY2hlYXAuIFRoZSBiYXNpYyBu ZXR3b3JrIG1hbmFnZW1lbnQsIGluY2x1ZGluZyZuYnNwO2Nvb3JkaW5hdGluZyZuYnNwO25ldHdv cmsgYWxhcm1zIHRvIHRoZSB2aXJ0dWFsIHVzZXJzL2FwcGxpY2F0aW9ucywgaXMgbm90IGluIHBs YWNlLiZuYnNwO1JlZHVuZGFuY3kgYW5kIHByb3RlY3Rpb24gLSB3aGF0IGFyZSB0aGV5PyA7LSkm bmJzcDtZZXMsIHRoZSBub3J0aC1ib3VuZCBBUEkncyBkbyBub3QgZXhpc3QgaW4gYW55IHN0YW5k YXJkIGZvcm0uLi4uPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2 PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5Eb2Vzbid0IFNPUCBkbyB0aGlzIGpvYj88bzpwPjwv bzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48YnI+PGJyPjxvOnA+PC9vOnA+PC9wPjxk aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+V2UgY2FuIGNhbGwgd2hhdGV2ZXIgdGhlIG5hbWUgd2Ugd2Fu dCwgYnV0IEkgdGhpbmsgdGhpcyBpcyBhbiBhcmVhIHRoYXQgSUVURiBjYW4gYWRkcmVzcyBhbmQg Y29udHJpYnV0ZS48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5SZWdhcmRz LDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlBpbmc8bzpwPjwvbzpwPjwv cD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PC9kaXY+PC9ib2R5PjwvaHRtbD4= ------_=_NextPart_001_01CD066A.85140BDB--
On Wed, Mar 14, 2012 at 6:54 PM, Ashish Dalela (adalela) <adalela@cisco.com>= wrote:

Vishwas,

=A0<= /p>

IETF works with specif= ic problem statements, and we made the problem statement for cloud control = plane w.r.t. HTTP, given that it is hugely deployed and used. There are oth= er things that are far less deployed and used for a variety of reasons, so = we did not add the problem statements w.r.t. those things.

There are two things we can do:

=A0<= /p>

1= .=A0=A0=A0=A0=A0=A0 = Complete the problem= statement with respect to HTTP (there are missing things =96 e.g. the need= to separate identity and privacy, which are not addressed by TLS and HTTPS= ).

2.=A0=A0=A0=A0=A0=A0 Add modified problem st= atements with respect to other HTTP enhancements or other protocols (XMPP .= .). Will you be willing to write that section?

=A0<= /p>

Once we have a complet= e list of problem statements from different reference points, it will becom= e clear whether to enhance existing solutions or go for new solutions. W.r.= t. existing solution enhancements, an additional problem to keep in mind is= what happens when firewalls and NAT are used. Lots of solutions are design= ed to operate within the firewall.

=A0<= /p>

Thanks, Ashish<= u>

=A0<= /p>

=A0

From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: Thursday, March 15, 2012 3:37 AM
To: Michael Hammer<= br>Cc: Ashish Dalela (adalela); sop@ietf.org


Subj= ect: Re: [sop] SOP Requirements

=A0=

Thanks Mik= e.

I am just eager that we have a clear cut set of requirements and = problem statement defined, before we go ahead and write a solution.

Ashish, sure let us look at the options and see what makes sense.
On the DTCP/IP front we have both an encryption as well as a control plan= e AKE, which serves the purpose for digital content.

-Vishwas=

On Tue, Mar 13, 2012 at 6:15 AM, Michael Hammer= <mphmmr@gmail.com= > wrote:

But, if you start w= ith an existing protocol and add methods and tweaks for every problem,=A0

you may end up with SOP again in the end. =A0:)=

=A0

Mike

=A0

On Tue, Mar 13, 2012 at 1:= 45 AM, Ashish Dalela (adalela) <adalela@cisco.com> wrote:

=

Vishwas,

=A0

There are multiple proble= ms. IKE is only key exchange. You can=92t use it to encrypt packets because= it will break policy routing (described in my email).=

=A0<= /p>

The multicast / discov= ery problem can be solved by moving from TCP to UDP. That alone isn=92t eno= ugh because moving away from TCP means you lost transaction identity.

=A0<= /p>

Sometimes what seems l= ike a solution brings some other problems, which also need to be solved.

=A0<= /p>

If you want, we can dr= aft up a list of enhancements needed to existing protocols. I=92m open to e= nhancing existing protocols.

=A0<= /p>

Thanks, Ashish<= u>

=A0<= /p>

From: sop-bounces@ietf.org= [mailto:sop-boun= ces@ietf.org] On Behalf Of Vishwas Manral
Sent: Tuesday, March 13, 2012 5:43 AM

<= div>


To: Ashish Dalela (adalela)
Cc:= sop@ietf.org; Mi= chael Hammer
Subject: Re: [sop] SOP Requirements

=A0

Hi Ashish,

Yes, I was talking ab= out UPnP/ SSDP. For hijacking prevention, we used a protocol like IKE calle= d AKE (though I am sure we could use IKE too).

I am not trying to say the protocol you invented is wrong, but based on= the top level information, it looks similar to what is achievable now.
=
So if the problem is multicast for discovery, can we optimize the disco= very part instead of doing the whole protocol itself. I think we need to pr= opose a tighter problem statement.

Thanks,
Vishwas

On Tue,= Mar 6, 2012 at 5:24 AM, Ashish Dalela (adalela) <adalela@cisco.com> wrote:=

Hi Vishwas,

=A0

I=92m supposing that you are talking about SSDP (http:/= /en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol)? Let me know = if that is correct.

=A0

In any large network, multicast isn=92t the= right way to scale. If every network element has to do a IGMP join to rece= ive ADVERTISE then it becomes a scaling issue. It also becomes a security p= roblem where some rogue element can start sending multicast ADVERTISE and h= ijack the orchestration sessions.

=A0

Broadcast doesn=92t scale either, but we ca= n convert it to a directed unicast (like DHCP for example). There are other= reasons as well, such as if there are multiple service specific controller= s then you have to choose different multicast groups for each. It seems lik= e we should use broadcast for this to be light-weight, and multicast could = be an option in case of L3 networks, but with additional access controls.

=A0

Regarding which existing protocol to extend= , there are multiple options:

=A0

HTTP =96 has CRUD, but doesn=92t support AD= VERTISE, DISCOVER, REGISTER, NOTIFY, SUBSCRIBE, COMMIT, CANCEL etc. So, jus= t adding a NOTIFY, as you suggest through SSDP, is still not going to be en= ough. Orchestration also needs =93identities=94 such as device@provider.com, which HTTP d= oesn=92t have.

=A0

XMPP =96 has PUBLISH, SUBSCRIBE, and identi= ties, but not all of the above. Service requests will require a =93VIA=94 a= nd dynamic injection of path elements, especially when a request forks into= multiple requests or is re-directed to a different provider / location.

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

<= p class=3D"MsoNormal">AMQP =96 this is designed for messaging and again lacks many of the constr= ucts.

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

So wherever we look= , the extension curve is long. It seemed like the problem space is big enou= gh to warrant a new protocol.

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

The= other issue is how easily we can implement the security for orchestration.= E.g. if we use IPSec end-to-end then how do hops in the middle route the r= equest differently (the nearest location, the cheapest location, location w= ith capacity, the location allowed by law, etc.). The right model seems to = be that we embed integrity within the protocol rather than into IPSec. Priv= acy can be implemented separately between the edges using IPSec. That secur= ity model requires another set of issues to be solved in the current protoc= ols (if we extend them).

=A0

Besides security, there are other types of = issues. For instance, a network might use UDP internally to get broadcast b= ut use TCP for unicast externally for higher reliability. That change betwe= en TCP and UDP causes loss of transaction identity, and transactions have t= o be built part of the protocol. Likewise, with overlays, and overlay trans= lations, the location information could be easily lost. Hence, you need loc= ation in the orchestration protocol. NAT may obfuscate real topology, and w= e lose information about the actual distance between two end-points.

=A0

Given these challenges, we choose to define= a protocol that can be tweaked over time for orchestration specific needs = without having to worry about backward compatibility, and/or how this gets = broken by overlay, firewalls, or NAT=92d networks. SIP already went over th= is hump and providers have learnt (somewhat painfully) on how to do this in= a way that works. That entire learning can be leveraged for cloud.<= u>

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

<= p class=3D"MsoNormal">In any case, not sure if you have seen it, but there is a draft for SOP th= at describes just what I=92m talking about.

=A0

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

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

=A0

Look forwa= rd to your comments.

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

Thanks, Ashish<= /span>

=A0<= /p>

From: Vishwas = Manral [mailto:= vishwas.ietf@gmail.com]
Sent: Tuesday, March 06, 2012 2:30 AM

<= div>


To: Ashish Dalela (adalela)
Cc:= sop@ietf.org; Mi= chael Hammer
Subject: Re: [sop] SOP Requirements

=A0

Hi Ashish,

Thanks for the mail.<= br>
So I looked at some of the reasons you mentioned you want to go in for SOP = instead of HTTP.

I however have worked in the past with the DLNA sta= ck, where we extended HTTP and used protocols like SOAP to get behaviors yo= u mention - like service discovery, transaction support etc.

If that is what we want, we should look at the DLNA stack and see how w= e can leverage existing mechanisms for the same.

I however think fi= nalizing the requirements is a good start.

Thanks,
Vishwas=

On Fri, Mar 2, 2012 at 7:26 PM, Ashish Dalela (= adalela) <adalela= @cisco.com> wrote:

Hi Vishwas,

=A0<= /p>

It is better if you co= mment on the drafts because there is a section dedicated to this very topic= .

=A0<= /p>

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

=A0<= /p>

This describes what yo= u can=92t do with web-services (assuming that=92s what you mean by APIs). T= his is *not* the shortcoming of the APIs, but that of the underlying= *protocol* (HTTP). So, if you changed the underlying protocol to fi= x issues with HTTP, then the APIs would be more powerful. That protocol we = propose to be SOP.

=A0<= /p>

You are mistaking me i= n pitching API against protocols. I=92m pitching protocol (HTTP) against pr= otocol (SOP). Unfortunately, application developers abuse the term API to m= ean HTTP web-services, and the discussion is then messed up into thinking p= rotocol against API.

=A0<= /p>

Thanks, Ashish<= u>

=A0<= /p>

From: sop-bounces@ietf.org= [mailto:sop-boun= ces@ietf.org] On Behalf Of Vishwas Manral
Sent: Saturday, March 03, 2012 12:19 AM
To: Ashish Dalela = (adalela)
Cc: s= op@ietf.org; Michael Hammer


Subject: Re: [sop] SOP Requirements

=A0

Hi Ashish,

My point was very= simple.

You had talked about cases where protocol is more flexible than an API,= and I was trying to help you understand that anything that can be done in = an East West manner (with protocols), can be done in North-South manner wit= h API's. If you say we can do something with protocols with only X pack= ets, we can do the same with just X API's too. That was my point and no= t the fact that we have only 1 API or more.

Also API's on which base services sit and ones which end users use = could be different.

Am I missing the point altogether?

Thanks= ,
Vishwas

On Wed, Feb 29, 2= 012 at 6:51 PM, Ashish Dalela (adalela) <adalela@cisco.com> wrote:

Hi Vishwas,

=A0<= /span>

What everyone calls API t= oday uses a protocol =96 HTTP. APIs survive on the interoperability provide= d by that protocol, and I don=92t think anyone can get away from that. The = real question is =96 what is the right protocol on top of which to build AP= Is? That=92s the question SOP is raising. Once you do that, then we can tal= k of one or many APIs.

=A0<= /p>

Limitations of using H= TTP 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 s= ection describes what APIs can=92t do. Some of the limitations are because = API is always unicast, and there are many things for which you need a manyc= ast and broadcast. Other limitations because APIs are synchronous and you n= eed to be asynchronous in some cases. Yet other issues because APIs are sin= gle complete transaction, but some transactions will spread over multiple s= uch APIs.

=A0<= /p>

The total amount of in= formation in a message is unchanged whether you put it inside a protocol he= ader 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 ot= her 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 re= peating that for voice and video and chat content.

=A0<= /p>

To your point, you can= have a single API for doing anything. As the service evolves and complexit= y grows, the number of parameters to that API increases. And yes, you can m= ake that backward compatible in terms of implementation. But, nobody does t= hat =96 especially when the interface is end-user facing. If this was an ac= ceptable design, then we would not have object inheritance and there won=92= t be hundreds of APIs being opened up by cloud providers today. You might w= ant to suggest one API to Amazon or other cloud providers.

=A0<= /p>

A practical operationa= l issue with APIs is that users don=92t understand all the details. A user = understands a server memory and CPU, but don=92t understand VLAN and LUN, a= nd zillions of other complicated things. Exposing them through APIs is usel= ess because they can=92t use it. Why would a user buy an expensive TV when = they can=92t use most of the features, because the remote is too complicate= d? The need is to reduce complexity through automation, not expose it all t= o the user via APIs. In other words, you need a more sophisticated policy e= ngine not a sophisticated API system.

=A0<= /p>

For any problem there = is a cure and there is a prevention. Building API bridges is a cure to dive= rse APIs, it=92s not a prevention. Once you recognize a problem, you build = a short-term cure and a long-term prevention (at least ideally). Then, a si= ngle API is neither a cure nor prevention; its side-effects are so severe t= hat we might be living with the original problem as well. =

=A0<= /p>

APIs have always exist= ed and will continue to exist. The goal is to interoperate diverse APIs wit= hout a translation bridge. That happens all the time with network protocols= , when one vendor=92s APIs works with another vendor=92s APIs without a tra= nslation bridge. I think not having a bridge is always better than having a= bridge. Agree?

=A0<= /p>

Thanks, Ashish<= u>

=A0<= /p>

=A0

From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: Wednesday, February 29, 2012 10:45 PM
To: Ashish Dal= ela (adalela)
Cc: Michael Hammer; sop@ietf.org


Subject: Re: [sop] SOP Requirements

=A0

Hi Ashish,

=A0

As the number of services increas= e or the complexity in a given service grows, this becomes very hard. Assum= e there is a service with N tunable parameters. You need at least N APIs th= at modify these parameters individually. Then permutations 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 br= idges, it=92s just inviting more complexity. Another limitation is that whe= n APIs have semantic incompatibilities, it becomes even harder to interoper= ate (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 we= ll 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 oper= ational standpoint, every new API introduction requires software upgrades t= o the controllers. That eventually hinders the rate of service creation.

=A0

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

That won=92t happen= if we separate service-independent and service-dependent pieces. An exampl= e of that is SNMP. SNMP is device/service independent. MIB defines the spec= ific service/device. If you have a standard protocol to manage a device, th= en 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. <= /u>

=A0<= /p>

BTW, I=92m not advocat= ing SNMP here because SNMP has many shortcomings in terms of network discov= ery, capability discovery, advertisements, transactions, etc. But, we need = to keep in mind that API proliferation is inevitable as services proliferat= e. Protocol proliferation is not inevitable. Similar separation has been do= ne in the past in SIP/SDP, HTTP/HTML, SMTP/MIME. That separation allows any= one to send any content in email to anyone. Or download any web-page, or ha= ve any type of codec (voice or video) use the same protocol.<= u>

=A0<= /p>

If you compare the suc= cess and widespread use of above mentioned protocols the value of separatio= n between service-independent and service-dependent seems pretty convincing= .

=A0=

>> C= orrect but the draft seems to differ.

=A0<= /p>

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

=A0=

>> T= he requirement seems contradictory to what we agree. Similar for points bel= ow.

=A0<= /p>

The requirement = is really that services are portable across providers. I think it is fair t= o 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.

=A0<= /p>

Thanks, Ashish<= u>

=A0<= /p>

=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<= /p>

=A0

Hi Michael,

Sounds like we ag= ree on most of the things, though I see the draft contradicting what we agr= ee 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 ado= pted by most providers. From the little I know OpenStack based API's ma= y be the alternative way and companies have built bridging layers to inter-= operate between the same.

=A0

=A0

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 perh= aps 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 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" etc could be used. All I am s= aying is can we use standard terms here.

=A0

<= div>

We can settle on specific terms to use, just so = long as we keep the distinction between the entity (enterprise?) that provi= sions 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 = Service, the operator of the Proxy provisions it with a CREATE, but the use= r 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 orchestration about creating services (from th= e cloud providers perspective), or an instance of a service (for a particul= ar user)? I think it is the latter, but doesn't sound so from the defin= ition.

=A0