Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

Jerome Moisand <jmoisand@juniper.net> Fri, 24 January 2014 15:33 UTC

Return-Path: <jmoisand@juniper.net>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B26981A011E for <sfc@ietfa.amsl.com>; Fri, 24 Jan 2014 07:33:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.6
X-Spam-Level:
X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBzFNv-8VWx1 for <sfc@ietfa.amsl.com>; Fri, 24 Jan 2014 07:33:52 -0800 (PST)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id 90C601A002C for <sfc@ietf.org>; Fri, 24 Jan 2014 07:33:52 -0800 (PST)
Received: from mail166-co9-R.bigfish.com (10.236.132.251) by CO9EHSOBE035.bigfish.com (10.236.130.98) with Microsoft SMTP Server id 14.1.225.22; Fri, 24 Jan 2014 15:33:51 +0000
Received: from mail166-co9 (localhost [127.0.0.1]) by mail166-co9-R.bigfish.com (Postfix) with ESMTP id 249882C01FB; Fri, 24 Jan 2014 15:33:51 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -23
X-BigFish: VPS-23(zzbb2dI98dI9371I542I1432Ic857hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzdchz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1c8fb4h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24ach24d7h9a9j1155h)
Received-SPF: pass (mail166-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(51704005)(377454003)(479174003)(24454002)(189002)(199002)(13464003)(31966008)(76576001)(76786001)(81542001)(59766001)(63696002)(19609705001)(81342001)(81816001)(87266001)(74502001)(54316002)(47446002)(69226001)(18717965001)(15975445006)(65816001)(74662001)(56776001)(77982001)(76796001)(85306002)(83072002)(85852003)(47976001)(80022001)(53806001)(54356001)(49866001)(56816005)(15202345003)(46102001)(51856001)(50986001)(83322001)(19580405001)(86362001)(19300405004)(74706001)(33646001)(66066001)(74876001)(74316001)(93136001)(81686001)(4396001)(90146001)(2656002)(47736001)(79102001)(19580395003)(76482001)(80976001)(87936001)(92566001)(16236675002)(2201001)(74366001)(93516002)(94316002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB713; H:CO2PR05MB716.namprd05.prod.outlook.com; CLIP:66.129.241.12; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en;
Received: from mail166-co9 (localhost.localdomain [127.0.0.1]) by mail166-co9 (MessageSwitch) id 1390577628572677_10819; Fri, 24 Jan 2014 15:33:48 +0000 (UTC)
Received: from CO9EHSMHS008.bigfish.com (unknown [10.236.132.253]) by mail166-co9.bigfish.com (Postfix) with ESMTP id 862182004A; Fri, 24 Jan 2014 15:33:48 +0000 (UTC)
Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS008.bigfish.com (10.236.130.18) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 24 Jan 2014 15:33:45 +0000
Received: from CO2PR05MB713.namprd05.prod.outlook.com (10.141.228.147) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.395.1; Fri, 24 Jan 2014 15:33:44 +0000
Received: from CO2PR05MB716.namprd05.prod.outlook.com (10.141.228.152) by CO2PR05MB713.namprd05.prod.outlook.com (10.141.228.147) with Microsoft SMTP Server (TLS) id 15.0.851.15; Fri, 24 Jan 2014 15:33:41 +0000
Received: from CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) by CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) with mapi id 15.00.0851.011; Fri, 24 Jan 2014 15:33:41 +0000
From: Jerome Moisand <jmoisand@juniper.net>
To: "mikebianc@aol.com" <mikebianc@aol.com>, "Ron_Parker@affirmednetworks.com" <Ron_Parker@affirmednetworks.com>, "jmh@joelhalpern.com" <jmh@joelhalpern.com>, "linda.dunbar@huawei.com" <linda.dunbar@huawei.com>, "Cathy.H.Zhang@huawei.com" <Cathy.H.Zhang@huawei.com>, "paulq@cisco.com" <paulq@cisco.com>, "jguichar@cisco.com" <jguichar@cisco.com>
Thread-Topic: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02
Thread-Index: AQHPFtz0BBXmRpg9rk2thNSnYBnFRZqPsP9wgAG25QCAAUIjgP//+sSwgAC0XgD//907sIAAjLcAgAArhjCAABPegIAAAumA
Date: Fri, 24 Jan 2014 15:33:41 +0000
Message-ID: <aca97274f9c84c07bbb81da119298b93@CO2PR05MB716.namprd05.prod.outlook.com>
References: <CF05AD35.146E8%jguichar@cisco.com> <DE09C008-A519-4B26-9F54-3A188ED41BE5@cisco.com> <A2C96F6779E6A041BC7023CC207FC99418F0A482@SJCEML701-CHM.china.huawei.com> <52E186B0.5020809@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C6F32D@dfweml701-chm.china.huawei.com> <52E1DF90.2070605@joelhalpern.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A7981A3@MBX021-W3-CA-2.exch021.domain.local> <184198357.1683.1390576957523.JavaMail.tomcat@mgs-aaa01.mail.aol.com>
In-Reply-To: <184198357.1683.1390576957523.JavaMail.tomcat@mgs-aaa01.mail.aol.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.241.12]
x-forefront-prvs: 01018CB5B3
Content-Type: multipart/alternative; boundary="_000_aca97274f9c84c07bbb81da119298b93CO2PR05MB716namprd05pro_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jan 2014 15:33:56 -0000

Great idea, Mike.


From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mikebianc@aol.com
Sent: Friday, January 24, 2014 10:23 AM
To: Ron_Parker@affirmednetworks.com; jmh@joelhalpern.com; linda.dunbar@huawei.com; Cathy.H.Zhang@huawei.com; paulq@cisco.com; jguichar@cisco.com
Cc: sfc@ietf.org
Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

To avoid further confusion, should we refer to the selection of a service instance as "service distribution" instead of "load balancing" to clearly differentiate this from the "load balancer" service?



________________________________
From: Ron_Parker@affirmednetworks.com<Ron_Parker@affirmednetworks.com<mailto:Ron_Parker@affirmednetworks.com%3cRon_Parker@affirmednetworks.com>>
To: Joel M. Halpern<jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>,Linda Dunbar<linda.dunbar@huawei.com<mailto:linda.dunbar@huawei.com>>,Cathy Zhang<Cathy.H.Zhang@huawei.com<mailto:Cathy.H.Zhang@huawei.com>>,Paul Quinn (paulq)<paulq@cisco.com<mailto:paulq@cisco.com>>,Jim Guichard (jguichar)<jguichar@cisco.com<mailto:jguichar@cisco.com>>
cc: sfc@ietf.org<sfc@ietf.org<mailto:sfc@ietf.org%3csfc@ietf.org>>
Sent: Friday, January 24, 2014
Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

Hi, Joel.

I think you raise an excellent point on the ambiguity of load balancing.   I would propose that there are more than 2 cases of load balancing:

* mid-box service function (e.g., firewall) with internal load balancing
* mid-box service function (e.g., firewall) requiring external load balancing
* explicitly addressed service (e.g., DB server) with internal load balancing
* explicitly addressed service (e.g., Web HTTP server) requiring external load balancing

From an SFC perspective, I think we can ignore the cases where the mid-box or explicit application is internally load balanced.   Such applications would typically present a single locator (i.e., IP address) to the outside world and manage redirection internally to the clustered application.

I think the last bullet, external load balancing for an explicitly addressed service (e.g., Web HTTP server) lends itself to load balancing as an explicit service function from an SFC perspective.   That is, the service function in the service function chain is "load balancer".

The second bullet, external load balancing for mid-box service function (e.g., firewall), is slightly trickier.   From an SFC perspective, my view is that the service function that appears in the service function chain is still firewall and not load balancer.   However, I do think that SFC should explicitly embrace the concept of a "load-balanced service function".   I tried to address this in http://datatracker.ietf.org/doc/draft-parker-sfc-chain-to-path/ and would appreciate any feedback.

Thanks.

  Ron


-----Original Message-----


From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern
Sent: Thursday, January 23, 2014 10:36 PM
To: Linda Dunbar; Cathy Zhang; Paul Quinn (paulq); Jim Guichard (jguichar)
Cc: sfc@ietf.org<mailto:sfc@ietf.org>
Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

For apps that have their own internal load balancer, I agree that there is no point in the tenant using the data center offered load balancer service.
But many apps do not have their own custom load balancer. So a data center might well offer load balancing as a service for those tenants who want it.

My only point was to distinguish load balancing as a service selected by the customer from load balancing used by the oeprator internall;y to deliver some other service.

Yours,
Joel

On 1/23/14 10:18 PM, Linda Dunbar wrote:
> Joel,
> Questions inserted below:
> -----Original Message-----
> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern
> Sent: Thursday, January 23, 2014 3:17 PM
> To: Cathy Zhang; Paul Quinn (paulq); Jim Guichard (jguichar)
> Cc: sfc@ietf.org<mailto:sfc@ietf.org>
> Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02
> In looking at the services, we need to be careful about who the
> service is for. Using load balancing as an example, there are two different cases.
> One case, common in a data center, will bw where load balncing is
> part of the service being delivered to the tenant, to help manage the
> tenants application traffic.
> [Linda] do you mean when "Load Balancing" among cluster of servers for
> one tenant application being offered as a service?
> Isn't this kind of "load balancing" application specific? Like Oracle
> DB has its own Load Balancer among cluster of servers.
> A different situation is when load balancing is used internally to the
> service chaining to manage instances of the internal services (where
> cardinality is invisible to the tenant / user).
> In the former case, LB is a service. And has to be able to direct
> traffic to the correct tenant application instance.
> In the latter case, the load balancing may well be bundled in with a
> collection of co-located service instances, with the whole looking
> like a service instance to service chaining and the end user. (There
> appear to be a multiplicity of ways to deliver this behavior. How
> much we need to specify in the architecture remains to be seen.)
> Yours, Joel _______________________________________________
> sfc mailing list
> sfc@ietf.org<mailto:sfc@ietf.org> <mailto:sfc@ietf.org>
> https://www.ietf.org/mailman/listinfo/sfc
_______________________________________________
sfc mailing list
sfc@ietf.org<mailto:sfc@ietf.org>
https://www.ietf.org/mailman/listinfo/sfc
_______________________________________________
sfc mailing list
sfc@ietf.org<mailto:sfc@ietf.org>
https://www.ietf.org/mailman/listinfo/sfc