From mlarson@amsl.com Wed Jan 8 05:35:16 2014 Return-Path: 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 7E6041AE3AB for ; Wed, 8 Jan 2014 05:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.039 X-Spam-Level: X-Spam-Status: No, score=-1.039 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.538, 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 JWkvf5gzcGoC for ; Wed, 8 Jan 2014 05:35:14 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1890:126c::1:15]) by ietfa.amsl.com (Postfix) with ESMTP id 65A741AE3A5 for ; Wed, 8 Jan 2014 05:35:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c9a.amsl.com (Postfix) with ESMTP id 642A6A60A0 for ; Wed, 8 Jan 2014 05:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c9a.amsl.com ([127.0.0.1]) by localhost (c9a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KOjaJd9Ch61 for ; Wed, 8 Jan 2014 05:33:24 -0800 (PST) Received: from [192.168.0.128] (unknown [142.196.200.6]) by c9a.amsl.com (Postfix) with ESMTPA id 246BFA609C for ; Wed, 8 Jan 2014 05:33:24 -0800 (PST) From: Matt Larson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5BFE41E9-2404-4DF1-A0EC-B94EDEC40192@amsl.com> Date: Wed, 8 Jan 2014 08:34:43 -0500 To: sfc@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) X-Mailman-Approved-At: Wed, 08 Jan 2014 05:39:53 -0800 Subject: [sfc] test X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 13:35:16 -0000 Testing ------------------------------------------- Matthew Larson, Asst. IT Director Association Management Solutions Forum Management, Meeting and Event Planning 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 http://www.amsl.com From adrian@olddog.co.uk Wed Jan 8 08:17:02 2014 Return-Path: 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 631871ADFFD for ; Wed, 8 Jan 2014 08:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 TTlAb9Q-MH9u for ; Wed, 8 Jan 2014 08:17:01 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id E0D431ADFD7 for ; Wed, 8 Jan 2014 08:16:57 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s08GGlLT009974 for ; Wed, 8 Jan 2014 16:16:47 GMT Received: from 950129200 (108.26.90.92.rev.sfr.net [92.90.26.108]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s08GGjck009965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 8 Jan 2014 16:16:46 GMT From: "Adrian Farrel" To: Date: Wed, 8 Jan 2014 16:16:48 -0000 Message-ID: <036a01cf0c8d$099b52d0$1cd1f870$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8MjQg/gmcNQQ6UQeyCkRGlzYzJag== Content-Language: en-gb X-TM-AS-MML: No Subject: [sfc] Mailing list migrated X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 16:17:02 -0000 Hi, In theory a seamless migration. Please send to sfc@ietf.org with all your wonderful and energetic discussions. Adrian From ramk@Brocade.com Wed Jan 8 21:15:15 2014 Return-Path: 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 2234F1ADF63 for ; Wed, 8 Jan 2014 21:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 9nR2vFnFeKAS for ; Wed, 8 Jan 2014 21:15:13 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4641ADF38 for ; Wed, 8 Jan 2014 21:15:13 -0800 (PST) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s094GehK012087; Wed, 8 Jan 2014 21:14:59 -0800 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1h8nudj7ca-7 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 08 Jan 2014 21:14:59 -0800 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 8 Jan 2014 21:14:59 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Wed, 8 Jan 2014 21:14:55 -0800 From: ramki Krishnan To: "sfc@ietf.org" Date: Wed, 8 Jan 2014 21:14:54 -0800 Thread-Topic: New Version Notification for draft-krishnan-sfc-long-lived-flow-use-cases-00.txt Thread-Index: Ac8M+RISio15GMrXSjGSqG18JV14RgAABASA Message-ID: References: <20140109051011.20660.93669.idtracker@ietfa.amsl.com> In-Reply-To: <20140109051011.20660.93669.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-09_02:2014-01-07,2014-01-09,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1401080213 Cc: ramki Krishnan , Joel Halpern , Anoop Ghanwani , "Sriganesh Kini \(sriganesh.kini@ericsson.com\)" Subject: Re: [sfc] New Version Notification for draft-krishnan-sfc-long-lived-flow-use-cases-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 05:15:15 -0000 RGVhciBBbGwsDQoNCldlIGhhdmUgcG9zdGVkIGEgZHJhZnQgb24gTG9uZy1saXZlZCBGbG93IFVz ZSBDYXNlcyBmb3IgU0ZDLiBMb29raW5nIGZvcndhcmQgdG8geW91ciBjb21tZW50cy4NCg0KVGhh bmtzLA0KUmFta2kgb24gYmVoYWxmIG9mIHRoZSBjby1hdXRob3JzDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDA4LCAyMDE0 IDk6MTAgUE0NClRvOiBTcmlnYW5lc2ggS2luaTsgcmFta2kgS3Jpc2huYW47IEpvZWwgSGFscGVy bjsgU3JpZ2FuZXNoIEtpbmk7IEFub29wIEdoYW53YW5pOyByYW1raSBLcmlzaG5hbjsgSm9lbCBI YWxwZXJuOyBBbm9vcCBHaGFud2FuaQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC1rcmlzaG5hbi1zZmMtbG9uZy1saXZlZC1mbG93LXVzZS1jYXNlcy0wMC50eHQN Cg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQta3Jpc2huYW4tc2ZjLWxvbmctbGl2ZWQt Zmxvdy11c2UtY2FzZXMtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5 IHJhbSAocmFta2kpIGtyaXNobmFuIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4N Cg0KTmFtZToJCWRyYWZ0LWtyaXNobmFuLXNmYy1sb25nLWxpdmVkLWZsb3ctdXNlLWNhc2VzDQpS ZXZpc2lvbjoJMDANClRpdGxlOgkJU0ZDIExvbmctbGl2ZWQgRmxvdyBVc2UgQ2FzZXMNCkRvY3Vt ZW50IGRhdGU6CTIwMTQtMDEtMDgNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdl czoJCTgNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1rcmlzaG5hbi1zZmMtbG9uZy1saXZlZC1mbG93LXVzZS1jYXNlcy0wMC50eHQNClN0 YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1rcmlz aG5hbi1zZmMtbG9uZy1saXZlZC1mbG93LXVzZS1jYXNlcy8NCkh0bWxpemVkOiAgICAgICBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1rcmlzaG5hbi1zZmMtbG9uZy1saXZlZC1mbG93 LXVzZS1jYXNlcy0wMA0KDQoNCkFic3RyYWN0Og0KICAgTG9uZy1saXZlZCBmbG93cyBzdWNoIGFz IGZpbGUgdHJhbnNmZXJzLCB2aWRlbyBzdHJlYW1zIGFyZSBjb21tb24gaW4NCiAgIHRvZGF5J3Mg bmV0d29ya3MuIEluIHRoZSBjb250ZXh0IG9mIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcsIHRo aXMNCiAgIGRyYWZ0IHN1Z2dlc3RzIHVzZSBjYXNlcyBmb3IgZHluYW1pYyBieXBhc3Mgb2YgY2Vy dGFpbiBzZXJ2aWNlIG5vZGVzDQogICBmb3Igc3VjaCBmbG93cy4gVGhlIGJlbmVmaXQgb2YgdGhp cyBhcHByb2FjaCB3b3VsZCBiZSB0byBhdm9pZA0KICAgZXhwZW5zaXZlIExheWVyIDcgc2Vydmlj ZSBub2RlIHByb2Nlc3NpbmcgZm9yIHN1Y2ggZmxvd3MgYmFzZWQgb24NCiAgIGR5bmFtaWMgZGVj aXNpb25zIGFuZCBpbXByb3ZlIG92ZXJhbGwgcGVyZm9ybWFuY2UuDQoNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9m IG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJ RVRGIFNlY3JldGFyaWF0DQoNCg== From repenno@cisco.com Thu Jan 9 08:24:03 2014 Return-Path: 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 B591D1ADEB5 for ; Thu, 9 Jan 2014 08:24:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 ebLXshPpCp6X for ; Thu, 9 Jan 2014 08:23:58 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB031AE454 for ; Thu, 9 Jan 2014 08:23:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=171; q=dns/txt; s=iport; t=1389284629; x=1390494229; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=wvX6zBhh17Adp8kBU4hNB+n9oN+pmv+hQHcpeBzvs0g=; b=AXxPpDM1oH3BfJVg1/HC7DOtidGtAOHaaWNCwwiDYOpefykEvsiu8Di2 5WJRBpGbWreHmBLv1QwdCJ6WEOx6Byg2y4bs1pJHSL/QxFdUSMRLMmQoU zqAIaYQIQN8xNHfbCfy+xd8fbO9nuFZX8lU+vk+lIR/QLG/Pmd+lIBVeO A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8FAD7MzlKtJV2Y/2dsb2JhbABZgws4GT2MPq0DgRAWdIIsOlEBPkIlAgSIFw2aZalmF48MhDcEmBeBMJBlgy2CKg X-IronPort-AV: E=Sophos;i="4.95,631,1384300800"; d="scan'208";a="296382186" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 09 Jan 2014 16:23:48 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s09GNmhf016050 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 9 Jan 2014 16:23:48 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.37]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Thu, 9 Jan 2014 10:23:47 -0600 From: "Reinaldo Penno (repenno)" To: "sfc@ietf.org" Thread-Topic: Yang model for SFC Thread-Index: AQHPDVcsXlQWvjkBG0m02wJUMgIr/g== Date: Thu, 9 Jan 2014 16:23:47 +0000 Message-ID: In-Reply-To: <036a01cf0c8d$099b52d0$1cd1f870$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.220.52] Content-Type: text/plain; charset="us-ascii" Content-ID: <95672EF442BCCF49B406D90CEE6C28CF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sfc] Yang model for SFC X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 16:24:03 -0000 Hi, we submitted a draft reflecting our thoughts and efforts on the area of Yang and SFC http://tools.ietf.org/html/draft-penno-sfc-yang-00 Thanks, Reinaldo From narten@us.ibm.com Fri Jan 10 14:25:20 2014 Return-Path: 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 B13681AE17A for ; Fri, 10 Jan 2014 14:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.439 X-Spam-Level: X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, 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 yLSenGdzp2u4 for ; Fri, 10 Jan 2014 14:25:17 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5101AE1BC for ; Fri, 10 Jan 2014 14:25:13 -0800 (PST) Received: from /spool/local by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 10 Jan 2014 15:25:03 -0700 Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e35.co.us.ibm.com (192.168.1.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 10 Jan 2014 15:25:01 -0700 Received: from b03cxnp07027.gho.boulder.ibm.com (b03cxnp07027.gho.boulder.ibm.com [9.17.130.14]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id CB8D919D8046 for ; Fri, 10 Jan 2014 15:24:51 -0700 (MST) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by b03cxnp07027.gho.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s0AMOl4F8913228 for ; Fri, 10 Jan 2014 23:24:47 +0100 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id s0AMSEgh009354 for ; Fri, 10 Jan 2014 15:28:14 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-48-103-77.mts.ibm.com [9.48.103.77]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id s0AMSDwe009330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Jan 2014 15:28:14 -0700 Received: from cichlid.raleigh.ibm.com.us.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id s0AMOwQJ023972; Fri, 10 Jan 2014 17:24:58 -0500 Date: Fri, 10 Jan 2014 17:24:58 -0500 Message-ID: From: Thomas Narten To: adrian@olddog.co.uk In-Reply-To: <024901cf00d3$33bd7ef0$9b387cd0$@olddog.co.uk> References: <024901cf00d3$33bd7ef0$9b387cd0$@olddog.co.uk> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/23.1 (x86_64-redhat-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14011022-6688-0000-0000-000005677785 Cc: sfc@ietf.org Subject: Re: [sfc] [nsc] Time to get to work! X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 22:25:20 -0000 Thanks Adrian for all your help getting this WG chartered! WG: We've got plenty of work to do, and we're pleased to see that folk are already getting to it (a number of new and revised IDs have appeared). Just to recap where we are, our milestones are as follows: Goals and Milestones: Apr 2014 - Submit to IESG Information document defining the SFC problem statement and core use cases Apr 2014 - Consult with OPS area on possible SFC charter modifications for management and configuration of SFC components related to the support of Service Function Chaining Jan 2015 - Submit to IESG Informational document defining the architecture for SFC Jan 2015 - Informational document defining the control plane requirements for conveying information between control or management elements and SFC implementation points Aug 2015 - Submit to IESG Standards Track document specifying the generic service function chaining header encapsulation With that in mind, our highest priority items for the short term are: 1) Finish the problem statement document. 2) Start working out the architecture. 3) Begin figuring out what the WG wants to do with regards to "management" and/or the "control plane" that relates to the Service Function instances and how they are to learn how they are to process the packets that traverse them relating to specific service function chains. Once we have a better idea of what work is needed here, we will go back sync up with the ADs on how best to do the work. We'll be sending followup notes on the individual topics, but feel free to chime in with thoughts/ideas on what our priorities should be. Jim & Thomas From narten@us.ibm.com Fri Jan 10 14:34:02 2014 Return-Path: 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 76CE41AE1D1 for ; Fri, 10 Jan 2014 14:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.439 X-Spam-Level: X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, 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 SnC0AhJd9R4O for ; Fri, 10 Jan 2014 14:34:00 -0800 (PST) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id A91611ACCF2 for ; Fri, 10 Jan 2014 14:34:00 -0800 (PST) Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 10 Jan 2014 17:33:50 -0500 Received: from d01dlp01.pok.ibm.com (9.56.250.166) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 10 Jan 2014 17:33:47 -0500 Received: from b01cxnp23034.gho.pok.ibm.com (b01cxnp23034.gho.pok.ibm.com [9.57.198.29]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 5726E38C803B for ; Fri, 10 Jan 2014 17:33:47 -0500 (EST) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by b01cxnp23034.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s0AMXl0Q4522340 for ; Fri, 10 Jan 2014 22:33:47 GMT Received: from d01av04.pok.ibm.com (localhost [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s0AMXkBK007411 for ; Fri, 10 Jan 2014 17:33:46 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-48-103-77.mts.ibm.com [9.48.103.77]) by d01av04.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s0AMXjNG007365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Jan 2014 17:33:46 -0500 Received: from cichlid.raleigh.ibm.com.us.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id s0AMXimH025254 for ; Fri, 10 Jan 2014 17:33:44 -0500 Date: Fri, 10 Jan 2014 17:33:44 -0500 Message-ID: From: Thomas Narten To: sfc@ietf.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/23.1 (x86_64-redhat-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14011022-7182-0000-0000-00000986C087 Subject: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 22:34:02 -0000 WG: Our highest-priority WG deliverable is getting a problem statement done. As has been discussed before, draft-quinn-sfc-problem-statement-02.txt has been the main candidate and has been the basis for getting this WG chartered. With that in mind, this is a call for WG adoption of the documment. Please note: 1) This is not WG Last Call. The document is not final, and the WG is expected to modify the document's content until there is WG consensus that the content is solid. So please don't oppose adoption just because you want to see changes to its content. 2) If you have objections to adoption of the document, please state your reasons why, and explain what it would take to address your concerns. 3) If you have issues with the content, by all means raise those issues and we can begin a dialog about how best to address those issues. Thomas & Jim From tnadeau@lucidvision.com Fri Jan 10 14:39:12 2014 Return-Path: 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 C30B21AE1D4 for ; Fri, 10 Jan 2014 14:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 zKyOYr0MiJQ4 for ; Fri, 10 Jan 2014 14:39:09 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF7B1ACCF2 for ; Fri, 10 Jan 2014 14:39:09 -0800 (PST) Received: from [192.168.1.113] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id D0E4926AFB96; Fri, 10 Jan 2014 17:38:58 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_D0A1EBB1-B867-4ADF-A6FE-812A30A4C0BA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: Date: Fri, 10 Jan 2014 17:38:58 -0500 Message-Id: References: To: Thomas Narten X-Mailer: Apple Mail (2.1827) Cc: sfc@ietf.org Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 22:39:13 -0000 --Apple-Mail=_D0A1EBB1-B867-4ADF-A6FE-812A30A4C0BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I believe this draft is a good place to start. I feel the = document has the right spirit and sections for the WG to chew on. It = also has already had significant input from the NSC community as well, = and so I think represents a good view of what the general community is = looking for.=20 --Tom > WG: >=20 > Our highest-priority WG deliverable is getting a problem statement > done. As has been discussed before, > draft-quinn-sfc-problem-statement-02.txt has been the main candidate > and has been the basis for getting this WG chartered. >=20 > With that in mind, this is a call for WG adoption of the documment. >=20 > Please note: >=20 > 1) This is not WG Last Call. The document is not final, and the WG is > expected to modify the document's content until there is WG consensus > that the content is solid. So please don't oppose adoption just > because you want to see changes to its content. >=20 > 2) If you have objections to adoption of the document, please state > your reasons why, and explain what it would take to address your > concerns. >=20 > 3) If you have issues with the content, by all means raise those > issues and we can begin a dialog about how best to address those > issues. >=20 > Thomas & Jim >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc >=20 --Apple-Mail=_D0A1EBB1-B867-4ADF-A6FE-812A30A4C0BA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJS0HaCAAoJEPcO+I7eiUJZEaYQALSrXjeh/NFnQR2x6tCfqngS Lv9U+QxSm48i4d4RgypoWSjHZ4SLB+390RxLBBzbrjoyoCkA/k1XO5QWZUzA2mwo iZ4GMq1kqatVlkVnr+HyhWKwiBzumwqddqzzcQ6KiL0UrckAg2jxhCuq8LZTmHZe KyGwXWNJ2I5U0wiEcMZS/Y1Y2rzXP7pDXzExckkhXCQFeP4rTDjCZlYjigp6B6S4 noYswN0niEhMZDMbO0ZTTRPG+i2nZRx2MeryPKuKL+c31E5tAmtvU/qDtShNSyZ+ fqUIi/M8SQ2U17BbcBnOvhyvS8vuOmumTj7qS4IBFfxQNGYSZ2t+ftV75pqLXxpl sAArJj1jfDkP1zh50Xw/l7a/vskpL7GKOFK3BX5YiwnneNEJFc2bu00a7l3R3U8R ZJWJKMu1YnjjRnoGLjcgOdCX8dnogGhMR0PeOmOSWIc1P6WvYcbXTm32tXq9htQ7 fbzAciMHt6jGNp5nDlD8jDUDRGLRDvcP5FLcO5ZYYTKUZUdvos1/sUdCugT4M56P HXknB4nWZ04MRzvnoOE4H3hUKYuB5l2lZgvLjXZSdAlph2i/9GGIAo5q2FkD9llM PBMxx9uTIhEAt9wKRNhl42jv4eJvWryr3riMgeLwzyMfDUwoeB/kLTx5+jXajsZ3 mfFyURel/oJ1unL+ebF9 =g31C -----END PGP SIGNATURE----- --Apple-Mail=_D0A1EBB1-B867-4ADF-A6FE-812A30A4C0BA-- From cpignata@cisco.com Fri Jan 10 17:15:52 2014 Return-Path: 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 D3E741AD8F0 for ; Fri, 10 Jan 2014 17:15:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 B2e4j_nk8Q0N for ; Fri, 10 Jan 2014 17:15:47 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id DA1921A1F76 for ; Fri, 10 Jan 2014 17:15:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2318; q=dns/txt; s=iport; t=1389402937; x=1390612537; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=J5npdgI8W3UXEfhMua7X5IIPvNGDJHy/Lk9pSRZHEvk=; b=XTkG2WBeNlQACRoz6zTA6aO8rsuzedoVSJvy/g4IerfMU11mPd6WpVp1 JG0RXtpbj9sPeQ5ZC1zyWN0/Pdu+fk6TfxrKZh6RR9xGHnUUnQpyPIhPE 40ZvSI7GeRreAOILDNmTA+1EitoR0LR5xrvwDJmg5B8DUrhgVxi1y1ix9 s=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAIma0FKtJXHA/2dsb2JhbABZgws4VrlogQcWdIIlAQEBAwEBAQEaUQsFCwIBCEYnCyUCBA4FDoduCA3DEBMEjwcHgySBEwSQM4ExhjOSFYMtgio X-IronPort-AV: E=Sophos;i="4.95,641,1384300800"; d="asc'?scan'208";a="12047580" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-4.cisco.com with ESMTP; 11 Jan 2014 01:15:36 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0B1Fawp016316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 11 Jan 2014 01:15:36 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.76]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Fri, 10 Jan 2014 19:15:36 -0600 From: "Carlos Pignataro (cpignata)" To: Thomas Narten Thread-Topic: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt Thread-Index: AQHPDlQpqU69uwsdUEiCVBtIV+X0Upp/HSsA Date: Sat, 11 Jan 2014 01:15:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.50] Content-Type: multipart/signed; boundary="Apple-Mail=_4C06724F-8C1C-41A8-860F-B393E445C8C4"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 01:15:53 -0000 --Apple-Mail=_4C06724F-8C1C-41A8-860F-B393E445C8C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Chairs, I support the adoption of draft-quinn-sfc-problem-statement-02.txt as = the WG's problem statement document. In my view, draft-quinn-sfc-problem-statement-02.txt provides a great = starting point that has received much review and broad input. It also = contains an important reference definition of terms. After adoption, I = think we ought to decide what's the best approach for Section 4 and use = cases in general. Thanks, -- Carlos. On Jan 10, 2014, at 5:33 PM, Thomas Narten wrote: > WG: >=20 > Our highest-priority WG deliverable is getting a problem statement > done. As has been discussed before, > draft-quinn-sfc-problem-statement-02.txt has been the main candidate > and has been the basis for getting this WG chartered. >=20 > With that in mind, this is a call for WG adoption of the documment. >=20 > Please note: >=20 > 1) This is not WG Last Call. The document is not final, and the WG is > expected to modify the document's content until there is WG consensus > that the content is solid. So please don't oppose adoption just > because you want to see changes to its content. >=20 > 2) If you have objections to adoption of the document, please state > your reasons why, and explain what it would take to address your > concerns. >=20 > 3) If you have issues with the content, by all means raise those > issues and we can begin a dialog about how best to address those > issues. >=20 > Thomas & Jim >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail=_4C06724F-8C1C-41A8-860F-B393E445C8C4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlLQmzQACgkQtfDPGTp3USyZOQCcDw3udg6bsQj1OSfF9Z9P2Nny WqsAnj7in6Nr5TUZ6GR4n60GiA4NbO0z =zA5S -----END PGP SIGNATURE----- --Apple-Mail=_4C06724F-8C1C-41A8-860F-B393E445C8C4-- From melinda.shore@gmail.com Fri Jan 10 19:23:29 2014 Return-Path: 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 B76771ADF7C for ; Fri, 10 Jan 2014 19:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 1VnYtbGotErK for ; Fri, 10 Jan 2014 19:23:27 -0800 (PST) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id D30681ADF79 for ; Fri, 10 Jan 2014 19:23:27 -0800 (PST) Received: by mail-pb0-f54.google.com with SMTP id un15so5211546pbc.13 for ; Fri, 10 Jan 2014 19:23:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=dEGzBZYaBLAPDwKlX7mf+pM3cmG3NGa0JCLwSAA6hK0=; b=bBXagELzumDhcU5GiXWWwlbFqG+1m3HgK0X+meRF4LH2IHIgR346wfhTKye4HyIa2B ueO3maJUbTfStBu1WddU7Bkg6Km8SB4rkEQCo2V1wjmT1f5LOc9k5s+a0AgChXyoosxS IKKuoBBo6UrJ1R7lj4KYepxzSSm/DoYFhMey++HaGT1tiqb12Gj5H5wdTY8YQToCP0o9 a5OIcBVWeQCOJQD7+1VPEJss1JVuXxpYGiWUfPhr3wpdZgr+X6xozB5rkqZhFM1uVVE2 51d4tKrOTTtZ5ELD0NtVVXcrDz9+vul2v0IglNv36dd0ii+B/paiQBNlnZWIc30vYJsb WjxA== X-Received: by 10.66.221.103 with SMTP id qd7mr15791137pac.44.1389410597794; Fri, 10 Jan 2014 19:23:17 -0800 (PST) Received: from spandex.local (69-161-17-63-rb2.fai.dsl.dynamic.acsalaska.net. [69.161.17.63]) by mx.google.com with ESMTPSA id er3sm20803418pbb.40.2014.01.10.19.23.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 Jan 2014 19:23:16 -0800 (PST) Message-ID: <52D0B921.6060903@gmail.com> Date: Fri, 10 Jan 2014 18:23:13 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: sfc@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 03:23:29 -0000 On 1/10/14 1:33 PM, Thomas Narten wrote: > With that in mind, this is a call for WG adoption of the documment. I think it's a very good start and I'm absolutely confident that the editors will be responsive to working group consensus. So yes, I support adoption. Melinda From diego@tid.es Sat Jan 11 11:37:59 2014 Return-Path: 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 B3F4A1ACCF2 for ; Sat, 11 Jan 2014 11:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.339 X-Spam-Level: X-Spam-Status: No, score=-3.339 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 fd4Yu58shd2U for ; Sat, 11 Jan 2014 11:37:57 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 32D541ACCE5 for ; Sat, 11 Jan 2014 11:37:57 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MZ900A5A56XFO@tid.hi.inet> for sfc@ietf.org; Sat, 11 Jan 2014 20:37:45 +0100 (MET) Received: from dequeue_removeroute (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id CF.F0.03314.98D91D25; Sat, 11 Jan 2014 20:37:45 +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 ESMTP id <0MZ900A5756XFO@tid.hi.inet> for sfc@ietf.org; Sat, 11 Jan 2014 20:37:45 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.204]) by EX10-HTCAS6-MAD.hi.inet ([::1]) with mapi id 14.03.0158.001; Sat, 11 Jan 2014 20:37:45 +0100 Date: Sat, 11 Jan 2014 19:37:44 +0000 From: "Diego R. Lopez" In-reply-to: <52D0B921.6060903@gmail.com> X-Originating-IP: [10.95.64.115] To: "sfc@ietf.org" Message-id: Content-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt Thread-index: AQHPDlQNl/jpdQy/nk6xb5u/o7QpqJp+y3+AgAEQUoA= X-AuditID: 0a5f4068-b7fe58e000000cf2-d6-52d19d893a96 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsXCFe/Apds592KQwbPfWhZPHmxld2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoXmgywFX3gqNv14xNzAeIKni5GTQ0LARGJjYxMbhC0mceHe ejBbSOAAo8Td9ypdjFxA9ldGiadXlzFCODMZJd5cncECUsUioCrx8+4JMJsNyH7U/JsdxBYW CJXovg4xlVNAU2LTjF2MEBsUJP6cewxWLyKgKHHu5QQgm4ODV8BSonu3OkiYWcBM4tyOycwg Nq+AoMSPyffASpgF1CWmTMmFKBGXaG69yQJhK0pMW9QANp1RQFbi3fz5rBDTwySub2iE2mQl cXHSZ1aICwQkluw5zwxhi0q8fPyPFeJfL4mmbR+YJjCKz0JyxSwkV8xCuGIWkitmIbliASPr Kkax4qSizPSMktzEzJx0A0O9jEy9zLzUkk2MkMjK2MG4fKfKIUYBDkYlHt4PXBeChFgTy4or cw8xSnAwK4nwTo68GCTEm5JYWZValB9fVJqTWnyIkYmDU6qBcTuzZHBzVsjFx+0p2r//zbdZ dmFqzOJb6nlfU/2eBXKxMjLNis2Ivryq628O01Vr6WvhgpvqmReJt6yfL1zlXlDabfZQMlfv zOavB+Uu/30Q17D4atz2bIaek4FtR3//OpkjINGd75bIaLA8MUNn+QxOPpvCJhOF+oaGwxP2 mG3afk1pnU+LEktxRqKhFnNRcSIA6NINdooCAAA= References: <52D0B921.6060903@gmail.com> Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 19:37:59 -0000 SSBmdWxseSBhZ3JlZSB3aXRoIE1lbGluZGEgb24gdGhpcy4gSSBzdXBwb3J0IGFkb3B0aW9uLg0K DQpCZSBnb29kZSwNCg0KT24gMTEgSmFuIDIwMTQsIGF0IDA0OjIzICwgTWVsaW5kYSBTaG9yZSA8 bWVsaW5kYS5zaG9yZUBnbWFpbC5jb20+IHdyb3RlOg0KDQo+IE9uIDEvMTAvMTQgMTozMyBQTSwg VGhvbWFzIE5hcnRlbiB3cm90ZToNCj4+IFdpdGggdGhhdCBpbiBtaW5kLCB0aGlzIGlzIGEgY2Fs bCBmb3IgV0cgYWRvcHRpb24gb2YgdGhlIGRvY3VtbWVudC4NCj4NCj4gSSB0aGluayBpdCdzIGEg dmVyeSBnb29kIHN0YXJ0IGFuZCBJJ20gYWJzb2x1dGVseSBjb25maWRlbnQgdGhhdCB0aGUNCj4g ZWRpdG9ycyB3aWxsIGJlIHJlc3BvbnNpdmUgdG8gd29ya2luZyBncm91cCBjb25zZW5zdXMuICBT byB5ZXMsDQo+IEkgc3VwcG9ydCBhZG9wdGlvbi4NCj4NCj4gTWVsaW5kYQ0KPg0KPg0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzZmMgbWFpbGlu ZyBsaXN0DQo+IHNmY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYw0KDQoNCi0tDQoiRXN0YSB2ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmll cm5vIg0KDQpEciBEaWVnbyBSLiBMb3Bleg0KVGVsZWZvbmljYSBJK0QNCmh0dHA6Ly9wZW9wbGUu dGlkLmVzL2RpZWdvLmxvcGV6Lw0KDQplLW1haWw6IGRpZWdvQHRpZC5lcw0KVGVsOiAgICArMzQg OTEzIDEyOSAwNDENCk1vYmlsZTogKzM0IDY4MiAwNTEgMDkxDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoNCkVzdGUgbWVuc2FqZSBzZSBkaXJpZ2UgZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5h dGFyaW8uIFB1ZWRlIGNvbnN1bHRhciBudWVzdHJhIHBvbMOtdGljYSBkZSBlbnbDrW8geSByZWNl cGNpw7NuIGRlIGNvcnJlbyBlbGVjdHLDs25pY28gZW4gZWwgZW5sYWNlIHNpdHVhZG8gbcOhcyBh YmFqby4NClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3IgaXRzIGFkZHJl c3NlZS4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUg dGVybXMgc2V0IG91dCBhdDoNCmh0dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlzY2xhaW1l ci5hc3B4DQo= From mehmet.ersue@nsn.com Sat Jan 11 15:23:05 2014 Return-Path: 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 0EC171AD8EA for ; Sat, 11 Jan 2014 15:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 RgXfI3lv4HCe for ; Sat, 11 Jan 2014 15:23:03 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6581AD627 for ; Sat, 11 Jan 2014 15:23:02 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s0BNMovm005254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 12 Jan 2014 00:22:50 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s0BNMnQH024431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 12 Jan 2014 00:22:49 +0100 Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 12 Jan 2014 00:22:48 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.117]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0123.003; Sun, 12 Jan 2014 00:22:49 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Thomas Nadeau , Thomas Narten Thread-Topic: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt Thread-Index: AQHPDlQNcM3VV0zhb0SmhgcGn/4bdZp+fBQAgAGvP5A= Date: Sat, 11 Jan 2014 23:22:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1771 X-purgate-ID: 151667::1389482570-00001A6F-CC41F2B8/0-0/0-0 Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 23:23:05 -0000 +1 Mehmet=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of ext Thomas Nadeau > Sent: Friday, January 10, 2014 11:39 PM > To: Thomas Narten > Cc: sfc@ietf.org > Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem- > statement-02.txt >=20 >=20 > I believe this draft is a good place to start. I feel the > document has the right spirit and sections for the WG to chew on. It > also has already had significant input from the NSC community as well, > and so I think represents a good view of what the general community is > looking for. >=20 > --Tom >=20 >=20 > > WG: > > > > Our highest-priority WG deliverable is getting a problem statement > > done. As has been discussed before, > > draft-quinn-sfc-problem-statement-02.txt has been the main candidate > > and has been the basis for getting this WG chartered. > > > > With that in mind, this is a call for WG adoption of the documment. > > > > Please note: > > > > 1) This is not WG Last Call. The document is not final, and the WG is > > expected to modify the document's content until there is WG consensus > > that the content is solid. So please don't oppose adoption just > > because you want to see changes to its content. > > > > 2) If you have objections to adoption of the document, please state > > your reasons why, and explain what it would take to address your > > concerns. > > > > 3) If you have issues with the content, by all means raise those > > issues and we can begin a dialog about how best to address those > > issues. > > > > Thomas & Jim > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > From seils@cisco.com Sat Jan 11 16:24:52 2014 Return-Path: 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 292B11AD8EE for ; Sat, 11 Jan 2014 16:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 dclPAq7nUots for ; Sat, 11 Jan 2014 16:24:50 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 4998D1A1F3E for ; Sat, 11 Jan 2014 16:24:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3461; q=dns/txt; s=iport; t=1389486280; x=1390695880; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sjryjA0h9+gUM3XfuptdHZo4QGZ75xLkVvw+5YaGFBc=; b=MlGqkZHV7cZXonc0eEpotnX0n6H+yjRJr7WGHGpgw/0fP8EW5cREd8/V ESvJA+8Es/gIvax+ZLiJ5YDsBKt6b7aVeLaUnKw4O9I1UMw4lQmVwK/Op CXTZJjQ0iV4ZkuQw2SUen4HUORBjaS1K6/YBjNlh6Ybv9tLLOjTyGqtCz 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFAPbf0VKtJXG9/2dsb2JhbABagkdEOLo8gQcWdIImAQEEAQEBGhBBCxACAQgEHiQnCyUCBA4FCId8DcNaEwSOVi0EB4MkgRMEqiyDLQ X-IronPort-AV: E=Sophos;i="4.95,645,1384300800"; d="scan'208,217";a="12192066" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-7.cisco.com with ESMTP; 12 Jan 2014 00:24:38 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0C0OcU5003406 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 12 Jan 2014 00:24:38 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.212]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Sat, 11 Jan 2014 18:24:38 -0600 From: "Zach Seils (seils)" To: Thomas Narten Thread-Topic: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt Thread-Index: AQHPDlQenmLEeKE1XUCA1C6uN6BB7ZqAPLKa Date: Sun, 12 Jan 2014 00:24:37 +0000 Message-ID: <4FF6CF4D6CDC5C4D9B1AE073B14B040D0AA296D8@xmb-aln-x14.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4FF6CF4D6CDC5C4D9B1AE073B14B040D0AA296D8xmbalnx14ciscoc_" MIME-Version: 1.0 Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 00:24:52 -0000 --_000_4FF6CF4D6CDC5C4D9B1AE073B14B040D0AA296D8xmbalnx14ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support adoption of draft-quinn-sfc-problem-statement-02. Thanks, Zach On Jan 10, 2014 5:34 PM, Thomas Narten wrote: WG: Our highest-priority WG deliverable is getting a problem statement done. As has been discussed before, draft-quinn-sfc-problem-statement-02.txt has been the main candidate and has been the basis for getting this WG chartered. With that in mind, this is a call for WG adoption of the documment. Please note: 1) This is not WG Last Call. The document is not final, and the WG is expected to modify the document's content until there is WG consensus that the content is solid. So please don't oppose adoption just because you want to see changes to its content. 2) If you have objections to adoption of the document, please state your reasons why, and explain what it would take to address your concerns. 3) If you have issues with the content, by all means raise those issues and we can begin a dialog about how best to address those issues. Thomas & Jim _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_4FF6CF4D6CDC5C4D9B1AE073B14B040D0AA296D8xmbalnx14ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support adoption of draft-quinn-sfc-problem-statement-02.<= /p>

Thanks,
Zach

On Jan 10, 2014 5:34 PM, Thomas Narten <narten@us= .ibm.com> wrote:
WG:

Our highest-priority WG deliverable is getting a problem statement
done. As has been discussed before,
draft-quinn-sfc-problem-statement-02.txt has been the main candidate
and has been the basis for getting this WG chartered.

With that in mind, this is a call for WG adoption of the documment.

Please note:

1) This is not WG Last Call. The document is not final, and the WG is
expected to modify the document's content until there is WG consensus
that the content is solid. So please don't oppose adoption just
because you want to see changes to its content.

2) If you have objections to adoption of the document, please state
your reasons why, and explain what it would take to address your
concerns.

3) If you have issues with the content, by all means  raise those
issues and we can begin a dialog about how best to address those
issues.

Thomas & Jim

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/= mailman/listinfo/sfc
 --_000_4FF6CF4D6CDC5C4D9B1AE073B14B040D0AA296D8xmbalnx14ciscoc_-- From christian.jacquenet@orange.com Sun Jan 12 01:38:41 2014 Return-Path: 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 882B71AD8ED for ; Sun, 12 Jan 2014 01:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 x0t5yquaiutt for ; Sun, 12 Jan 2014 01:38:39 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 91FCE1AC8F5 for ; Sun, 12 Jan 2014 01:38:38 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 4591D22C360; Sun, 12 Jan 2014 10:38:27 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 2A3DE23805C; Sun, 12 Jan 2014 10:38:27 +0100 (CET) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Sun, 12 Jan 2014 10:38:27 +0100 From: To: Thomas Narten , "sfc@ietf.org" Date: Sun, 12 Jan 2014 10:38:27 +0100 Thread-Topic: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt Thread-Index: Ac8OVAz0+kQSNQgCRTynipsqO32btQBJey7w Message-ID: <18237_1389519507_52D26293_18237_17572_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15EF81FE0D2@PUEXCB1C.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.12.45714 Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 09:38:41 -0000 WG, I support the adoption of draft-quinn-* as a sfc WG document. Cheers, Christian. -----Message d'origine----- De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas Narten Envoy=E9=A0: vendredi 10 janvier 2014 23:34 =C0=A0: sfc@ietf.org Objet=A0: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-0= 2.txt WG: Our highest-priority WG deliverable is getting a problem statement done. As= has been discussed before, draft-quinn-sfc-problem-statement-02.txt has be= en the main candidate and has been the basis for getting this WG chartered. With that in mind, this is a call for WG adoption of the documment. Please note: 1) This is not WG Last Call. The document is not final, and the WG is expec= ted to modify the document's content until there is WG consensus that the c= ontent is solid. So please don't oppose adoption just because you want to s= ee changes to its content. 2) If you have objections to adoption of the document, please state your re= asons why, and explain what it would take to address your concerns. 3) If you have issues with the content, by all means raise those issues an= d we can begin a dialog about how best to address those issues. Thomas & Jim _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From bgreene@senki.org Sun Jan 12 04:44:35 2014 Return-Path: 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 37F2A1AE047 for ; Sun, 12 Jan 2014 04:44:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 NjlxXCmWDOj5 for ; Sun, 12 Jan 2014 04:44:33 -0800 (PST) Received: from smtp89.ord1c.emailsrvr.com (smtp89.ord1c.emailsrvr.com [108.166.43.89]) by ietfa.amsl.com (Postfix) with ESMTP id 38CC41AD738 for ; Sun, 12 Jan 2014 04:44:27 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp4.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 97206141C2D; Sun, 12 Jan 2014 07:44:16 -0500 (EST) X-Virus-Scanned: OK Received: by smtp4.relay.ord1c.emailsrvr.com (Authenticated sender: bgreene-AT-senki.org) with ESMTPSA id B8C1D141C94; Sun, 12 Jan 2014 07:44:13 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Barry Greene In-Reply-To: Date: Sun, 12 Jan 2014 19:43:54 +0700 Content-Transfer-Encoding: quoted-printable Message-Id: <85B0A245-27CF-42E5-913B-F604C960C838@senki.org> References: To: "Carlos Pignataro (cpignata)" X-Mailer: Apple Mail (2.1827) Cc: Thomas Narten , "sfc@ietf.org" Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 12:44:35 -0000 +1 On Jan 11, 2014, at 8:15 AM, Carlos Pignataro (cpignata) = wrote: > Chairs, >=20 > I support the adoption of draft-quinn-sfc-problem-statement-02.txt as = the WG's problem statement document. >=20 > In my view, draft-quinn-sfc-problem-statement-02.txt provides a great = starting point that has received much review and broad input. It also = contains an important reference definition of terms. After adoption, I = think we ought to decide what's the best approach for Section 4 and use = cases in general. >=20 > Thanks, >=20 > -- Carlos. >=20 > On Jan 10, 2014, at 5:33 PM, Thomas Narten wrote: >=20 >> WG: >>=20 >> Our highest-priority WG deliverable is getting a problem statement >> done. As has been discussed before, >> draft-quinn-sfc-problem-statement-02.txt has been the main candidate >> and has been the basis for getting this WG chartered. >>=20 >> With that in mind, this is a call for WG adoption of the documment. >>=20 >> Please note: >>=20 >> 1) This is not WG Last Call. The document is not final, and the WG is >> expected to modify the document's content until there is WG consensus >> that the content is solid. So please don't oppose adoption just >> because you want to see changes to its content. >>=20 >> 2) If you have objections to adoption of the document, please state >> your reasons why, and explain what it would take to address your >> concerns. >>=20 >> 3) If you have issues with the content, by all means raise those >> issues and we can begin a dialog about how best to address those >> issues. >>=20 >> Thomas & Jim >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From mmorrow@cisco.com Sun Jan 12 07:17:53 2014 Return-Path: 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 EF1901ADF85 for ; Sun, 12 Jan 2014 07:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 M5EbRBKcFQ-b for ; Sun, 12 Jan 2014 07:17:48 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2891ADF83 for ; Sun, 12 Jan 2014 07:17:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2260; q=dns/txt; s=iport; t=1389539857; x=1390749457; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IVHrmDr9lMP6UAqOb6Mvdfiw0hAQmlSDVEBwoQqY0Mc=; b=kVV0zmP+TYx6rFDK0+SNUHk8I+M0Lne1M0AGxpIsHr21Dbt14jldEQ9b o80WR7YWYx7jv/fc3IR0Hoss016CpgM+09YoV2rLcELSGrLu6tuj5r88n 6NEXaGxAM9RiEJ1O/DEMVu3YuKVVhNp45mvCvvU70DdDH8AxEIMeTT9T1 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAL6x0lKtJV2b/2dsb2JhbABagws4uj6BBhZ0giUBAQEDAQEBARodNAsFCwIBCA4KHhAnCyUCBA4Fh3wIDcQZEwSOVDMHgySBEwSYF5IVgy0 X-IronPort-AV: E=Sophos;i="4.95,647,1384300800"; d="scan'208";a="12272231" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP; 12 Jan 2014 15:17:36 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0CFHarp007880 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 12 Jan 2014 15:17:36 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.125]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Sun, 12 Jan 2014 09:17:35 -0600 From: "Monique Morrow (mmorrow)" To: Barry Greene Thread-Topic: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt Thread-Index: AQHPD5Pzl/jpdQy/nk6xb5u/o7QpqJqBM69K Date: Sun, 12 Jan 2014 15:17:34 +0000 Message-ID: References: , <85B0A245-27CF-42E5-913B-F604C960C838@senki.org> In-Reply-To: <85B0A245-27CF-42E5-913B-F604C960C838@senki.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "Carlos Pignataro \(cpignata\)" , "sfc@ietf.org" Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 15:17:54 -0000 +1 Monique Sent from my iPhone > On 12.01.2014, at 14:44, "Barry Greene" wrote: >=20 >=20 > +1 >=20 >=20 >> On Jan 11, 2014, at 8:15 AM, Carlos Pignataro (cpignata) wrote: >>=20 >> Chairs, >>=20 >> I support the adoption of draft-quinn-sfc-problem-statement-02.txt as th= e WG's problem statement document. >>=20 >> In my view, draft-quinn-sfc-problem-statement-02.txt provides a great st= arting point that has received much review and broad input. It also contain= s an important reference definition of terms. After adoption, I think we ou= ght to decide what's the best approach for Section 4 and use cases in gener= al. >>=20 >> Thanks, >>=20 >> -- Carlos. >>=20 >>> On Jan 10, 2014, at 5:33 PM, Thomas Narten wrote: >>>=20 >>> WG: >>>=20 >>> Our highest-priority WG deliverable is getting a problem statement >>> done. As has been discussed before, >>> draft-quinn-sfc-problem-statement-02.txt has been the main candidate >>> and has been the basis for getting this WG chartered. >>>=20 >>> With that in mind, this is a call for WG adoption of the documment. >>>=20 >>> Please note: >>>=20 >>> 1) This is not WG Last Call. The document is not final, and the WG is >>> expected to modify the document's content until there is WG consensus >>> that the content is solid. So please don't oppose adoption just >>> because you want to see changes to its content. >>>=20 >>> 2) If you have objections to adoption of the document, please state >>> your reasons why, and explain what it would take to address your >>> concerns. >>>=20 >>> 3) If you have issues with the content, by all means raise those >>> issues and we can begin a dialog about how best to address those >>> issues. >>>=20 >>> Thomas & Jim >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From agmalis@gmail.com Sun Jan 12 07:26:56 2014 Return-Path: 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 CBEA01ADF24 for ; Sun, 12 Jan 2014 07:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 TVL8w3dS3tIT for ; Sun, 12 Jan 2014 07:26:54 -0800 (PST) Received: from mail-qe0-x232.google.com (mail-qe0-x232.google.com [IPv6:2607:f8b0:400d:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id B31FA1ADE72 for ; Sun, 12 Jan 2014 07:26:54 -0800 (PST) Received: by mail-qe0-f50.google.com with SMTP id 1so6338203qec.9 for ; Sun, 12 Jan 2014 07:26:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=GzoNYiHcx0bNhAhFMBOdQDnPHFC1tW4jGfhqFNieoR4=; b=nx/N0WqGuZaKeKbm0qS9ns28S1eC1v/rFE/4DrBk5KdpoGqXeproWWqMg0fBHpUSso rnnm2mxe+JQEhxATVdT35H/KYRHNpvml5xfa4Xfjf/saCot65jMkQyQA+TVOQgsWGJhg DYkwsa0DHZf23wftEb5aYnOveggiTfKpdn3gL1vexiVfE4DC3EERPYWmE0xNTMpEmUZw 4VDXNFcjxRZlS4mFQM4cvLPpjkSYlHfRAysfiPPUfJ5SDkWWU6elZA79V/87xn0oeZMQ +nQlH52zXAftKqdKz30DWEOQDQ6SiS9sR2rGoFRrMWn4MqKGz1u5H4RqyV+uKkZLmcsI ADIw== X-Received: by 10.224.166.70 with SMTP id l6mr30160749qay.25.1389540403987; Sun, 12 Jan 2014 07:26:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.120.130 with HTTP; Sun, 12 Jan 2014 07:26:23 -0800 (PST) In-Reply-To: References: <85B0A245-27CF-42E5-913B-F604C960C838@senki.org> From: "Andrew G. Malis" Date: Sun, 12 Jan 2014 10:26:23 -0500 Message-ID: To: "sfc@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 15:26:57 -0000 I also support adoption of the draft. Cheers, Andy On Sun, Jan 12, 2014 at 10:17 AM, Monique Morrow (mmorrow) wrote: > +1 > > Monique > > Sent from my iPhone > >> On 12.01.2014, at 14:44, "Barry Greene" wrote: >> >> >> +1 >> >> >>> On Jan 11, 2014, at 8:15 AM, Carlos Pignataro (cpignata) wrote: >>> >>> Chairs, >>> >>> I support the adoption of draft-quinn-sfc-problem-statement-02.txt as t= he WG's problem statement document. >>> >>> In my view, draft-quinn-sfc-problem-statement-02.txt provides a great s= tarting point that has received much review and broad input. It also contai= ns an important reference definition of terms. After adoption, I think we o= ught to decide what's the best approach for Section 4 and use cases in gene= ral. >>> >>> Thanks, >>> >>> -- Carlos. >>> >>>> On Jan 10, 2014, at 5:33 PM, Thomas Narten wrote: >>>> >>>> WG: >>>> >>>> Our highest-priority WG deliverable is getting a problem statement >>>> done. As has been discussed before, >>>> draft-quinn-sfc-problem-statement-02.txt has been the main candidate >>>> and has been the basis for getting this WG chartered. >>>> >>>> With that in mind, this is a call for WG adoption of the documment. >>>> >>>> Please note: >>>> >>>> 1) This is not WG Last Call. The document is not final, and the WG is >>>> expected to modify the document's content until there is WG consensus >>>> that the content is solid. So please don't oppose adoption just >>>> because you want to see changes to its content. >>>> >>>> 2) If you have objections to adoption of the document, please state >>>> your reasons why, and explain what it would take to address your >>>> concerns. >>>> >>>> 3) If you have issues with the content, by all means raise those >>>> issues and we can begin a dialog about how best to address those >>>> issues. >>>> >>>> Thomas & Jim >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From kegray@cisco.com Sun Jan 12 13:08:04 2014 Return-Path: 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 029D11ADFF3 for ; Sun, 12 Jan 2014 13:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 KozTUm2ZAmAz for ; Sun, 12 Jan 2014 13:08:02 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 66C031ADFD1 for ; Sun, 12 Jan 2014 13:08:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1758; q=dns/txt; s=iport; t=1389560872; x=1390770472; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=PexMOeUqopuKwYzVBgdJsWMuV5jURgxvlhsQQNWYpcg=; b=PxRIm9hZ0tbP7riySTtN5b4oypbLUK8dmd+jDVZ+i8Wn5tNLUoyP/ujS jVdzcp064HkPMJWGL8WhOm0b4qJYOWMdoHcccZku+l/leMkAePI7XzXj0 iuZFt5AFgtOntj2vET4RnNObUZQCw2Ngj8l2yyJTxqtgmQPjX8YGF60Z/ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAMID01KtJV2a/2dsb2JhbABagws4VrlogQgWdIIlAQEBBAEBARodNAsSAQgYHjcLJQIEAQ0FiAQNxBYTBI8HB4Q3BJgXkhWDLYIq X-IronPort-AV: E=Sophos;i="4.95,648,1384300800"; d="scan'208";a="12306683" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP; 12 Jan 2014 21:07:50 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0CL7oPI007964 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 12 Jan 2014 21:07:50 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.76]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Sun, 12 Jan 2014 15:07:50 -0600 From: "Ken Gray (kegray)" To: "Carlos Pignataro (cpignata)" , Thomas Narten Thread-Topic: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt Thread-Index: AQHPD9pZWbFliUAqUEeZ4gfXuUpYvA== Date: Sun, 12 Jan 2014 21:07:50 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.117.78] Content-Type: text/plain; charset="us-ascii" Content-ID: <446A9B7924CF4940BD08068AECAB4B71@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 21:08:04 -0000 +1 On 1/10/14 8:15 PM, "Carlos Pignataro (cpignata)" wrote: >Chairs, > >I support the adoption of draft-quinn-sfc-problem-statement-02.txt as the >WG's problem statement document. > >In my view, draft-quinn-sfc-problem-statement-02.txt provides a great >starting point that has received much review and broad input. It also >contains an important reference definition of terms. After adoption, I >think we ought to decide what's the best approach for Section 4 and use >cases in general. > >Thanks, > >-- Carlos. > >On Jan 10, 2014, at 5:33 PM, Thomas Narten wrote: > >> WG: >>=20 >> Our highest-priority WG deliverable is getting a problem statement >> done. As has been discussed before, >> draft-quinn-sfc-problem-statement-02.txt has been the main candidate >> and has been the basis for getting this WG chartered. >>=20 >> With that in mind, this is a call for WG adoption of the documment. >>=20 >> Please note: >>=20 >> 1) This is not WG Last Call. The document is not final, and the WG is >> expected to modify the document's content until there is WG consensus >> that the content is solid. So please don't oppose adoption just >> because you want to see changes to its content. >>=20 >> 2) If you have objections to adoption of the document, please state >> your reasons why, and explain what it would take to address your >> concerns. >>=20 >> 3) If you have issues with the content, by all means raise those >> issues and we can begin a dialog about how best to address those >> issues. >>=20 >> Thomas & Jim >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > From Ron_Parker@affirmednetworks.com Sun Jan 12 13:36:23 2014 Return-Path: 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 94AB51ACC85 for ; Sun, 12 Jan 2014 13:36:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 4qHF0MoqJFV9 for ; Sun, 12 Jan 2014 13:36:21 -0800 (PST) Received: from hub021-ca-7.exch021.serverdata.net (hub021-ca-7.exch021.serverdata.net [64.78.56.72]) by ietfa.amsl.com (Postfix) with ESMTP id C1F2F1A1DFA for ; Sun, 12 Jan 2014 13:36:21 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-7.exch021.domain.local ([10.254.4.109]) with mapi id 14.03.0158.001; Sun, 12 Jan 2014 13:36:10 -0800 From: Ron Parker To: "Carlos Pignataro (cpignata)" , Thomas Narten Thread-Topic: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt Thread-Index: AQHPDmqsW3BAHnHlE0mjJq2Yig1w7JqBniGA Date: Sun, 12 Jan 2014 21:36:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.20.29.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 21:36:23 -0000 All, I, too, am comfortable with draft-quinn-sfc-problem-statement-02 as the bas= is of our problem statement deliverable. Section 2, points 1-12 are nicel= y concise and to the point. =20 However, section 3 reads more like the beginnings of an architectural frame= work and not a problem statement. Without taking any position on the goo= dness of those items, might they be better expressed in an architectural do= cument? =20 Thanks. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpig= nata) Sent: Friday, January 10, 2014 8:16 PM To: Thomas Narten Cc: sfc@ietf.org Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statemen= t-02.txt Chairs, I support the adoption of draft-quinn-sfc-problem-statement-02.txt as the W= G's problem statement document. In my view, draft-quinn-sfc-problem-statement-02.txt provides a great start= ing point that has received much review and broad input. It also contains a= n important reference definition of terms. After adoption, I think we ought= to decide what's the best approach for Section 4 and use cases in general. Thanks, -- Carlos. On Jan 10, 2014, at 5:33 PM, Thomas Narten wrote: > WG: >=20 > Our highest-priority WG deliverable is getting a problem statement=20 > done. As has been discussed before,=20 > draft-quinn-sfc-problem-statement-02.txt has been the main candidate=20 > and has been the basis for getting this WG chartered. >=20 > With that in mind, this is a call for WG adoption of the documment. >=20 > Please note: >=20 > 1) This is not WG Last Call. The document is not final, and the WG is=20 > expected to modify the document's content until there is WG consensus=20 > that the content is solid. So please don't oppose adoption just=20 > because you want to see changes to its content. >=20 > 2) If you have objections to adoption of the document, please state=20 > your reasons why, and explain what it would take to address your=20 > concerns. >=20 > 3) If you have issues with the content, by all means raise those=20 > issues and we can begin a dialog about how best to address those=20 > issues. >=20 > Thomas & Jim >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From cpignata@cisco.com Sun Jan 12 13:55:34 2014 Return-Path: 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 43A051A1F06 for ; Sun, 12 Jan 2014 13:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 fjChZL6pIS3Z for ; Sun, 12 Jan 2014 13:55:32 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 356011A1F05 for ; Sun, 12 Jan 2014 13:55:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3991; q=dns/txt; s=iport; t=1389563721; x=1390773321; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jQc9cQ7wHVZURTw5Ip3VsJJVFb/Eq8/wrbPkX/N1NuQ=; b=l/cLpd+D7faU6eWUT47yYDGtifjECIGsvfQAczP3MWaVZ62sxHBziE2t t9gM1Q1W1Rd+pKmuOHBgMVZx2GgL/CMQbbdWykW3IT57qRQnqAuG/u44j b2u9AYwyBTx3V9VZyWvm/aY0vd15SGQfg3SczlqHAA/NjHzcy0sGPPzbQ 8=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAHgO01KtJXHA/2dsb2JhbABagws4VrlogQgWdIIlAQEBAwEBAQEaUQsFBwQCAQgRBAEBAScHJwsUCQgCBA4FDg2HYQgNxB0TBI5cKwcGgx6BEwSQM4ExhjOSFYMtgio X-IronPort-AV: E=Sophos;i="4.95,648,1384300800"; d="asc'?scan'208";a="12304741" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-2.cisco.com with ESMTP; 12 Jan 2014 21:55:21 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0CLtL99031088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 12 Jan 2014 21:55:21 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.76]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Sun, 12 Jan 2014 15:55:20 -0600 From: "Carlos Pignataro (cpignata)" To: Ron Parker Thread-Topic: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt Thread-Index: AQHPD95UHsqwP9zPck6q4osmWarTCpqCBswA Date: Sun, 12 Jan 2014 21:55:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.61.171.17] Content-Type: multipart/signed; boundary="Apple-Mail=_E504ED91-6ED2-41E1-AA4F-F53821614B33"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Thomas Narten , "sfc@ietf.org" Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 21:55:34 -0000 --Apple-Mail=_E504ED91-6ED2-41E1-AA4F-F53821614B33 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Ron, I think Section 3 is perfectly scoped for a problem statement document. = Basically, the flow is that Section 2 describes "aspects of existing = service deployments that are problematic", and then Section 3 = double-clicks on specific elements to address those aspects ("SFC will = investigate solutions that address the following elements"). It is perfectly fine for a problem description to include a model and a = catalog of areas to be addressed (i.e., this is the definition of the = areas of the problem statement). Further, a problem statement can = contain desired aspects of the solutions to those elements. Thanks, -- Carlos. On Jan 12, 2014, at 11:36 PM, Ron Parker = wrote: > All, >=20 > I, too, am comfortable with draft-quinn-sfc-problem-statement-02 as = the basis of our problem statement deliverable. Section 2, points 1-12 = are nicely concise and to the point. =20 >=20 > However, section 3 reads more like the beginnings of an architectural = framework and not a problem statement. Without taking any position on = the goodness of those items, might they be better expressed in an = architectural document? =20 >=20 > Thanks. >=20 > Ron >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro = (cpignata) > Sent: Friday, January 10, 2014 8:16 PM > To: Thomas Narten > Cc: sfc@ietf.org > Subject: Re: [sfc] Call for WG Adoption of = draft-quinn-sfc-problem-statement-02.txt >=20 > Chairs, >=20 > I support the adoption of draft-quinn-sfc-problem-statement-02.txt as = the WG's problem statement document. >=20 > In my view, draft-quinn-sfc-problem-statement-02.txt provides a great = starting point that has received much review and broad input. It also = contains an important reference definition of terms. After adoption, I = think we ought to decide what's the best approach for Section 4 and use = cases in general. >=20 > Thanks, >=20 > -- Carlos. >=20 > On Jan 10, 2014, at 5:33 PM, Thomas Narten wrote: >=20 >> WG: >>=20 >> Our highest-priority WG deliverable is getting a problem statement=20 >> done. As has been discussed before,=20 >> draft-quinn-sfc-problem-statement-02.txt has been the main candidate=20= >> and has been the basis for getting this WG chartered. >>=20 >> With that in mind, this is a call for WG adoption of the documment. >>=20 >> Please note: >>=20 >> 1) This is not WG Last Call. The document is not final, and the WG is=20= >> expected to modify the document's content until there is WG consensus=20= >> that the content is solid. So please don't oppose adoption just=20 >> because you want to see changes to its content. >>=20 >> 2) If you have objections to adoption of the document, please state=20= >> your reasons why, and explain what it would take to address your=20 >> concerns. >>=20 >> 3) If you have issues with the content, by all means raise those=20 >> issues and we can begin a dialog about how best to address those=20 >> issues. >>=20 >> Thomas & Jim >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >=20 --Apple-Mail=_E504ED91-6ED2-41E1-AA4F-F53821614B33 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlLTD0QACgkQtfDPGTp3USwwTwCg1gV5r9noBFUin8KoMHRC//c9 sFcAoLsMPy+oodTZtjkeUUkCRNGkCYpv =1oBw -----END PGP SIGNATURE----- --Apple-Mail=_E504ED91-6ED2-41E1-AA4F-F53821614B33-- From Ron_Parker@affirmednetworks.com Sun Jan 12 14:01:35 2014 Return-Path: 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 D994B1AE027 for ; Sun, 12 Jan 2014 14:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 jpl6LuXIOawl for ; Sun, 12 Jan 2014 14:01:33 -0800 (PST) Received: from hub021-ca-3.exch021.serverdata.net (hub021-ca-3.exch021.serverdata.net [64.78.22.170]) by ietfa.amsl.com (Postfix) with ESMTP id E65AE1A1F06 for ; Sun, 12 Jan 2014 14:01:33 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-3.exch021.domain.local ([10.254.4.36]) with mapi id 14.03.0158.001; Sun, 12 Jan 2014 14:01:22 -0800 From: Ron Parker To: "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt Thread-Index: AQHPDmqsW3BAHnHlE0mjJq2Yig1w7JqBniGAgACNHYD//3rLYA== Date: Sun, 12 Jan 2014 22:01:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.20.29.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "sfc@ietf.org" Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 22:01:36 -0000 Thanks, Carlos. If that is a typical approach, then I have no objections. =20 One suggestion for the document editors would be wrt section 3, item 2, Gen= eric Service Control Plane (GSCP). The concepts are fine by me, but intro= ducing this acronym here makes it sound like a specific control plane proto= col which has not yet been discussed by the group. This was where I start= ed thinking that this was beyond a problem statement. Ron -----Original Message----- From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]=20 Sent: Sunday, January 12, 2014 4:55 PM To: Ron Parker Cc: Thomas Narten; sfc@ietf.org Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statemen= t-02.txt Hi, Ron, I think Section 3 is perfectly scoped for a problem statement document. Bas= ically, the flow is that Section 2 describes "aspects of existing service d= eployments that are problematic", and then Section 3 double-clicks on speci= fic elements to address those aspects ("SFC will investigate solutions that= address the following elements"). It is perfectly fine for a problem description to include a model and a cat= alog of areas to be addressed (i.e., this is the definition of the areas of= the problem statement). Further, a problem statement can contain desired a= spects of the solutions to those elements. Thanks, -- Carlos. On Jan 12, 2014, at 11:36 PM, Ron Parker = wrote: > All, >=20 > I, too, am comfortable with draft-quinn-sfc-problem-statement-02 as the b= asis of our problem statement deliverable. Section 2, points 1-12 are nic= ely concise and to the point. =20 >=20 > However, section 3 reads more like the beginnings of an architectural fra= mework and not a problem statement. Without taking any position on the g= oodness of those items, might they be better expressed in an architectural = document? =20 >=20 > Thanks. >=20 > Ron >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro=20 > (cpignata) > Sent: Friday, January 10, 2014 8:16 PM > To: Thomas Narten > Cc: sfc@ietf.org > Subject: Re: [sfc] Call for WG Adoption of=20 > draft-quinn-sfc-problem-statement-02.txt >=20 > Chairs, >=20 > I support the adoption of draft-quinn-sfc-problem-statement-02.txt as the= WG's problem statement document. >=20 > In my view, draft-quinn-sfc-problem-statement-02.txt provides a great sta= rting point that has received much review and broad input. It also contains= an important reference definition of terms. After adoption, I think we oug= ht to decide what's the best approach for Section 4 and use cases in genera= l. >=20 > Thanks, >=20 > -- Carlos. >=20 > On Jan 10, 2014, at 5:33 PM, Thomas Narten wrote: >=20 >> WG: >>=20 >> Our highest-priority WG deliverable is getting a problem statement=20 >> done. As has been discussed before,=20 >> draft-quinn-sfc-problem-statement-02.txt has been the main candidate=20 >> and has been the basis for getting this WG chartered. >>=20 >> With that in mind, this is a call for WG adoption of the documment. >>=20 >> Please note: >>=20 >> 1) This is not WG Last Call. The document is not final, and the WG is=20 >> expected to modify the document's content until there is WG consensus=20 >> that the content is solid. So please don't oppose adoption just=20 >> because you want to see changes to its content. >>=20 >> 2) If you have objections to adoption of the document, please state=20 >> your reasons why, and explain what it would take to address your=20 >> concerns. >>=20 >> 3) If you have issues with the content, by all means raise those=20 >> issues and we can begin a dialog about how best to address those=20 >> issues. >>=20 >> Thomas & Jim >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >=20 From cpignata@cisco.com Sun Jan 12 14:14:27 2014 Return-Path: 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 5DD831A1F3F for ; Sun, 12 Jan 2014 14:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 loTyraUsgMRd for ; Sun, 12 Jan 2014 14:14:25 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id DC4961A1F02 for ; Sun, 12 Jan 2014 14:14:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5512; q=dns/txt; s=iport; t=1389564854; x=1390774454; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kNpOTlFVoK/I36KWtIya5PszcUCeVnEf7PNLYyYwZsw=; b=mna2KTatWv8oMDdcJUuBnWMp+c+txrf+6+0WFXFlr+RkChUs64qmrtuj Pm2oO9Q3zCjBnX4re6rwNMGI8TwBZM5vb09xB4drhxYNMxkbCHL/5BCeB u4fhxiMX+ywraWGl/5999P7Yr1w7SCVxujLLAk2U31uKRpZVnxbyzUF2l E=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAHIS01KtJXG9/2dsb2JhbABagws4VrlogQgWdIIlAQEBAwEBAQEaUQsFBwQCAQgRBAEBAScHJwsUCQgCBA4FDg2HYQgNxB8XjlwrBwaDHoETBJAzgTGGM4EwkGWDLYIq X-IronPort-AV: E=Sophos;i="4.95,648,1384300800"; d="asc'?scan'208";a="296826179" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 12 Jan 2014 22:14:14 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0CMEDMY027699 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 12 Jan 2014 22:14:13 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.76]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Sun, 12 Jan 2014 16:14:13 -0600 From: "Carlos Pignataro (cpignata)" To: Ron Parker Thread-Topic: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt Thread-Index: AQHPD95UHsqwP9zPck6q4osmWarTCpqCBswAgAABtQCAAAOSgA== Date: Sun, 12 Jan 2014 22:14:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.61.171.17] Content-Type: multipart/signed; boundary="Apple-Mail=_23CAF200-4465-4D0B-86BE-DC5F48402011"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Thomas Narten , "sfc@ietf.org" Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 22:14:27 -0000 --Apple-Mail=_23CAF200-4465-4D0B-86BE-DC5F48402011 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Ron, Please note that that specific nomenclature that you find confusing = (GSCP) was removed in the current version being polled for adoption: = http://tools.ietf.org/rfcdiff?url2=3Ddraft-quinn-sfc-problem-statement-02.= txt#diff0040 Enumerating elements (like a plane, a protocol, classification, or any = other) to anchor it as an area to architect/design, and even listing = their desired properties helps with describing the actual problem = statement with more specificity, I think. Thanks, -- Carlos. On Jan 13, 2014, at 12:01 AM, Ron Parker = wrote: > Thanks, Carlos. >=20 > If that is a typical approach, then I have no objections. =20 >=20 > One suggestion for the document editors would be wrt section 3, item = 2, Generic Service Control Plane (GSCP). The concepts are fine by me, = but introducing this acronym here makes it sound like a specific control = plane protocol which has not yet been discussed by the group. This was = where I started thinking that this was beyond a problem statement. >=20 > Ron >=20 >=20 > -----Original Message----- > From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]=20 > Sent: Sunday, January 12, 2014 4:55 PM > To: Ron Parker > Cc: Thomas Narten; sfc@ietf.org > Subject: Re: [sfc] Call for WG Adoption of = draft-quinn-sfc-problem-statement-02.txt >=20 > Hi, Ron, >=20 > I think Section 3 is perfectly scoped for a problem statement = document. Basically, the flow is that Section 2 describes "aspects of = existing service deployments that are problematic", and then Section 3 = double-clicks on specific elements to address those aspects ("SFC will = investigate solutions that address the following elements"). >=20 > It is perfectly fine for a problem description to include a model and = a catalog of areas to be addressed (i.e., this is the definition of the = areas of the problem statement). Further, a problem statement can = contain desired aspects of the solutions to those elements. >=20 > Thanks, >=20 > -- Carlos. >=20 > On Jan 12, 2014, at 11:36 PM, Ron Parker = wrote: >=20 >> All, >>=20 >> I, too, am comfortable with draft-quinn-sfc-problem-statement-02 as = the basis of our problem statement deliverable. Section 2, points 1-12 = are nicely concise and to the point. =20 >>=20 >> However, section 3 reads more like the beginnings of an architectural = framework and not a problem statement. Without taking any position on = the goodness of those items, might they be better expressed in an = architectural document? =20 >>=20 >> Thanks. >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro=20= >> (cpignata) >> Sent: Friday, January 10, 2014 8:16 PM >> To: Thomas Narten >> Cc: sfc@ietf.org >> Subject: Re: [sfc] Call for WG Adoption of=20 >> draft-quinn-sfc-problem-statement-02.txt >>=20 >> Chairs, >>=20 >> I support the adoption of draft-quinn-sfc-problem-statement-02.txt as = the WG's problem statement document. >>=20 >> In my view, draft-quinn-sfc-problem-statement-02.txt provides a great = starting point that has received much review and broad input. It also = contains an important reference definition of terms. After adoption, I = think we ought to decide what's the best approach for Section 4 and use = cases in general. >>=20 >> Thanks, >>=20 >> -- Carlos. >>=20 >> On Jan 10, 2014, at 5:33 PM, Thomas Narten wrote: >>=20 >>> WG: >>>=20 >>> Our highest-priority WG deliverable is getting a problem statement=20= >>> done. As has been discussed before,=20 >>> draft-quinn-sfc-problem-statement-02.txt has been the main candidate=20= >>> and has been the basis for getting this WG chartered. >>>=20 >>> With that in mind, this is a call for WG adoption of the documment. >>>=20 >>> Please note: >>>=20 >>> 1) This is not WG Last Call. The document is not final, and the WG = is=20 >>> expected to modify the document's content until there is WG = consensus=20 >>> that the content is solid. So please don't oppose adoption just=20 >>> because you want to see changes to its content. >>>=20 >>> 2) If you have objections to adoption of the document, please state=20= >>> your reasons why, and explain what it would take to address your=20 >>> concerns. >>>=20 >>> 3) If you have issues with the content, by all means raise those=20 >>> issues and we can begin a dialog about how best to address those=20 >>> issues. >>>=20 >>> Thomas & Jim >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>=20 >=20 --Apple-Mail=_23CAF200-4465-4D0B-86BE-DC5F48402011 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlLTE7EACgkQtfDPGTp3USytkwCgtTOVqLP4HlprrmHIvHzSHKwU IK4AoIRSqI+K2XA3WITA/HjgzLof1f9U =/FQ0 -----END PGP SIGNATURE----- --Apple-Mail=_23CAF200-4465-4D0B-86BE-DC5F48402011-- From haibin.song@huawei.com Sun Jan 12 19:00:22 2014 Return-Path: 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 E10091AD6B9 for ; Sun, 12 Jan 2014 19:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 Xc9imHa1njlz for ; Sun, 12 Jan 2014 19:00:21 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A78EF1AD8C4 for ; Sun, 12 Jan 2014 19:00:20 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCK66764; Mon, 13 Jan 2014 03:00:08 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Jan 2014 02:58:44 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Jan 2014 02:59:20 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Mon, 13 Jan 2014 10:59:16 +0800 From: "Songhaibin (A)" To: "Andrew G. Malis" , "sfc@ietf.org" Thread-Topic: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt Thread-Index: AQHPD6q8buXORwiPAEuXdHjzVRaKK5qB9bnQ Date: Mon, 13 Jan 2014 02:59:15 +0000 Message-ID: References: <85B0A245-27CF-42E5-913B-F604C960C838@senki.org> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 03:00:23 -0000 I read this document in detail. I also support the adoption :) I think section 4 needs contents to replace the "TBD". And one side questio= n after reading, is overlay layer solution the only direction the working g= roup is going to work on? Best Regards! -Haibin > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Andrew G. Malis > Sent: Sunday, January 12, 2014 11:26 PM > To: sfc@ietf.org > Subject: Re: [sfc] Call for WG Adoption of > draft-quinn-sfc-problem-statement-02.txt >=20 > I also support adoption of the draft. >=20 > Cheers, > Andy >=20 >=20 > On Sun, Jan 12, 2014 at 10:17 AM, Monique Morrow (mmorrow) > wrote: > > +1 > > > > Monique > > > > Sent from my iPhone > > > >> On 12.01.2014, at 14:44, "Barry Greene" wrote: > >> > >> > >> +1 > >> > >> > >>> On Jan 11, 2014, at 8:15 AM, Carlos Pignataro (cpignata) > wrote: > >>> > >>> Chairs, > >>> > >>> I support the adoption of draft-quinn-sfc-problem-statement-02.txt as= the > WG's problem statement document. > >>> > >>> In my view, draft-quinn-sfc-problem-statement-02.txt provides a great > starting point that has received much review and broad input. It also con= tains > an important reference definition of terms. After adoption, I think we ou= ght to > decide what's the best approach for Section 4 and use cases in general. > >>> > >>> Thanks, > >>> > >>> -- Carlos. > >>> > >>>> On Jan 10, 2014, at 5:33 PM, Thomas Narten > wrote: > >>>> > >>>> WG: > >>>> > >>>> Our highest-priority WG deliverable is getting a problem statement > >>>> done. As has been discussed before, > >>>> draft-quinn-sfc-problem-statement-02.txt has been the main > >>>> candidate and has been the basis for getting this WG chartered. > >>>> > >>>> With that in mind, this is a call for WG adoption of the documment. > >>>> > >>>> Please note: > >>>> > >>>> 1) This is not WG Last Call. The document is not final, and the WG > >>>> is expected to modify the document's content until there is WG > >>>> consensus that the content is solid. So please don't oppose > >>>> adoption just because you want to see changes to its content. > >>>> > >>>> 2) If you have objections to adoption of the document, please state > >>>> your reasons why, and explain what it would take to address your > >>>> concerns. > >>>> > >>>> 3) If you have issues with the content, by all means raise those > >>>> issues and we can begin a dialog about how best to address those > >>>> issues. > >>>> > >>>> Thomas & Jim > >>>> > >>>> _______________________________________________ > >>>> sfc mailing list > >>>> sfc@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sfc > >>> > >>> _______________________________________________ > >>> sfc mailing list > >>> sfc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sfc > >> > >> _______________________________________________ > >> sfc mailing list > >> sfc@ietf.org > >> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From haibin.song@huawei.com Sun Jan 12 19:10:07 2014 Return-Path: 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 7360D1AD9AD for ; Sun, 12 Jan 2014 19:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 bnmDc4k2v9yz for ; Sun, 12 Jan 2014 19:10:04 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A330F1AD9AB for ; Sun, 12 Jan 2014 19:10:03 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCK67418; Mon, 13 Jan 2014 03:09:52 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Jan 2014 03:09:05 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Jan 2014 03:09:51 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Mon, 13 Jan 2014 11:09:47 +0800 From: "Songhaibin (A)" To: "Carlos Pignataro (cpignata)" , Ron Parker Thread-Topic: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt Thread-Index: AQHPD95XipzkOvrwMEyneTMrY04NJpqBHB6AgADdP8A= Date: Mon, 13 Jan 2014 03:09:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Thomas Narten , "sfc@ietf.org" Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 03:10:07 -0000 I also think a problem statement can include some high level model to addre= ss the problem based on the charter. Although sometimes we will encounter s= ome area directors who do not believe so. But that is another story. Best Regards! -Haibin > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro > (cpignata) > Sent: Monday, January 13, 2014 5:55 AM > To: Ron Parker > Cc: Thomas Narten; sfc@ietf.org > Subject: Re: [sfc] Call for WG Adoption of > draft-quinn-sfc-problem-statement-02.txt >=20 > Hi, Ron, >=20 > I think Section 3 is perfectly scoped for a problem statement document. > Basically, the flow is that Section 2 describes "aspects of existing serv= ice > deployments that are problematic", and then Section 3 double-clicks on sp= ecific > elements to address those aspects ("SFC will investigate solutions that a= ddress > the following elements"). >=20 > It is perfectly fine for a problem description to include a model and a c= atalog of > areas to be addressed (i.e., this is the definition of the areas of the p= roblem > statement). Further, a problem statement can contain desired aspects of t= he > solutions to those elements. >=20 > Thanks, >=20 > -- Carlos. >=20 > On Jan 12, 2014, at 11:36 PM, Ron Parker > wrote: >=20 > > All, > > > > I, too, am comfortable with draft-quinn-sfc-problem-statement-02 as the > basis of our problem statement deliverable. Section 2, points 1-12 are = nicely > concise and to the point. > > > > However, section 3 reads more like the beginnings of an architectural > framework and not a problem statement. Without taking any position on > the goodness of those items, might they be better expressed in an > architectural document? > > > > Thanks. > > > > Ron > > > > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro > > (cpignata) > > Sent: Friday, January 10, 2014 8:16 PM > > To: Thomas Narten > > Cc: sfc@ietf.org > > Subject: Re: [sfc] Call for WG Adoption of > > draft-quinn-sfc-problem-statement-02.txt > > > > Chairs, > > > > I support the adoption of draft-quinn-sfc-problem-statement-02.txt as t= he > WG's problem statement document. > > > > In my view, draft-quinn-sfc-problem-statement-02.txt provides a great > starting point that has received much review and broad input. It also con= tains > an important reference definition of terms. After adoption, I think we ou= ght to > decide what's the best approach for Section 4 and use cases in general. > > > > Thanks, > > > > -- Carlos. > > > > On Jan 10, 2014, at 5:33 PM, Thomas Narten wrote: > > > >> WG: > >> > >> Our highest-priority WG deliverable is getting a problem statement > >> done. As has been discussed before, > >> draft-quinn-sfc-problem-statement-02.txt has been the main candidate > >> and has been the basis for getting this WG chartered. > >> > >> With that in mind, this is a call for WG adoption of the documment. > >> > >> Please note: > >> > >> 1) This is not WG Last Call. The document is not final, and the WG is > >> expected to modify the document's content until there is WG consensus > >> that the content is solid. So please don't oppose adoption just > >> because you want to see changes to its content. > >> > >> 2) If you have objections to adoption of the document, please state > >> your reasons why, and explain what it would take to address your > >> concerns. > >> > >> 3) If you have issues with the content, by all means raise those > >> issues and we can begin a dialog about how best to address those > >> issues. > >> > >> Thomas & Jim > >> > >> _______________________________________________ > >> sfc mailing list > >> sfc@ietf.org > >> https://www.ietf.org/mailman/listinfo/sfc > > From hongyu.li@huawei.com Sun Jan 12 21:38:59 2014 Return-Path: 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 0B4481ADEBB for ; Sun, 12 Jan 2014 21:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 WlcEj1nqupuR for ; Sun, 12 Jan 2014 21:38:57 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 85F2C1AD672 for ; Sun, 12 Jan 2014 21:38:55 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCK76764; Mon, 13 Jan 2014 05:38:44 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Jan 2014 05:38:06 +0000 Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Jan 2014 05:38:42 +0000 Received: from SZXEMA509-MBX.china.huawei.com ([169.254.1.51]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Mon, 13 Jan 2014 13:38:38 +0800 From: "Hongyu Li (Julio)" To: Thomas Narten , "adrian@olddog.co.uk" Thread-Topic: [sfc] [nsc] Time to get to work! Thread-Index: Ac7/UBP/z8hA0XuDQIiGMoXU0EpheQOv6lIAAIR87ZA= Date: Mon, 13 Jan 2014 05:38:38 +0000 Message-ID: <6EB34CB5D82C4645B826C56144826EA97E9B4AB5@SZXEMA509-MBX.china.huawei.com> References: <024901cf00d3$33bd7ef0$9b387cd0$@olddog.co.uk> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.102.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "sfc@ietf.org" Subject: Re: [sfc] [nsc] Time to get to work! X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 05:38:59 -0000 I agree to use this draft as the basis for our first milestone. One comment= here. As the charter says, we need to define problem statement and core us= e cases. Current section 4 of draft-quinn-sfc-problem-statement-02 is obvio= usly not persuasive enough. Suggest referring to draft-liu-sfc-use-cases an= d incorporate more valuable use cases. Cheers, Hongyu -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas Narten Sent: Saturday, January 11, 2014 6:25 AM To: adrian@olddog.co.uk Cc: sfc@ietf.org Subject: Re: [sfc] [nsc] Time to get to work! Thanks Adrian for all your help getting this WG chartered! WG: We've got plenty of work to do, and we're pleased to see that folk are alre= ady getting to it (a number of new and revised IDs have appeared). Just to recap where we are, our milestones are as follows: Goals and Milestones: Apr 2014 - Submit to IESG Information document defining the SFC problem statement and core use cases =20 Apr 2014 - Consult with OPS area on possible SFC charter modifications for management and configuration of SFC components related to the support of Service Function Chaining =20 Jan 2015 - Submit to IESG Informational document defining the architecture for SFC =20 Jan 2015 - Informational document defining the control plane requirements for conveying information between control or management elements and SFC implementation points =20 Aug 2015 - Submit to IESG Standards Track document specifying the generic service function chaining header encapsulation With that in mind, our highest priority items for the short term are: 1) Finish the problem statement document. 2) Start working out the architecture. 3) Begin figuring out what the WG wants to do with regards to "management" = and/or the "control plane" that relates to the Service Function instances a= nd how they are to learn how they are to process the packets that traverse = them relating to specific service function chains. Once we have a better id= ea of what work is needed here, we will go back sync up with the ADs on ho= w best to do the work. We'll be sending followup notes on the individual topics, but feel free to = chime in with thoughts/ideas on what our priorities should be. Jim & Thomas _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From mohamed.boucadair@orange.com Mon Jan 13 02:31:27 2014 Return-Path: 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 B676D1ADF33 for ; Mon, 13 Jan 2014 02:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 LPXAUNU92LEf for ; Mon, 13 Jan 2014 02:31:26 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 19C561ADFA9 for ; Mon, 13 Jan 2014 02:31:25 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 62545C02DA; Mon, 13 Jan 2014 11:31:14 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 42D31158052; Mon, 13 Jan 2014 11:31:14 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Mon, 13 Jan 2014 11:31:13 +0100 From: To: Thomas Narten , "sfc@ietf.org" Date: Mon, 13 Jan 2014 11:31:11 +0100 Thread-Topic: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt Thread-Index: Ac8OVA0S6kOxK2RIQ5muKUXMVS1GiAB9mFTg Message-ID: <94C682931C08B048B7A8645303FDC9F36F44CA078F@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.19.63615 Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 10:31:27 -0000 Dear chairs, all, I support the adoption of this draft as a starting point to record the sfc = problem statement.=20 Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas Narten >Envoy=E9=A0: vendredi 10 janvier 2014 23:34 >=C0=A0: sfc@ietf.org >Objet=A0: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement- >02.txt > >WG: > >Our highest-priority WG deliverable is getting a problem statement >done. As has been discussed before, >draft-quinn-sfc-problem-statement-02.txt has been the main candidate >and has been the basis for getting this WG chartered. > >With that in mind, this is a call for WG adoption of the documment. > >Please note: > >1) This is not WG Last Call. The document is not final, and the WG is >expected to modify the document's content until there is WG consensus >that the content is solid. So please don't oppose adoption just >because you want to see changes to its content. > >2) If you have objections to adoption of the document, please state >your reasons why, and explain what it would take to address your >concerns. > >3) If you have issues with the content, by all means raise those >issues and we can begin a dialog about how best to address those >issues. > >Thomas & Jim > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From jenapper@cisco.com Mon Jan 13 03:23:10 2014 Return-Path: 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 03E261ADDCA for ; Mon, 13 Jan 2014 03:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 0-F4Wfr-Rswf for ; Mon, 13 Jan 2014 03:23:06 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7909C1ADFA4 for ; Mon, 13 Jan 2014 03:23:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2161; q=dns/txt; s=iport; t=1389612175; x=1390821775; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=8Hukbz5FaIMlzDm8NO8AQvKlCTK9B/RkGwxNO+SntmU=; b=mt4RMi9TK4ffqjgNa/dgIAiONXU40FIKwo+elBxG4qFnpCE0Mp2ezAKt hweC1Xvz0XlvnBYsLDZCnSuNLUjCTj7oEq0SMv+vBXZwoaYh8F6B/amTS ruREf0RcDr5TxlviFKYZFIIX5GxdNpHBIL6Sc6whUbHGvCg66xkPDV3Je o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFADTL01KtJV2b/2dsb2JhbABagws4VrlqgQ4WdIIlAQEBBAEBARodNAsMBgEIEQMBAgEeNwsdCgQBDQWIBA3EWxMEjwcNhDEEmBeSFYMtgio X-IronPort-AV: E=Sophos;i="4.95,652,1384300800"; d="scan'208";a="12431541" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP; 13 Jan 2014 11:22:55 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0DBMtfM027922 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Jan 2014 11:22:55 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.37]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Mon, 13 Jan 2014 05:22:55 -0600 From: "Jeffrey Napper (jenapper)" To: "Carlos Pignataro (cpignata)" , Thomas Narten Thread-Topic: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt Thread-Index: AQHPEFHNUg84M5WXO0W8cy0QTLHJZw== Date: Mon, 13 Jan 2014 11:22:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.198.128] Content-Type: text/plain; charset="us-ascii" Content-ID: <4E88BDBC5E286F4B8046CCC2A3015F76@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 11:23:10 -0000 +1 Section 4 should probably be highlights of a couple of use cases where other drafts can discuss things in more detail. That appears to be the current approach already. Cheers, Jeff -----Original Message----- From: "Carlos Pignataro (cpignata)" Date: Saturday, January 11, 2014 at 2:15 AM To: Thomas Narten Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt >Chairs, > >I support the adoption of draft-quinn-sfc-problem-statement-02.txt as the >WG's problem statement document. > >In my view, draft-quinn-sfc-problem-statement-02.txt provides a great >starting point that has received much review and broad input. It also >contains an important reference definition of terms. After adoption, I >think we ought to decide what's the best approach for Section 4 and use >cases in general. > >Thanks, > >-- Carlos. > >On Jan 10, 2014, at 5:33 PM, Thomas Narten wrote: > >> WG: >>=20 >> Our highest-priority WG deliverable is getting a problem statement >> done. As has been discussed before, >> draft-quinn-sfc-problem-statement-02.txt has been the main candidate >> and has been the basis for getting this WG chartered. >>=20 >> With that in mind, this is a call for WG adoption of the documment. >>=20 >> Please note: >>=20 >> 1) This is not WG Last Call. The document is not final, and the WG is >> expected to modify the document's content until there is WG consensus >> that the content is solid. So please don't oppose adoption just >> because you want to see changes to its content. >>=20 >> 2) If you have objections to adoption of the document, please state >> your reasons why, and explain what it would take to address your >> concerns. >>=20 >> 3) If you have issues with the content, by all means raise those >> issues and we can begin a dialog about how best to address those >> issues. >>=20 >> Thomas & Jim >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > From jiangyuanlong@huawei.com Mon Jan 13 03:50:47 2014 Return-Path: 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 74CA21AE134 for ; Mon, 13 Jan 2014 03:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 wVpkKjFXGhWt for ; Mon, 13 Jan 2014 03:50:46 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7451AE12F for ; Mon, 13 Jan 2014 03:50:45 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZW88887; Mon, 13 Jan 2014 11:50:34 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Jan 2014 11:49:43 +0000 Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Jan 2014 11:50:30 +0000 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.204]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Mon, 13 Jan 2014 19:50:21 +0800 From: Jiangyuanlong To: Thomas Narten , "sfc@ietf.org" Thread-Topic: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt Thread-Index: AQHPDlQQXhreIPQ1fUiV2CDM4D3CaJqCjOOQ Date: Mon, 13 Jan 2014 11:50:20 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6CF909@szxema506-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 11:50:47 -0000 Hi Tom and all, I support adoption of this document, though Section 4 needs to be developed= by the work group. Regards, Yuanlong -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas Narten Sent: Saturday, January 11, 2014 6:34 AM To: sfc@ietf.org Subject: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02= .txt WG: Our highest-priority WG deliverable is getting a problem statement done. As has been discussed before, draft-quinn-sfc-problem-statement-02.txt has been the main candidate and has been the basis for getting this WG chartered. With that in mind, this is a call for WG adoption of the documment. Please note: 1) This is not WG Last Call. The document is not final, and the WG is expected to modify the document's content until there is WG consensus that the content is solid. So please don't oppose adoption just because you want to see changes to its content. 2) If you have objections to adoption of the document, please state your reasons why, and explain what it would take to address your concerns. 3) If you have issues with the content, by all means raise those issues and we can begin a dialog about how best to address those issues. Thomas & Jim _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From wim.henderickx@alcatel-lucent.com Mon Jan 13 04:26:12 2014 Return-Path: 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 DB28B1AE152 for ; Mon, 13 Jan 2014 04:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 raydvCenQI_U for ; Mon, 13 Jan 2014 04:26:11 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 0099B1AE151 for ; Mon, 13 Jan 2014 04:26:10 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s0DCPvn0021887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Jan 2014 06:25:59 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s0DCPvFW026357 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Jan 2014 13:25:57 +0100 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.62]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 13 Jan 2014 13:25:57 +0100 From: "Henderickx, Wim (Wim)" To: "mohamed.boucadair@orange.com" , "Thomas Narten" , "sfc@ietf.org" Thread-Topic: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt Thread-Index: AQHPEFqcXX6W1gHChka6JbHNPdGX7A== Date: Mon, 13 Jan 2014 12:25:56 +0000 Message-ID: References: <94C682931C08B048B7A8645303FDC9F36F44CA078F@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F44CA078F@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <59D13232CD2B1548B22C2F8598712CFA@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 12:26:13 -0000 +1 On 13/01/14 11:31, "mohamed.boucadair@orange.com" wrote: >Dear chairs, all, > >I support the adoption of this draft as a starting point to record the >sfc problem statement. > >Cheers, >Med > >>-----Message d'origine----- >>De : sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas Narten >>Envoy=E9 : vendredi 10 janvier 2014 23:34 >>=C0 : sfc@ietf.org >>Objet : [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement- >>02.txt >> >>WG: >> >>Our highest-priority WG deliverable is getting a problem statement >>done. As has been discussed before, >>draft-quinn-sfc-problem-statement-02.txt has been the main candidate >>and has been the basis for getting this WG chartered. >> >>With that in mind, this is a call for WG adoption of the documment. >> >>Please note: >> >>1) This is not WG Last Call. The document is not final, and the WG is >>expected to modify the document's content until there is WG consensus >>that the content is solid. So please don't oppose adoption just >>because you want to see changes to its content. >> >>2) If you have objections to adoption of the document, please state >>your reasons why, and explain what it would take to address your >>concerns. >> >>3) If you have issues with the content, by all means raise those >>issues and we can begin a dialog about how best to address those >>issues. >> >>Thomas & Jim >> >>_______________________________________________ >>sfc mailing list >>sfc@ietf.org >>https://www.ietf.org/mailman/listinfo/sfc >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From ramk@Brocade.com Mon Jan 13 09:07:22 2014 Return-Path: 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 591EB1ADFD6 for ; Mon, 13 Jan 2014 09:07:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 zkZeVxhxPfSg for ; Mon, 13 Jan 2014 09:07:20 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD561ADFA3 for ; Mon, 13 Jan 2014 09:07:20 -0800 (PST) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s0DGEmwH017364; Mon, 13 Jan 2014 09:07:08 -0800 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1hb3kuj5us-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 13 Jan 2014 09:07:08 -0800 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 13 Jan 2014 09:07:07 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Mon, 13 Jan 2014 09:06:57 -0800 From: ramki Krishnan To: "Henderickx, Wim (Wim)" , "mohamed.boucadair@orange.com" , Thomas Narten , "sfc@ietf.org" Date: Mon, 13 Jan 2014 09:06:58 -0800 Thread-Topic: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt Thread-Index: AQHPEFqcXX6W1gHChka6JbHNPdGX7JqC4vzQ Message-ID: References: <94C682931C08B048B7A8645303FDC9F36F44CA078F@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-13_02:2014-01-13,2014-01-13,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1401130093 Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 17:07:22 -0000 +1 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Henderickx, Wim (Wim) Sent: Monday, January 13, 2014 4:26 AM To: mohamed.boucadair@orange.com; Thomas Narten; sfc@ietf.org Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statemen= t-02.txt +1 On 13/01/14 11:31, "mohamed.boucadair@orange.com" wrote: >Dear chairs, all, > >I support the adoption of this draft as a starting point to record the=20 >sfc problem statement. > >Cheers, >Med > >>-----Message d'origine----- >>De : sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas Narten=20 >>Envoy=E9 : vendredi 10 janvier 2014 23:34 =C0 : sfc@ietf.org Objet : [sfc= ]=20 >>Call for WG Adoption of draft-quinn-sfc-problem-statement- >>02.txt >> >>WG: >> >>Our highest-priority WG deliverable is getting a problem statement=20 >>done. As has been discussed before,=20 >>draft-quinn-sfc-problem-statement-02.txt has been the main candidate=20 >>and has been the basis for getting this WG chartered. >> >>With that in mind, this is a call for WG adoption of the documment. >> >>Please note: >> >>1) This is not WG Last Call. The document is not final, and the WG is=20 >>expected to modify the document's content until there is WG consensus=20 >>that the content is solid. So please don't oppose adoption just=20 >>because you want to see changes to its content. >> >>2) If you have objections to adoption of the document, please state=20 >>your reasons why, and explain what it would take to address your=20 >>concerns. >> >>3) If you have issues with the content, by all means raise those=20 >>issues and we can begin a dialog about how best to address those=20 >>issues. >> >>Thomas & Jim >> >>_______________________________________________ >>sfc mailing list >>sfc@ietf.org >>https://www.ietf.org/mailman/listinfo/sfc >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From schaganti@versa-networks.com Mon Jan 13 10:28:04 2014 Return-Path: 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 88F161ADF96 for ; Mon, 13 Jan 2014 10:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=no 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 Pjsxu8BUwj2i for ; Mon, 13 Jan 2014 10:28:02 -0800 (PST) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) by ietfa.amsl.com (Postfix) with ESMTP id 2D72C1ADF48 for ; Mon, 13 Jan 2014 10:28:02 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id j1so5202127iga.3 for ; Mon, 13 Jan 2014 10:27:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type; bh=bELygkCxP71+L5bJ2o2RJ3qt2X+mxVvD3KdQayQUnvE=; b=MWfEozuwVHNJ0VyqHSHHzYvTIcbbFVTtHKkqii5KhlH3J1UAwUwdimzsT8+s2y2ip1 YvaBAS31YwPoeHvxGs8ZQxkKcVDz5289h3N8R4Y7KysWKaftJ5ZA96lAthVOWr8BK1OG ZQ7GT7h78zwMYzjPM8glMtkWGSjcpUzwaRCpZO6whLBfL6UD/9J38mHqa7CryqMfqkR0 +hG4aUW0l3ULDJzWZlZYw4BfB4VVFD18ltZJm1oi6/Yj2yoYXmiiJJX0TP0xJm5dRFam JqOIjn+5XU1N0lvDyVPKFhQCHHtWG9byjHFgM2LXO8h+Q/7sJ5SMmEdXwzw5K+KSudea LehQ== X-Gm-Message-State: ALoCoQn2suMN8ySevYDLZWfnUrfTeInbF0mP+287XMNueuh0PMtzktHq2jEDewuwU+dOG9O34+WR X-Received: by 10.42.65.73 with SMTP id k9mr21910572ici.44.1389637671070; Mon, 13 Jan 2014 10:27:51 -0800 (PST) From: Srinivasa Chaganti References: , <85B0A245-27CF-42E5-913B-F604C960C838@senki.org> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQILJLlrc9dJWp3lOl0khXTlCE17dwJ0leDlALpGyPEA1sEN2JnqomPw Date: Mon, 13 Jan 2014 10:25:21 -0800 Message-ID: <9b3acb0468617094302d9dbc504e8e6a@mail.gmail.com> To: "Monique Morrow (mmorrow)" , Barry Greene Content-Type: text/plain; charset=ISO-8859-1 Cc: Thomas Narten , "Carlos Pignataro \(cpignata\)" , sfc@ietf.org Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 18:28:04 -0000 Hi all, I support adoption of draft-quinn-sfc-problem-statement-02.txt as starting point for WG's problem statement document. Regards, Chaganti -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Monique Morrow (mmorrow) Sent: Sunday, January 12, 2014 7:18 AM To: Barry Greene Cc: Thomas Narten; Carlos Pignataro (cpignata); sfc@ietf.org Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt +1 Monique Sent from my iPhone > On 12.01.2014, at 14:44, "Barry Greene" wrote: > > > +1 > > >> On Jan 11, 2014, at 8:15 AM, Carlos Pignataro (cpignata) wrote: >> >> Chairs, >> >> I support the adoption of draft-quinn-sfc-problem-statement-02.txt as the WG's problem statement document. >> >> In my view, draft-quinn-sfc-problem-statement-02.txt provides a great starting point that has received much review and broad input. It also contains an important reference definition of terms. After adoption, I think we ought to decide what's the best approach for Section 4 and use cases in general. >> >> Thanks, >> >> -- Carlos. >> >>> On Jan 10, 2014, at 5:33 PM, Thomas Narten wrote: >>> >>> WG: >>> >>> Our highest-priority WG deliverable is getting a problem statement >>> done. As has been discussed before, >>> draft-quinn-sfc-problem-statement-02.txt has been the main candidate >>> and has been the basis for getting this WG chartered. >>> >>> With that in mind, this is a call for WG adoption of the documment. >>> >>> Please note: >>> >>> 1) This is not WG Last Call. The document is not final, and the WG >>> is expected to modify the document's content until there is WG >>> consensus that the content is solid. So please don't oppose adoption >>> just because you want to see changes to its content. >>> >>> 2) If you have objections to adoption of the document, please state >>> your reasons why, and explain what it would take to address your >>> concerns. >>> >>> 3) If you have issues with the content, by all means raise those >>> issues and we can begin a dialog about how best to address those >>> issues. >>> >>> Thomas & Jim >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From prvs=0090e56a3b=hshah@ciena.com Mon Jan 13 11:05:57 2014 Return-Path: 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 80C611ADFC8 for ; Mon, 13 Jan 2014 11:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 U_UOL127DUuB for ; Mon, 13 Jan 2014 11:05:55 -0800 (PST) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id 10D821ADF9A for ; Mon, 13 Jan 2014 11:05:55 -0800 (PST) Received: from pps.filterd (m0000419.ppops.net [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.5/8.14.5) with SMTP id s0DJ5C5s027572; Mon, 13 Jan 2014 14:05:44 -0500 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0a-00103a01.pphosted.com with ESMTP id 1hb0p8x4tq-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 13 Jan 2014 14:05:43 -0500 Received: from ONWVEXCHHT02.ciena.com (10.128.6.17) by MDWEXGHT02.ciena.com (10.4.140.213) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 13 Jan 2014 14:05:42 -0500 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT02.ciena.com ([::1]) with mapi; Mon, 13 Jan 2014 14:05:41 -0500 From: "Shah, Himanshu" To: Thomas Narten , "sfc@ietf.org" Date: Mon, 13 Jan 2014 14:05:40 -0500 Thread-Topic: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt Thread-Index: AQHPEFqcXX6W1gHChka6JbHNPdGX7JqC4vzQgAAhFpA= Message-ID: <40746B2300A8FC4AB04EE722A593182B6C0D40B1@ONWVEXCHMB04.ciena.com> References: <94C682931C08B048B7A8645303FDC9F36F44CA078F@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-20430.001 X-TM-AS-Result: No--21.533600-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-13_03:2014-01-13,2014-01-13,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1401130122 Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 19:05:57 -0000 +1 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of ramki Krishnan Sent: Monday, January 13, 2014 12:07 PM To: Henderickx, Wim (Wim); mohamed.boucadair@orange.com; Thomas Narten; sfc= @ietf.org Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statemen= t-02.txt +1 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Henderickx, Wim (Wim) Sent: Monday, January 13, 2014 4:26 AM To: mohamed.boucadair@orange.com; Thomas Narten; sfc@ietf.org Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statemen= t-02.txt +1 On 13/01/14 11:31, "mohamed.boucadair@orange.com" wrote: >Dear chairs, all, > >I support the adoption of this draft as a starting point to record the=20 >sfc problem statement. > >Cheers, >Med > >>-----Message d'origine----- >>De : sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas Narten=20 >>Envoy=E9 : vendredi 10 janvier 2014 23:34 =C0 : sfc@ietf.org Objet : [sfc= ]=20 >>Call for WG Adoption of draft-quinn-sfc-problem-statement- >>02.txt >> >>WG: >> >>Our highest-priority WG deliverable is getting a problem statement=20 >>done. As has been discussed before,=20 >>draft-quinn-sfc-problem-statement-02.txt has been the main candidate=20 >>and has been the basis for getting this WG chartered. >> >>With that in mind, this is a call for WG adoption of the documment. >> >>Please note: >> >>1) This is not WG Last Call. The document is not final, and the WG is=20 >>expected to modify the document's content until there is WG consensus=20 >>that the content is solid. So please don't oppose adoption just=20 >>because you want to see changes to its content. >> >>2) If you have objections to adoption of the document, please state=20 >>your reasons why, and explain what it would take to address your=20 >>concerns. >> >>3) If you have issues with the content, by all means raise those=20 >>issues and we can begin a dialog about how best to address those=20 >>issues. >> >>Thomas & Jim >> >>_______________________________________________ >>sfc mailing list >>sfc@ietf.org >>https://www.ietf.org/mailman/listinfo/sfc >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From praveen.muley@alcatel-lucent.com Mon Jan 13 11:06:44 2014 Return-Path: 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 9A5501ADFC8 for ; Mon, 13 Jan 2014 11:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 F9WAXgc_dfAv for ; Mon, 13 Jan 2014 11:06:43 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id DB89F1ADF9A for ; Mon, 13 Jan 2014 11:06:42 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s0DJ6VOX012933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Jan 2014 13:06:31 -0600 (CST) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s0DJ6UPC015596 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Jan 2014 14:06:31 -0500 Received: from US70TWXCHMBA10.zam.alcatel-lucent.com ([169.254.4.40]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Mon, 13 Jan 2014 14:06:30 -0500 From: "Muley, Praveen V (Praveen)" To: Thomas Narten Thread-Topic: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt Thread-Index: AQHPEFHNY1WhCCfCGkqG85DOrZgL7pqDBCcg Date: Mon, 13 Jan 2014 19:06:30 +0000 Message-ID: <22069265D1B36949926E9422EBF3B8815663728A@US70TWXCHMBA10.zam.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 19:06:44 -0000 =20 Support. -----Original Message----- From: "Carlos Pignataro (cpignata)" Date: Saturday, January 11, 2014 at 2:15 AM To: Thomas Narten Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt >Chairs, > >I support the adoption of draft-quinn-sfc-problem-statement-02.txt as=20 >the WG's problem statement document. > >In my view, draft-quinn-sfc-problem-statement-02.txt provides a great=20 >starting point that has received much review and broad input. It also=20 >contains an important reference definition of terms. After adoption, I=20 >think we ought to decide what's the best approach for Section 4 and use=20 >cases in general. > >Thanks, > >-- Carlos. > >On Jan 10, 2014, at 5:33 PM, Thomas Narten wrote: > >> WG: >>=20 >> Our highest-priority WG deliverable is getting a problem statement=20 >> done. As has been discussed before,=20 >> draft-quinn-sfc-problem-statement-02.txt has been the main candidate=20 >> and has been the basis for getting this WG chartered. >>=20 >> With that in mind, this is a call for WG adoption of the documment. >>=20 >> Please note: >>=20 >> 1) This is not WG Last Call. The document is not final, and the WG is=20 >> expected to modify the document's content until there is WG consensus=20 >> that the content is solid. So please don't oppose adoption just=20 >> because you want to see changes to its content. >>=20 >> 2) If you have objections to adoption of the document, please state=20 >> your reasons why, and explain what it would take to address your=20 >> concerns. >>=20 >> 3) If you have issues with the content, by all means raise those=20 >> issues and we can begin a dialog about how best to address those=20 >> issues. >>=20 >> Thomas & Jim >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From mikebianc@aol.com Mon Jan 13 11:11:23 2014 Return-Path: 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 C3BE91ADF93 for ; Mon, 13 Jan 2014 11:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, 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 PXfVI4EWyCla for ; Mon, 13 Jan 2014 11:11:16 -0800 (PST) Received: from omr-m02.mx.aol.com (omr-m02.mx.aol.com [64.12.143.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE931ADF48 for ; Mon, 13 Jan 2014 11:11:16 -0800 (PST) Received: from mtaout-mbc01.mx.aol.com (mtaout-mbc01.mx.aol.com [172.26.221.141]) by omr-m02.mx.aol.com (Outbound Mail Relay) with ESMTP id 4D281701C83B0; Mon, 13 Jan 2014 14:11:05 -0500 (EST) Received: from mgs-aam01.mail.aol.com (mgs-aam01.mail.aol.com [64.12.250.54]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-mbc01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 098FB38000099; Mon, 13 Jan 2014 14:11:05 -0500 (EST) Date: Mon, 13 Jan 2014 14:11:04 -0500 From: "mikebianc@aol.com" To: narten@us.ibm.com Message-ID: <335589803.105419.1389640264880.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: <9b3acb0468617094302d9dbc504e8e6a@mail.gmail.com> References: , <85B0A245-27CF-42E5-913B-F604C960C838@senki.org> <9b3acb0468617094302d9dbc504e8e6a@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_105418_1052359785.1389640264879" X-Originating-IP: 10.172.4.203, 205.188.60.49 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1389640265; bh=2Ft8MGmADYjJ9ZKEAX7Luj2Yh8R6EOY41gIeQG5aV3E=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=tC+r1S6noG4jynsc7S2+PEnqv5yNH/UwILjg/fb+bWEdn6PWu8YNUv/fu75+jWbQC KUAlOyfpnvvYKJZNDvBx/g4CAYWU05F0HizBCxC9o9ei28UttNtTDpuVemvoeKsIHU WI+ru6ln58/RqPzK2RjrhVHFye7/dYPHhhmyHWn4= x-aol-sid: 3039ac1add8d52d43a491987 X-AOL-IP: 64.12.250.54 Cc: sfc@ietf.org Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 19:11:24 -0000 ------=_Part_105418_1052359785.1389640264879 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1. =C2=A0Looks good to me. =C2=A0What more are you looking for wrt to 4.1?= =C2=A0 From: schaganti@versa-networks.com To: Monique Morrow (mmorrow),Barry Greene cc: Thomas Narten,Carlos Pignataro (cpignata), Sent: Monday, January 13, 2014 Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statemen= t-02.txt Hi all, I support adoption of draft-quinn-sfc-problem-statement-02.txt as starting point for WG's problem statement document. Regards, Chaganti -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Monique Morrow(mmorrow= )Sent: Sunday, January 12, 2014 7:18 AMTo: Barry GreeneCc: Thomas Narten; C= arlos Pignataro (cpignata); sfc@ietf.orgSubject: Re: [sfc] Call for WG Adop= tion ofdraft-quinn-sfc-problem-statement-02.txt+1MoniqueSent from my iPhone= > On 12.01.2014, at 14:44, "Barry Greene" wrote:>>> +1>= >>> On Jan 11, 2014, at 8:15 AM, Carlos Pignataro (cpignata) wrote:>>>> Chairs,>>>> I support the adoption of draft-quinn-sfc-prob= lem-statement-02.txt asthe WG's problem statement document.>>>> In my view,= draft-quinn-sfc-problem-statement-02.txt provides a greatstarting point th= at has received much review and broad input. It alsocontains an important r= eference definition of terms. After adoption, Ithink we ought to decide wha= t's the best approach for Section 4 and usecases in general.>>>> Thanks,>>>= > -- Carlos.>>>>> On Jan 10, 2014, at 5:33 PM, Thomas Narten wrote:>>>>>> WG:>>>>>> Our highest-priority WG deliverable is getting= a problem statement>>> done. As has been discussed before,>>> draft-quinn-= sfc-problem-statement-02.txt has been the main candidate>>> and has been th= e basis for getting this WG chartered.>>>>>> With that in mind, this is a c= all for WG adoption of the documment.>>>>>> Please note:>>>>>> 1) This is n= ot WG Last Call. The document is not final, and the WG>>> is expected to mo= dify the document's content until there is WG>>> consensus that the content= is solid. So please don't oppose adoption>>> just because you want to see = changes to its content.>>>>>> 2) If you have objections to adoption of the = document, please state>>> your reasons why, and explain what it would take = to address your>>> concerns.>>>>>> 3) If you have issues with the content, = by all means raise those>>> issues and we can begin a dialog about how bes= t to address those>>> issues.>>>>>> Thomas & Jim>>>>>> ____________________= ___________________________>>> sfc mailing list>>> sfc@ietf.org>>> https://= www.ietf.org/mailman/listinfo/sfc>>>> _____________________________________= __________>> sfc mailing list>> sfc@ietf.org>> https://www.ietf.org/mailman= /listinfo/sfc>> _______________________________________________> sfc mailin= g list> sfc@ietf.org> https://www.ietf.org/mailman/listinfo/sfc____________= ___________________________________sfc mailing listsfc@ietf.orghttps://www.= ietf.org/mailman/listinfo/sfc______________________________________________= _sfc mailing listsfc@ietf.orghttps://www.ietf.org/mailman/listinfo/sfc ------=_Part_105418_1052359785.1389640264879 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1.  Looks= good to me.  What more are you looking for wrt to 4.1?  

=



From: schaganti@versa-networks.com<schaganti@versa-network= s.com>
To: Monique Morrow (mmorrow)<mmorrow@cisco.com>,B= arry Greene<bgreene@senki.org>
cc: Thomas Narten<narten@= us.ibm.com>,Carlos Pignataro (cpignata)<cpignata@cisco.com>,<sf= c@ietf.org>
Sent: Monday, January 13, 2014
Subject: = Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt<= br>
Hi all,
I support adoption of draft-quinn-sfc-prob= lem-statement-02.txt as starting
point for WG's problem statement docume= nt.

Regards,
Chaganti

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

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Monique M= orrow
(mmorrow)
Sent: Sunday, January 12, 2014 = 7:18 AM
To: Barry Greene
Cc: Thomas Narten; Car= los Pignataro (cpignata); sfc@ietf.org
Subject: Re: [sfc] Cal= l for WG Adoption of
draft-quinn-sfc-problem-statement-02.txt=

+1

Monique

Sent from my iPhone

&g= t; On 12.01.2014, at 14:44, "Barry Greene" <bgreene@senki.org> wrote:=
>
>
> +1
= >
>
>> On Jan 11, 2014, at 8:15 AM,= Carlos Pignataro (cpignata)
<cpignata@cisco.com> wrote= :
>>
>> Chairs,
>&= gt;
>> I support the adoption of draft-quinn-sfc-proble= m-statement-02.txt as
the WG's problem statement document.>>
>> In my view, draft-quinn-sfc-pro= blem-statement-02.txt provides a great
starting point that ha= s received much review and broad input. It also
contains an i= mportant reference definition of terms. After adoption, I
thi= nk we ought to decide what's the best approach for Section 4 and use
cases in general.
>>
>> Tha= nks,
>>
>> -- Carlos.
>>
>>> On Jan 10, 2014, at 5:33 PM, Thomas Na= rten <narten@us.ibm.com> wrote:
>>>
>>> WG:
>>>
>>>= ; Our highest-priority WG deliverable is getting a problem statement
>>> done. As has been discussed before,
>= >> draft-quinn-sfc-problem-statement-02.txt has been the main candida= te
>>> and has been the basis for getting this WG ch= artered.
>>>
>>> With that in= mind, this is a call for WG adoption of the documment.
>&= gt;>
>>> Please note:
>>><= br class=3D"">>>> 1) This is not WG Last Call. The document is not= final, and the WG
>>> is expected to modify the doc= ument's content until there is WG
>>> consensus that= the content is solid. So please don't oppose adoption
>&g= t;> just because you want to see changes to its content.
&= gt;>>
>>> 2) If you have objections to adoptio= n of the document, please state
>>> your reasons why= , and explain what it would take to address your
>>>= concerns.
>>>
>>> 3) If you = have issues with the content, by all means raise those
>&= gt;> issues and we can begin a dialog about how best to address those>>> issues.
>>>
&= gt;>> Thomas & Jim
>>>
>&= gt;> _______________________________________________
>&= gt;> sfc mailing list
>>> sfc@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sfc
= >>
>> ___________________________________________= ____
>> sfc mailing list
>> sfc@iet= f.org
>> https://www.ietf.org/mailman/listinfo/sfc
>
> _________________________________________= ______
> sfc mailing list
> sfc@ietf.org<= br class=3D"">> https://www.ietf.org/mailman/listinfo/sfc
= _______________________________________________
sfc mailing l= ist
sfc@ietf.org
https://www.ietf.org/mailman/l= istinfo/sfc
_______________________________________________sfc mailing list
sfc@ietf.org
http= s://www.ietf.org/mailman/listinfo/sfc
------=_Part_105418_1052359785.1389640264879-- From jmoisand@juniper.net Mon Jan 13 11:49:42 2014 Return-Path: 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 4D2DC1ADF97 for ; Mon, 13 Jan 2014 11:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 OuhQFBGpVQwG for ; Mon, 13 Jan 2014 11:49:25 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 533581ADF89 for ; Mon, 13 Jan 2014 11:49:25 -0800 (PST) Received: from mail200-ch1-R.bigfish.com (10.43.68.226) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.22; Mon, 13 Jan 2014 19:49:14 +0000 Received: from mail200-ch1 (localhost [127.0.0.1]) by mail200-ch1-R.bigfish.com (Postfix) with ESMTP id 0C3124E01E7 for ; Mon, 13 Jan 2014 19:49:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(z579ehz9371I542Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h1033IL8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h9a9j1155h) Received-SPF: pass (mail200-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(189002)(199002)(377454003)(13464003)(81542001)(92566001)(79102001)(93136001)(63696002)(80022001)(66066001)(65816001)(74876001)(31966008)(81816001)(47446002)(74502001)(74662001)(76796001)(76786001)(2656002)(53806001)(224303002)(81686001)(224313003)(83072002)(76576001)(54356001)(85852003)(15975445006)(81342001)(69226001)(51856001)(85306002)(56816005)(90146001)(46102001)(19580395003)(33646001)(74366001)(74706001)(74316001)(49866001)(54316002)(56776001)(76482001)(47976001)(19580405001)(83322001)(47736001)(87936001)(59766001)(77982001)(87266001)(4396001)(80976001)(50986001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB715; H:CO2PR05MB716.namprd05.prod.outlook.com; CLIP:66.129.241.12; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail200-ch1 (localhost.localdomain [127.0.0.1]) by mail200-ch1 (MessageSwitch) id 1389642552146350_5074; Mon, 13 Jan 2014 19:49:12 +0000 (UTC) Received: from CH1EHSMHS020.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail200-ch1.bigfish.com (Postfix) with ESMTP id 15CF246004C for ; Mon, 13 Jan 2014 19:49:12 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS020.bigfish.com (10.43.70.20) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 13 Jan 2014 19:49:10 +0000 Received: from CO2PR05MB715.namprd05.prod.outlook.com (10.141.228.150) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.395.1; Mon, 13 Jan 2014 19:49:07 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com (10.141.228.152) by CO2PR05MB715.namprd05.prod.outlook.com (10.141.228.150) with Microsoft SMTP Server (TLS) id 15.0.842.7; Mon, 13 Jan 2014 19:49:05 +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.0842.003; Mon, 13 Jan 2014 19:49:05 +0000 From: Jerome Moisand To: "sfc@ietf.org" Thread-Topic: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt Thread-Index: AQHPDlQRjsoXyK8sH0+81NFAZXN1sJqDEyiA Date: Mon, 13 Jan 2014 19:49:04 +0000 Message-ID: <25c9849f393b4c43a805efc7b5e38edf@CO2PR05MB716.namprd05.prod.outlook.com> References: In-Reply-To: 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: 00909363D5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 19:49:42 -0000 This document is indeed a good start. I am supportive of WG adoption. More work is definitely required though, notably on use cases overview (fix= ed broadband scenarios are glaringly missing), and then some fine tuning of= the rest of the document.=20 Jerome Moisand -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas Narten Sent: Friday, January 10, 2014 5:34 PM To: sfc@ietf.org Subject: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02= .txt WG: Our highest-priority WG deliverable is getting a problem statement done. As= has been discussed before, draft-quinn-sfc-problem-statement-02.txt has be= en the main candidate and has been the basis for getting this WG chartered. With that in mind, this is a call for WG adoption of the documment. Please note: 1) This is not WG Last Call. The document is not final, and the WG is expec= ted to modify the document's content until there is WG consensus that the c= ontent is solid. So please don't oppose adoption just because you want to s= ee changes to its content. 2) If you have objections to adoption of the document, please state your re= asons why, and explain what it would take to address your concerns. 3) If you have issues with the content, by all means raise those issues an= d we can begin a dialog about how best to address those issues. Thomas & Jim _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From andre.beliveau@ericsson.com Mon Jan 13 13:07:04 2014 Return-Path: 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 5B0451AE15D for ; Mon, 13 Jan 2014 13:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3Zp8deJ4_GZ2 for ; Mon, 13 Jan 2014 13:07:02 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 83AF71AE000 for ; Mon, 13 Jan 2014 13:07:02 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-94-52d4556a15d5 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E6.E6.04556.A6554D25; Mon, 13 Jan 2014 22:06:51 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0347.000; Mon, 13 Jan 2014 16:06:49 -0500 From: Andre Beliveau To: "sfc@ietf.org" Thread-Topic: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt Thread-Index: AQHPDlQPwFum/l189EeB53l7Ua6ampp+4KkAgARJTkA= Date: Mon, 13 Jan 2014 21:06:49 +0000 Message-ID: <3049626EAC5C3E43866CD2692A7E19AC1C35895E@eusaamb103.ericsson.se> References: In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyuXRPiG526JUggxmPWCyePNjK7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujH8TZ7AXLOGtWNO8lb2B8TJXFyMHh4SAicTvNqsuRk4gU0zi wr31bF2MXBxCAkcYJfbt3cUM4SxnlGj4fIYRpIpNwEji/ZVJYLaIgKLEuZcTWEBsYYFQiamt y5kg4mESG468gaqxknjbvYUdxGYRUJXo6vnMCmLzCvhKvFl3jQ3EFhJIk3i8+DxYnFPAWaJ5 zROwekYBWYkNE7+BzWcWEJe49WQ+E8SlAhJL9pxnhrBFJV4+/scKYStLfJ/zCKpeR2LB7k9s ELa2xLKFr5kh9gpKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxg5SotTy3LTjQw3MQID/5gE m+MOxgWfLA8xSnOwKInzfnnrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB0a3+NL+t85a6 R6uql+vfe1O5tZRz/aPDd9VZGBf/yLuadEXz7/sfdwL+OPvpXvj5Jf6ThjLDvvRu+8Nxp16d WdU+VTryyD7lFLP5FzWVyzll6zhE0heV/emdUOaSM9dKeYnO9v0iR3ex2zJEuM4+1tr+mkPO oSrwwN15uy0PnZuhqlGkrzBJSYmlOCPRUIu5qDgRAFk8BnFKAgAA Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 21:07:04 -0000 +1 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas Nadeau Sent: January-10-14 5:39 PM To: Thomas Narten Cc: sfc@ietf.org Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statemen= t-02.txt I believe this draft is a good place to start. I feel the document has the= right spirit and sections for the WG to chew on. It also has already had s= ignificant input from the NSC community as well, and so I think represents = a good view of what the general community is looking for.=20 --Tom > WG: >=20 > Our highest-priority WG deliverable is getting a problem statement=20 > done. As has been discussed before,=20 > draft-quinn-sfc-problem-statement-02.txt has been the main candidate=20 > and has been the basis for getting this WG chartered. >=20 > With that in mind, this is a call for WG adoption of the documment. >=20 > Please note: >=20 > 1) This is not WG Last Call. The document is not final, and the WG is=20 > expected to modify the document's content until there is WG consensus=20 > that the content is solid. So please don't oppose adoption just=20 > because you want to see changes to its content. >=20 > 2) If you have objections to adoption of the document, please state=20 > your reasons why, and explain what it would take to address your=20 > concerns. >=20 > 3) If you have issues with the content, by all means raise those=20 > issues and we can begin a dialog about how best to address those=20 > issues. >=20 > Thomas & Jim >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc >=20 From linda.dunbar@huawei.com Mon Jan 13 14:20:04 2014 Return-Path: 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 9192B1ADF47 for ; Mon, 13 Jan 2014 14:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 29n4kUZuATRM for ; Mon, 13 Jan 2014 14:20:02 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A71C71ADA5D for ; Mon, 13 Jan 2014 14:20:01 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZX29149; Mon, 13 Jan 2014 22:19:49 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Jan 2014 22:18:59 +0000 Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Jan 2014 22:19:47 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml702-chm.china.huawei.com ([169.254.4.231]) with mapi id 14.03.0158.001; Mon, 13 Jan 2014 14:19:41 -0800 From: Linda Dunbar To: Thomas Narten , "sfc@ietf.org" Thread-Topic: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt Thread-Index: AQHPDlQSvsEYJgvLJkSdJ7CrWt9DZZqDPkKg Date: Mon, 13 Jan 2014 22:19:41 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C4B581@dfweml701-chm.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 22:20:04 -0000 Support.=20 Very good draft, short and informative.=20 Linda -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas Narten Sent: Friday, January 10, 2014 4:34 PM To: sfc@ietf.org Subject: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02= .txt WG: Our highest-priority WG deliverable is getting a problem statement done. As= has been discussed before, draft-quinn-sfc-problem-statement-02.txt has be= en the main candidate and has been the basis for getting this WG chartered. With that in mind, this is a call for WG adoption of the documment. Please note: 1) This is not WG Last Call. The document is not final, and the WG is expec= ted to modify the document's content until there is WG consensus that the c= ontent is solid. So please don't oppose adoption just because you want to s= ee changes to its content. 2) If you have objections to adoption of the document, please state your re= asons why, and explain what it would take to address your concerns. 3) If you have issues with the content, by all means raise those issues an= d we can begin a dialog about how best to address those issues. Thomas & Jim _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From lucy.yong@huawei.com Mon Jan 13 15:51:46 2014 Return-Path: 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 3AFAA1AC82B for ; Mon, 13 Jan 2014 15:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 8Qgv1NHJ85gU for ; Mon, 13 Jan 2014 15:51:43 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 77C4A1A8033 for ; Mon, 13 Jan 2014 15:51:42 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCL58005; Mon, 13 Jan 2014 23:51:30 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Jan 2014 23:50:50 +0000 Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Jan 2014 23:51:29 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml702-chm.china.huawei.com ([169.254.4.231]) with mapi id 14.03.0158.001; Mon, 13 Jan 2014 15:51:20 -0800 From: Lucy yong To: "sfc@ietf.org" Thread-Topic: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt Thread-Index: AQHPEI0yjo/YrevGH0eXOcG74uxDLJqDNxYg Date: Mon, 13 Jan 2014 23:51:19 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D45311960@dfweml701-chm.china.huawei.com> References: , <85B0A245-27CF-42E5-913B-F604C960C838@senki.org> <9b3acb0468617094302d9dbc504e8e6a@mail.gmail.com> In-Reply-To: <9b3acb0468617094302d9dbc504e8e6a@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.240] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Thomas Narten , "Carlos Pignataro \(cpignata\)" Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 23:51:46 -0000 Good way to start. Support! Cheers, Lucy -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Srinivasa Chaganti Sent: Monday, January 13, 2014 12:25 PM To: Monique Morrow (mmorrow); Barry Greene Cc: Thomas Narten; Carlos Pignataro (cpignata); sfc@ietf.org Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statemen= t-02.txt Hi all, I support adoption of draft-quinn-sfc-problem-statement-02.txt as starting = point for WG's problem statement document. Regards, Chaganti -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Monique Morrow (mmorrow) Sent: Sunday, January 12, 2014 7:18 AM To: Barry Greene Cc: Thomas Narten; Carlos Pignataro (cpignata); sfc@ietf.org Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statemen= t-02.txt +1 Monique Sent from my iPhone > On 12.01.2014, at 14:44, "Barry Greene" wrote: > > > +1 > > >> On Jan 11, 2014, at 8:15 AM, Carlos Pignataro (cpignata) wrote: >> >> Chairs, >> >> I support the adoption of draft-quinn-sfc-problem-statement-02.txt as the WG's problem statement document. >> >> In my view, draft-quinn-sfc-problem-statement-02.txt provides a great starting point that has received much review and broad input. It also conta= ins an important reference definition of terms. After adoption, I think we = ought to decide what's the best approach for Section 4 and use cases in gen= eral. >> >> Thanks, >> >> -- Carlos. >> >>> On Jan 10, 2014, at 5:33 PM, Thomas Narten wrote: >>> >>> WG: >>> >>> Our highest-priority WG deliverable is getting a problem statement=20 >>> done. As has been discussed before,=20 >>> draft-quinn-sfc-problem-statement-02.txt has been the main candidate=20 >>> and has been the basis for getting this WG chartered. >>> >>> With that in mind, this is a call for WG adoption of the documment. >>> >>> Please note: >>> >>> 1) This is not WG Last Call. The document is not final, and the WG=20 >>> is expected to modify the document's content until there is WG=20 >>> consensus that the content is solid. So please don't oppose adoption=20 >>> just because you want to see changes to its content. >>> >>> 2) If you have objections to adoption of the document, please state=20 >>> your reasons why, and explain what it would take to address your=20 >>> concerns. >>> >>> 3) If you have issues with the content, by all means raise those=20 >>> issues and we can begin a dialog about how best to address those=20 >>> issues. >>> >>> Thomas & Jim >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From andrew.dolganow@alcatel-lucent.com Mon Jan 13 17:50:38 2014 Return-Path: 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 6F2E61ADFD7 for ; Mon, 13 Jan 2014 17:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 zzTr4_nYD1LP for ; Mon, 13 Jan 2014 17:50:36 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 73D121AD8EA for ; Mon, 13 Jan 2014 17:50:36 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s0E1oOCw026649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 13 Jan 2014 19:50:25 -0600 (CST) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s0E1oOYQ007355 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 13 Jan 2014 20:50:24 -0500 Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.176]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Mon, 13 Jan 2014 20:50:24 -0500 From: "Dolganow, Andrew (Andrew)" To: "sfc@ietf.org" Thread-Topic: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt Thread-Index: AQHPEMr9eUoYZaA/OE2Ex2Oz1lBHpQ== Date: Tue, 14 Jan 2014 01:50:23 +0000 Message-ID: References: <85B0A245-27CF-42E5-913B-F604C960C838@senki.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 01:50:38 -0000 +1 On 1/12/2014, 10:26 AM, "Andrew G. Malis" wrote: >I also support adoption of the draft. > >Cheers, >Andy > > >On Sun, Jan 12, 2014 at 10:17 AM, Monique Morrow (mmorrow) > wrote: >> +1 >> >> Monique >> >> Sent from my iPhone >> >>> On 12.01.2014, at 14:44, "Barry Greene" wrote: >>> >>> >>> +1 >>> >>> >>>> On Jan 11, 2014, at 8:15 AM, Carlos Pignataro (cpignata) >>>> wrote: >>>> >>>> Chairs, >>>> >>>> I support the adoption of draft-quinn-sfc-problem-statement-02.txt as >>>>the WG's problem statement document. >>>> >>>> In my view, draft-quinn-sfc-problem-statement-02.txt provides a great >>>>starting point that has received much review and broad input. It also >>>>contains an important reference definition of terms. After adoption, I >>>>think we ought to decide what's the best approach for Section 4 and >>>>use cases in general. >>>> >>>> Thanks, >>>> >>>> -- Carlos. >>>> >>>>> On Jan 10, 2014, at 5:33 PM, Thomas Narten wrote: >>>>> >>>>> WG: >>>>> >>>>> Our highest-priority WG deliverable is getting a problem statement >>>>> done. As has been discussed before, >>>>> draft-quinn-sfc-problem-statement-02.txt has been the main candidate >>>>> and has been the basis for getting this WG chartered. >>>>> >>>>> With that in mind, this is a call for WG adoption of the documment. >>>>> >>>>> Please note: >>>>> >>>>> 1) This is not WG Last Call. The document is not final, and the WG is >>>>> expected to modify the document's content until there is WG consensus >>>>> that the content is solid. So please don't oppose adoption just >>>>> because you want to see changes to its content. >>>>> >>>>> 2) If you have objections to adoption of the document, please state >>>>> your reasons why, and explain what it would take to address your >>>>> concerns. >>>>> >>>>> 3) If you have issues with the content, by all means raise those >>>>> issues and we can begin a dialog about how best to address those >>>>> issues. >>>>> >>>>> Thomas & Jim >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From N.Leymann@telekom.de Tue Jan 14 02:57:31 2014 Return-Path: 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 409BA1AE08A for ; Tue, 14 Jan 2014 02:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] 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 1si6Vflu6yqK for ; Tue, 14 Jan 2014 02:57:29 -0800 (PST) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id EB21C1AE088 for ; Tue, 14 Jan 2014 02:57:27 -0800 (PST) Received: from he113598.emea1.cds.t-internal.com ([10.125.65.117]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 14 Jan 2014 11:57:15 +0100 Received: from HE113559.emea1.cds.t-internal.com (10.125.65.101) by HE113598.emea1.cds.t-internal.com (10.125.65.117) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 14 Jan 2014 11:56:23 +0100 Received: from HE111543.emea1.cds.t-internal.com ([10.125.90.96]) by HE113559.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 14 Jan 2014 11:57:12 +0100 From: To: Date: Tue, 14 Jan 2014 11:57:11 +0100 Thread-Topic: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt Thread-Index: Ac8OVA6UL1TYDt6RQySkNNWmT416oACw0ciw Message-ID: <9762ACF04FA26B4388476841256BDE02011BA9564BDA@HE111543.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 10:57:31 -0000 Support. Nic -----Urspr=FCngliche Nachricht----- Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Thomas Narten Gesendet: Freitag, 10. Januar 2014 23:34 An: sfc@ietf.org Betreff: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02= .txt WG: Our highest-priority WG deliverable is getting a problem statement done. As= has been discussed before, draft-quinn-sfc-problem-statement-02.txt has be= en the main candidate and has been the basis for getting this WG chartered. With that in mind, this is a call for WG adoption of the documment. Please note: 1) This is not WG Last Call. The document is not final, and the WG is expec= ted to modify the document's content until there is WG consensus that the c= ontent is solid. So please don't oppose adoption just because you want to s= ee changes to its content. 2) If you have objections to adoption of the document, please state your re= asons why, and explain what it would take to address your concerns. 3) If you have issues with the content, by all means raise those issues an= d we can begin a dialog about how best to address those issues. Thomas & Jim _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From hadi@mojatatu.com Tue Jan 14 03:02:01 2014 Return-Path: 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 61C121AE099 for ; Tue, 14 Jan 2014 03:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 c6lI-iuSoHrl for ; Tue, 14 Jan 2014 03:02:00 -0800 (PST) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by ietfa.amsl.com (Postfix) with ESMTP id EC3361AE0A3 for ; Tue, 14 Jan 2014 03:01:59 -0800 (PST) Received: by mail-vc0-f176.google.com with SMTP id la4so202277vcb.21 for ; Tue, 14 Jan 2014 03:01:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=byN4zA9ITZiYQZFh1mjgJnikNjafWquE5vdl5ZFTyOQ=; b=i+EXQnXA1xF345Ff2fbPsRadsSO9AwV6D5czXq/7Y/PpDa2mTaDqLQmq6i8eNB3Bb2 qchnzeTANdatYCkf+ufioB9x2alz37biwg1uFmWdGKiMpgeXmZp1ngeif8tXQdPKkXV0 2CEldqPwNh5pJ7LYkkQt2AShOC2joRzouh6e2YL5sHaY80+ZcKYcR0s0XaEtqmw+cO6g oJGgw3b1GeyEsQRnv7zw9BljboIFfYOWZ6CUfeh9eH+Q1xI0kZnDQsShs4XSfvElsmEV iML6own97Fk2uwsnpvD2WFp2cwelgS9iqU2tvdzEuj4lk7zUyb2Ch0a8pfRTgBC1fkZB XvEA== X-Gm-Message-State: ALoCoQm5hIMLyY6diZLfYwOcRDTLdf93KcSkxIS8M301eKfzKZJi/4KUkKmfcTRwxJ5do8gZRgsG X-Received: by 10.58.161.78 with SMTP id xq14mr100012veb.51.1389697308473; Tue, 14 Jan 2014 03:01:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.2.196 with HTTP; Tue, 14 Jan 2014 03:01:28 -0800 (PST) In-Reply-To: References: From: Jamal Hadi Salim Date: Tue, 14 Jan 2014 06:01:28 -0500 Message-ID: To: Thomas Narten Content-Type: text/plain; charset=ISO-8859-1 Cc: sfc@ietf.org Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 11:02:01 -0000 As all the kids have said so far: +1. per #3 i have comments - but will start a different thread. cheers, jamal On Fri, Jan 10, 2014 at 5:33 PM, Thomas Narten wrote: > WG: > > Our highest-priority WG deliverable is getting a problem statement > done. As has been discussed before, > draft-quinn-sfc-problem-statement-02.txt has been the main candidate > and has been the basis for getting this WG chartered. > > With that in mind, this is a call for WG adoption of the documment. > > Please note: > > 1) This is not WG Last Call. The document is not final, and the WG is > expected to modify the document's content until there is WG consensus > that the content is solid. So please don't oppose adoption just > because you want to see changes to its content. > > 2) If you have objections to adoption of the document, please state > your reasons why, and explain what it would take to address your > concerns. > > 3) If you have issues with the content, by all means raise those > issues and we can begin a dialog about how best to address those > issues. > > Thomas & Jim > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From hadi@mojatatu.com Tue Jan 14 03:17:32 2014 Return-Path: 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 32DC01AE090 for ; Tue, 14 Jan 2014 03:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 R2g5Mjvzwee9 for ; Tue, 14 Jan 2014 03:17:30 -0800 (PST) Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com [209.85.212.43]) by ietfa.amsl.com (Postfix) with ESMTP id B25741AE07B for ; Tue, 14 Jan 2014 03:17:30 -0800 (PST) Received: by mail-vb0-f43.google.com with SMTP id p5so961263vbn.30 for ; Tue, 14 Jan 2014 03:17:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=raJjLj7/QERsZIjQD60op+3jBx91NHwUtGytGXY1Fpk=; b=kEOuuE2COjpP3jSy3T2BhcOqCLN0skgHDJNPQdrfq0zHxz82d+CrjAOO+H3uw+VPMS 8/4ojel+WCLQEX+fwz93W2HC3JCj3S5ssW9AKhrB+ThRoi3TJmRV/K515AgK59bx4lzc RNAwPQEhVBYjZsiIpfQdlaxrVQIdnwSUwndZdp6cvox8SFN5+s/vANt44JAaq7hYgpqd IrGhlAfn287rIS4b15qbefBlmK5mceJASTQuIDFrGfSFOKspJvguHVRPPt6BfqUiZVWt lBGHOGtCc2Nwv0veQ9v9RcfHoX5sydHVNk4m0SXtXigwNrbatzdI41XdXZ48xutpT+MW 5PdA== X-Gm-Message-State: ALoCoQm72XMVxWP4BOYb9EJtmH78rOGFaKzpKxUHrwqQqoO481/feVtAllWScJXVlvUcRk+ucfqT X-Received: by 10.221.40.10 with SMTP id to10mr469221vcb.22.1389698239171; Tue, 14 Jan 2014 03:17:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.2.196 with HTTP; Tue, 14 Jan 2014 03:16:58 -0800 (PST) From: Jamal Hadi Salim Date: Tue, 14 Jan 2014 06:16:58 -0500 Message-ID: To: sfc Content-Type: text/plain; charset=ISO-8859-1 Cc: "dj@verizon.com" Subject: [sfc] comments on draft-quinn-sfc-problem-statement-02 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 11:17:32 -0000 Some context: ForCES is defining what is known as the inter-FE LFB (http://tools.ietf.org/html/draft-joachimpillai-forces-interfelfb-03) to describe chaining of network functions. One of the desires ForCES has is for horizontal scaling of network functions/service. We would like to take a network function or service and split its parts across several processing resources. This requires to pass around relevant "Pipeline stage indices" Brad McConnell did touch on it here (slide 6): http://www.ietf.org/proceedings/87/slides/slides-87-nsc-6.pdf This view is missing from the problem space. Additionally - we have a requirement to be able pass arbitrary metadata between nodes (means desire to have more than just basic 32/64 bit constructs) cheers, jamal From Ron_Parker@affirmednetworks.com Tue Jan 14 04:55:16 2014 Return-Path: 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 BADAE1AE0C3 for ; Tue, 14 Jan 2014 04:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 zAZ8_hyuAErU for ; Tue, 14 Jan 2014 04:55:15 -0800 (PST) Received: from hub021-ca-8.exch021.serverdata.net (hub021-ca-8.exch021.serverdata.net [64.78.56.73]) by ietfa.amsl.com (Postfix) with ESMTP id 19ADD1AE0BD for ; Tue, 14 Jan 2014 04:55:15 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-8.exch021.domain.local ([10.254.4.112]) with mapi id 14.03.0158.001; Tue, 14 Jan 2014 04:55:03 -0800 From: Ron Parker To: Jamal Hadi Salim Thread-Topic: [sfc] comments on draft-quinn-sfc-problem-statement-02 Thread-Index: AQHPERo2rbD8mkh5hEONvgk86cvjY5qELXrQ Date: Tue, 14 Jan 2014 12:55:03 +0000 Message-ID: <4105A88A-91D5-4321-B215-CFA96AE3208F@affirmednetworks.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dj@verizon.com" , sfc Subject: Re: [sfc] comments on draft-quinn-sfc-problem-statement-02 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 12:55:17 -0000 Hi, Jamal.=20 I'm not very familiar with the details of FORCES, so I have a few questions= .=20 Just as the referenced slide points out that DPI at every service function = is undesirable, it may be that fully qualified flow tracking at every servi= ce function is undesirable, too, although clearly some will need to in orde= r to perform their function. How would FORCES handle that? Would full f= low learning become mandatory? In FORCES, Is there a signaling component operating at the fully qualified = flow level? In a network with 10's or 100's of millions of active fully qu= alified flows, what are the scaling properties of FORCES? Thanks.=20 Ron > On Jan 14, 2014, at 6:17 AM, "Jamal Hadi Salim" wrote= : >=20 > Some context: > ForCES is defining what is known as the inter-FE LFB > (http://tools.ietf.org/html/draft-joachimpillai-forces-interfelfb-03) > to describe chaining of network functions. >=20 > One of the desires ForCES has is for horizontal scaling of > network functions/service. > We would like to take a network function or service and split > its parts across several processing resources. This requires to > pass around relevant "Pipeline stage indices" > Brad McConnell did touch on it here (slide 6): > http://www.ietf.org/proceedings/87/slides/slides-87-nsc-6.pdf >=20 > This view is missing from the problem space. >=20 > Additionally - we have a requirement to be able pass arbitrary > metadata between nodes (means desire to have more than just > basic 32/64 bit constructs) >=20 > cheers, > jamal > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From meadorg@cisco.com Tue Jan 14 05:12:05 2014 Return-Path: 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 EA93E1AE0C3 for ; Tue, 14 Jan 2014 05:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 dqccg-4Jw4ZF for ; Tue, 14 Jan 2014 05:12:02 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 005541AE0CC for ; Tue, 14 Jan 2014 05:11:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1191; q=dns/txt; s=iport; t=1389705105; x=1390914705; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=X7rjWFDbX4Y84pK3L3v1ze15CKGaCuNDxYBryNlzrFg=; b=fDzLreeZ6+bRPdWiv44mA70BnYnntmDuRC+T6NZyCyyUW6N+Sa/t1pyc EbgomTS/mYo9+Uz0aLL17+yVzWbEscaJ973w3Y4dIJ5yHUgJrSL2t12i5 C/UzlXpLrK5zE3qozmS/VrEdNSCP79csnDsJhIA+YKSaUqNwYND4m1iIx Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAL421VKtJV2c/2dsb2JhbABagws4VrpWgRMWdIIlAQEBAwEBAQEaHTQQCwIBCDYQJwslAgQTh3wIDcRgEwSPDoMkgRMEmB6SFYMtgio X-IronPort-AV: E=Sophos;i="4.95,658,1384300800"; d="scan'208";a="297021145" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 14 Jan 2014 13:11:44 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0EDBitl005540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 14 Jan 2014 13:11:44 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.191]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Tue, 14 Jan 2014 07:11:44 -0600 From: "Guy Meador III (meadorg)" To: "sfc@ietf.org" Thread-Topic: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt Thread-Index: AQHPESoscXQbo4KZiki3JWbIN8mBtQ== Date: Tue, 14 Jan 2014 13:11:44 +0000 Message-ID: <04A466E0-288E-41EC-9D16-F578452E7D13@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.94.197] Content-Type: text/plain; charset="us-ascii" Content-ID: <24F2FE5BACED58458E9DE21B5A0F230A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] Call for WG Adoption of draft-quinn-sfc-problem-statement-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 13:12:05 -0000 +1 on support. -Guy On Jan 10, 2014, at 5:33 PM, Thomas Narten wrote: > WG: >=20 > Our highest-priority WG deliverable is getting a problem statement > done. As has been discussed before, > draft-quinn-sfc-problem-statement-02.txt has been the main candidate > and has been the basis for getting this WG chartered. >=20 > With that in mind, this is a call for WG adoption of the documment. >=20 > Please note: >=20 > 1) This is not WG Last Call. The document is not final, and the WG is > expected to modify the document's content until there is WG consensus > that the content is solid. So please don't oppose adoption just > because you want to see changes to its content. >=20 > 2) If you have objections to adoption of the document, please state > your reasons why, and explain what it would take to address your > concerns. >=20 > 3) If you have issues with the content, by all means raise those > issues and we can begin a dialog about how best to address those > issues. >=20 > Thomas & Jim >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From jguichar@cisco.com Tue Jan 14 05:19:17 2014 Return-Path: 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 A17701AE0CE for ; Tue, 14 Jan 2014 05:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 DD3GgJ-1Fz0r for ; Tue, 14 Jan 2014 05:19:16 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 115001AE0CA for ; Tue, 14 Jan 2014 05:19:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1470; q=dns/txt; s=iport; t=1389705545; x=1390915145; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=F7aG/Z5SXXPkDTk/P2qxWvPiKjITam5ytt4furdK/Qk=; b=liESMH3hH6P9QU+3U4Vj+/wPA6tsy4njMUdvxmxHyuZEsuK5NyOJowQ6 /gtZ/n0lcGB34kUEFoAtxEivxCnU8JV+HlqAOrSmpwvKqZv6cJMzJa67I KSUf+RoFUaOYSLkHlcnIcs2N70lRPeWiVPLPnysNHYsSeemrzjqrDB6Ro Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAPw41VKtJXG//2dsb2JhbABagws4VrpWgRMWdIInAQICAQEBNzQGBRIBCBIkNwsXDgIEAQ0FCRKHaQ3EURePBweENwSYHoEwkGWDLYIq X-IronPort-AV: E=Sophos;i="4.95,658,1384300800"; d="scan'208";a="12717674" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-3.cisco.com with ESMTP; 14 Jan 2014 13:19:04 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0EDJ4Bk015702 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Jan 2014 13:19:04 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.157]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Tue, 14 Jan 2014 07:19:04 -0600 From: "Jim Guichard (jguichar)" To: Jamal Hadi Salim , sfc Thread-Topic: [sfc] comments on draft-quinn-sfc-problem-statement-02 Thread-Index: AQHPERo1Jt9vzu342U6WIp+JbNP2NJqERO4A Date: Tue, 14 Jan 2014 13:19:03 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.183] Content-Type: text/plain; charset="us-ascii" Content-ID: <46299669620BBE4E9601EB7D39DBAA09@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dj@verizon.com" Subject: Re: [sfc] comments on draft-quinn-sfc-problem-statement-02 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 13:19:17 -0000 Hi Jamal, Thanks for this input. Comments inline. On 1/14/14 6:16 AM, "Jamal Hadi Salim" wrote: >Some context: >ForCES is defining what is known as the inter-FE LFB >(http://tools.ietf.org/html/draft-joachimpillai-forces-interfelfb-03) >to describe chaining of network functions. > >One of the desires ForCES has is for horizontal scaling of >network functions/service. >We would like to take a network function or service and split >its parts across several processing resources. This requires to >pass around relevant "Pipeline stage indices" >Brad McConnell did touch on it here (slide 6): >http://www.ietf.org/proceedings/87/slides/slides-87-nsc-6.pdf > >This view is missing from the problem space. Jim> I agree. Do you have suggested text that can be reviewed and discussed further? > >Additionally - we have a requirement to be able pass arbitrary >metadata between nodes (means desire to have more than just >basic 32/64 bit constructs) Jim> I think this is an area that will require some discussion as part of the SFC architecture. The problem statement has no "solution" text and simply states that metadata between the network and SF's, and between SF's, is needed. The format of that metadata should be discussed outside of the problem statement. > >cheers, >jamal >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From hadi@mojatatu.com Tue Jan 14 06:05:33 2014 Return-Path: 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 7D0D71AE0EA for ; Tue, 14 Jan 2014 06:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 6dLcl15g-7ri for ; Tue, 14 Jan 2014 06:05:31 -0800 (PST) Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) by ietfa.amsl.com (Postfix) with ESMTP id 715AC1AE0E5 for ; Tue, 14 Jan 2014 06:05:31 -0800 (PST) Received: by mail-ve0-f177.google.com with SMTP id pa12so1878466veb.8 for ; Tue, 14 Jan 2014 06:05:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=QSlxcco+1csuw9Z4Y2u0Whv/Xf8JS7fqD2S9enkoO3Q=; b=d8EkwnFTXW3G2es0AcNjtazQ72jv9+eGundyGu7P8J2EQ6ptdNQ6hH3N3NRi36Y8nU vALBNKnjeG+NN7A2dCtP7HX48TF0z4W6ZTIYfLoGLBcO5k5UDjctuUMoldojawG8AEJc DBoadzj7j25NgX5L5YcFEaXWNQPCEF5An7KCM8qFA3DV9Nwb6Uy6dB/ODb1tYrv6qbmC Pv5QihVKFHSdKNmjqFkbNbyHQi2hcqw/+HeZVk6psNOPWGWWOR9c9mK82wyyKaiuCv7p FD1nQTV4dTut/loqjvkwLUYZ7dB8+limBq3Ol0HrPYI/ozptvVwl2yaSMVWU1iUrxwuS BBww== X-Gm-Message-State: ALoCoQlq/NkbDvtJnu5/6dff/Hj/VBQYOBHGvWo737lLvBdFGE1yFfuC76M181+VjOeT6xRcwa93 X-Received: by 10.221.24.200 with SMTP id rf8mr178934vcb.65.1389708319874; Tue, 14 Jan 2014 06:05:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.2.196 with HTTP; Tue, 14 Jan 2014 06:04:58 -0800 (PST) In-Reply-To: <4105A88A-91D5-4321-B215-CFA96AE3208F@affirmednetworks.com> References: <4105A88A-91D5-4321-B215-CFA96AE3208F@affirmednetworks.com> From: Jamal Hadi Salim Date: Tue, 14 Jan 2014 09:04:58 -0500 Message-ID: To: Ron Parker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "forces@ietf.org" , "dj@verizon.com" , sfc Subject: Re: [sfc] comments on draft-quinn-sfc-problem-statement-02 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 14:05:33 -0000 Hi Ron, On Tue, Jan 14, 2014 at 7:55 AM, Ron Parker wrote: > Hi, Jamal. > > I'm not very familiar with the details of FORCES, so I have a few questio= ns. > > Just as the referenced slide points out that DPI at every service functio= n is undesirable, it may be that fully qualified flow tracking at every ser= vice function is undesirable, too, although clearly some will need to in or= der to perform their function. How would FORCES handle that? Would full= flow learning become mandatory? > The whole point behind pipeline indexing is to avoid things of that sort. It would be upto the service definition: as an _example_, something like DPI would happen at one stage of the pipeline and the results are useable further down stream. > In FORCES, Is there a signaling component operating at the fully qualifie= d flow level? In a network with 10's or 100's of millions of active fully = qualified flows, what are the scaling properties of FORCES? > I am not sure i understood the context of "fully qualified flow level" but let me see if i can answer your question (and i worry this list is the wrong place for such a discussion, come to the ForCES list which I am CCing with any further discussion). ForCES defines a model per network function. (ForCES term for a network function would be LFB). A service would then be a graph of instantiated network functions To your scaling question. You scale the service either: - vertically by using a higher performing network function (eg an ASIC assisted DPI engine as opposed to purely software running in user space) - horizontally as specified by creating appropriate service graphs that pipeline (as pointed in that draft) or you could go further and use systolic approaches (as an example take a look at: http://tools.ietf.org/search/draft-haleplidis-forces-packet-paralleliza= tion-04) Now - dont let the two drafts confuse you because they take a very fine gra= ined approach to what a network function. The protocol is designed to be scale for control activities where throughput and latency are relevant attributes. It is also used for management where usability maybe more of value. So scaling was an important part of the initial design. Not sure if i answered your question. If you want a quick dump on the features: http://www.ietf.org/proceedings/86/slides/slides-86-sdnrg-2.pdf We are working to publish a tutorial RSN. cheers, jamal > Thanks. > > Ron > > >> On Jan 14, 2014, at 6:17 AM, "Jamal Hadi Salim" wrot= e: >> >> Some context: >> ForCES is defining what is known as the inter-FE LFB >> (http://tools.ietf.org/html/draft-joachimpillai-forces-interfelfb-03) >> to describe chaining of network functions. >> >> One of the desires ForCES has is for horizontal scaling of >> network functions/service. >> We would like to take a network function or service and split >> its parts across several processing resources. This requires to >> pass around relevant "Pipeline stage indices" >> Brad McConnell did touch on it here (slide 6): >> http://www.ietf.org/proceedings/87/slides/slides-87-nsc-6.pdf >> >> This view is missing from the problem space. >> >> Additionally - we have a requirement to be able pass arbitrary >> metadata between nodes (means desire to have more than just >> basic 32/64 bit constructs) >> >> cheers, >> jamal >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc From hadi@mojatatu.com Tue Jan 14 06:17:56 2014 Return-Path: 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 EA7C41ADFB6 for ; Tue, 14 Jan 2014 06:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 qxN7SJfhRPdI for ; Tue, 14 Jan 2014 06:17:54 -0800 (PST) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9C31ADF76 for ; Tue, 14 Jan 2014 06:17:54 -0800 (PST) Received: by mail-vc0-f181.google.com with SMTP id ie18so281819vcb.40 for ; Tue, 14 Jan 2014 06:17:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=NP49bDhFJpn1ALrPCpSraqxIMsU/fufObRrW9OcVo6Y=; b=CFZQ8LVTQzSR7PuoILh5uZAdCCHnB40H1g6XJRbx3gHZc6I+iBn34yxvL83gT3+x2B EXJYsLFQS3HNSMLQsx+IUyRyCyIc5L3ARvGaSELB49NHDn0AqBlF3seiHXssX+zCCizW f2CRtEYh1o/WTUe482IqQLacvLpxa1muAL/rXvFNcLNyXL4cHSBv/hyteVukwcIFDFAY iCluz0ad7GuQCuHU/tabafxbg33Fmxz2KXRb+pvE7c9T+N/T9wlAgbsW+tB/ZjVvt2TE MaDNUVMrkYf8sFO1qsJiFlgFgw9PPlrGDCZ+FEZI+KrUNUZD1ulKTYgtRP8tuH3mt97L y4WA== X-Gm-Message-State: ALoCoQlKR/Edpgp+ulxNcR6UuSMY0boT2LhuOAJnNba4fM4lVGX3P7qsxAHvOblbr5+/1zhtEMFt X-Received: by 10.58.106.70 with SMTP id gs6mr1190708veb.28.1389709062739; Tue, 14 Jan 2014 06:17:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.2.196 with HTTP; Tue, 14 Jan 2014 06:17:22 -0800 (PST) In-Reply-To: References: From: Jamal Hadi Salim Date: Tue, 14 Jan 2014 09:17:22 -0500 Message-ID: To: "Jim Guichard (jguichar)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "dj@verizon.com" , sfc Subject: Re: [sfc] comments on draft-quinn-sfc-problem-statement-02 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 14:17:56 -0000 Hi Jim, On Tue, Jan 14, 2014 at 8:19 AM, Jim Guichard (jguichar) wrote: > Hi Jamal, > > Thanks for this input. Comments inline. >>This view is missing from the problem space. > > Jim> I agree. Do you have suggested text that can be reviewed and > discussed further? > Ok, let me re-scan the draft one more time and then i will suggest some text. >>Additionally - we have a requirement to be able pass arbitrary >>metadata between nodes (means desire to have more than just >>basic 32/64 bit constructs) > > Jim> I think this is an area that will require some discussion as part of > the SFC architecture. The problem statement has no "solution" text and > simply states that metadata between the network and SF's, and between > SF's, is needed. The format of that metadata should be discussed outside > of the problem statement. > Fair enough. I am hoping i can bring it up later. cheers, jamal From haibin.song@huawei.com Wed Jan 15 19:43:12 2014 Return-Path: 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 288391AE1C9 for ; Wed, 15 Jan 2014 19:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 bIAxI9xZp-ca for ; Wed, 15 Jan 2014 19:43:10 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 28FBA1AE1B4 for ; Wed, 15 Jan 2014 19:43:10 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCN59840; Thu, 16 Jan 2014 03:42:57 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 16 Jan 2014 03:42:11 +0000 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 16 Jan 2014 03:42:56 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Thu, 16 Jan 2014 11:42:51 +0800 From: "Songhaibin (A)" To: "sfc@ietf.org" Thread-Topic: my comments to draft-beliveau-sfc-architecture-00 Thread-Index: Ac8SbQfHNM9JNyLZRGS2JVV23C/3hg== Date: Thu, 16 Jan 2014 03:42:51 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [sfc] my comments to draft-beliveau-sfc-architecture-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 03:43:12 -0000 Dear authors, Here are some comments after my reading of this document, and most of them = are editorial. Generally the document is easy to understand. But it also ha= s many confusing terms and does not have technical details.=20 1) Section 2: Service Function Locator(SF-Loc): A unique name or address= which identifies each Service Function. When multiple instances of the... [Haibin] each Service Function -> each Service Function instance 2) "SFC network" is used multiple times without definition. What is its dif= ference with SFC-IN? If they are the same thing, I suggest to use the same = terminology throughout the document. 3) Section 3.2, figure 1: this figure uses SFC-ID instead of SC-ID defined = in the terminology? If they are the same thing, I suggest to use the same t= erminology throughout the document. 4)Section 3.3, The Service Chaining Infrastructure (SC-IN) consists of Serv= ice Chaining Enforcement Points (SCEP) and Service Functions interconnected= as a network. [Haibin] it is conflict with the terminology in section 2. In section 2, SC= -IN only consists of one or more SCEPs. 5) Section 3.3, When entering an SC-IN, an ingress SCEP which contains an S= C-CL will map packets into a specific Service Function Path. Once this map= ping is done, the SC-FWD will determine the locator for the next SF on the = Service Function Path and forward the packet to the SF to be invoked. [Haibin]With regarding to the next SF, I think if the next SF is connected = to this SCEP, then the SC-FWD forwards traffic to SF, otherwise, it should = forward to the next SCEP which connects to the next SF. Because this docume= nt forbids the direct communication between SFs. All traffic must go throug= h SCEPs. It would be helpful to understand if the authors can give a illust= rative figure on how the traffic goes the nodes including SFs and SCEPs. 6) Section 3.4, what is Service Function Controller? If it is the same with= Service Chain Controller defined in Section 3.6, I suggest to use the same= terminology throughout the document. 7)Section 7, I do not think RFC 3022, 6092, and 6146 are normative referenc= es. Best Regards! -Haibin From jguichar@cisco.com Tue Jan 21 11:05:15 2014 Return-Path: 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 DDA7C1A01E2 for ; Tue, 21 Jan 2014 11:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 YAG3Oj8T0LoN for ; Tue, 21 Jan 2014 11:05:14 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2011A01C0 for ; Tue, 21 Jan 2014 11:05:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2564; q=dns/txt; s=iport; t=1390331114; x=1391540714; h=from:to:cc:subject:date:message-id:mime-version; bh=899fZjSRh1+qBAYyj5++15xsAZyTCHsWq1k16LEDhY0=; b=PxIMmBDufOAl5rs3FoIbHzReEhG3AkJdmAhZePBlmg71qx6tAdlLf+UL 02cbXu4dHqd6aby0nVt2KuQ+/lVU4MHSLGnkt5WDUyg6PDX6zw+T38C7b ZfsX8Y7kPkxNnhPbNn+qgGva1Ka+hgTwIYUHAySMeaoOAHECTZWqHIMhA w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8HAPzD3lKtJXHB/2dsb2JhbABZgkdEOFazHohSgRUWdIIsbgsSAQwBcycEDogKDcMtF44dEQFQhD8EmCKBMpBmgy2BcTk X-IronPort-AV: E=Sophos;i="4.95,697,1384300800"; d="scan'208,217";a="298753923" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 21 Jan 2014 19:05:14 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0LJ5EKc022978 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jan 2014 19:05:14 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.207]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 13:05:13 -0600 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: IPR check for draft-quinn-sfc-problem-statement Thread-Index: AQHPFtu2NSEh36Zfh0G0Wjova3ew6A== Date: Tue, 21 Jan 2014 19:05:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.183] Content-Type: multipart/alternative; boundary="_000_CF042F13145EDjguicharciscocom_" MIME-Version: 1.0 Cc: Thomas Narten Subject: [sfc] IPR check for draft-quinn-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 19:05:16 -0000 --_000_CF042F13145EDjguicharciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This email serves as a poll for knowledge of any IPR that applies to draft = [1], to ensure that IPR has been disclosed in compliance with IETF IPR rule= s (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email whether or not you are aware of any relevant IPR. The draft will no= t be adopted until a response has been received from each author and major = contributor. If you are on the SFC WG mailing list but are not listed as an author or co= ntributor, then please explicitly respond only if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. Thank you, Jim & Thomas SFC chairs [1] http://tools.ietf.org/id/draft-quinn-sfc-problem-statement-02.txt --_000_CF042F13145EDjguicharciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <069A310ECC97414D984214CAA23B35C9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
This email serves as a poll for knowledge of any IPR that applies to d= raft [1], to ensure that IPR has been disclosed in compliance with IETF IPR= rules (see RFCs 3979, 4879, 3669 and 5378 for more details). 

If you are listed as a document author or contributor please respond t= o this email whether or not you are aware of any relevant IPR. The draft wi= ll not be adopted until a response has been received from each author and m= ajor contributor. 

If you are on the SFC WG mailing list but are not listed as an author = or contributor, then please explicitly respond only if you are aware of any= IPR that has not yet been disclosed in conformance with IETF rules. <= /div>

Thank you,

Jim & Thomas
SFC chairs

--_000_CF042F13145EDjguicharciscocom_-- From jguichar@cisco.com Tue Jan 21 11:14:23 2014 Return-Path: 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 8B3ED1A021F for ; Tue, 21 Jan 2014 11:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 cu5dsT6WOdgN for ; Tue, 21 Jan 2014 11:14:21 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id A26D71A0234 for ; Tue, 21 Jan 2014 11:14:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1532; q=dns/txt; s=iport; t=1390331661; x=1391541261; h=from:to:subject:date:message-id:mime-version; bh=xDof8uHxNJ6S2XWZueDHQjz+BhK4JDlj9t6JC7ox4SA=; b=O1/X/NprhvwklrPp2sDVc6E2Rjor+qHKjKsd0NhS/nZXSPCx3zqv2Upm 2Rr0HxCsaaO3mzg/hD61N/a69lEM+WgL7vylH/b4Rj5N9jXaD7zOx3fnn K2r2QydIPJvVMlfTZQe763i9tPblAsIItwaU2FLQxU8gb938z924AK9YH 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAM7G3lKtJXG8/2dsb2JhbABZgkdEgQ69BhZ0ghwQHW4BCwF0JwSIGJgEqzYXjh0RAYUPBJgikhiDLYFxOQ X-IronPort-AV: E=Sophos;i="4.95,697,1384300800"; d="scan'208,217";a="14439414" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-2.cisco.com with ESMTP; 21 Jan 2014 19:14:07 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0LJE7Mp032680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 21 Jan 2014 19:14:07 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.207]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 13:14:07 -0600 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: WG adoption of draft-quinn-sfc-problem-statement-02 Thread-Index: AQHPFtz0BBXmRpg9rk2thNSnYBnFRQ== Date: Tue, 21 Jan 2014 19:14:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.183] Content-Type: multipart/alternative; boundary="_000_CF04312B14604jguicharciscocom_" MIME-Version: 1.0 Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 19:14:23 -0000 --_000_CF04312B14604jguicharciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thomas and I would like to remind you of the ongoing WG call for adoption o= f draft-quinn-sfc-problem-statement-02. We have received numerous positive = responses to our original email and plan to formally close out the call for= adoption this coming Friday (1/24/14). If folks have any additional commen= ts or concerns please voice them before this Friday. Jim & Thomas SFC chairs. --_000_CF04312B14604jguicharciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Thomas and I would like to remind you of the ongoing WG call for adopt= ion of draft-quinn-sfc-problem-statement-02. We have received numerous posi= tive responses to our original email and plan to formally close out the cal= l for adoption this coming Friday (1/24/14). If folks have any additional comments or concerns please voice = them before this Friday.

Jim & Thomas
SFC chairs. 
--_000_CF04312B14604jguicharciscocom_-- From tnadeau@lucidvision.com Tue Jan 21 11:55:00 2014 Return-Path: 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 E94DB1A0213 for ; Tue, 21 Jan 2014 11:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] 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 x3ZP-yGa8N6U for ; Tue, 21 Jan 2014 11:54:59 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 036221A014D for ; Tue, 21 Jan 2014 11:54:58 -0800 (PST) Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 93B6926C13B6; Tue, 21 Jan 2014 14:54:58 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_7B74469E-7327-4DA4-88FC-27294EFC18B6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: Date: Tue, 21 Jan 2014 14:54:58 -0500 Message-Id: <6A6E5EEA-975B-482B-AFC7-7472DB9C1B00@lucidvision.com> References: To: Guichard Jim X-Mailer: Apple Mail (2.1827) Cc: Thomas Narten , "sfc@ietf.org" Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 19:55:01 -0000 --Apple-Mail=_7B74469E-7327-4DA4-88FC-27294EFC18B6 Content-Type: multipart/alternative; boundary="Apple-Mail=_62EB99C6-5881-4F78-BA17-0018E5A5C0F0" --Apple-Mail=_62EB99C6-5881-4F78-BA17-0018E5A5C0F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii None from my end. On Jan 21, 2014:2:05 PM, at 2:05 PM, Jim Guichard (jguichar) = wrote: > This email serves as a poll for knowledge of any IPR that applies to = draft [1], to ensure that IPR has been disclosed in compliance with IETF = IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).=20 >=20 > If you are listed as a document author or contributor please respond = to this email whether or not you are aware of any relevant IPR. The = draft will not be adopted until a response has been received from each = author and major contributor.=20 >=20 > If you are on the SFC WG mailing list but are not listed as an author = or contributor, then please explicitly respond only if you are aware of = any IPR that has not yet been disclosed in conformance with IETF rules.=20= >=20 > Thank you, >=20 > Jim & Thomas > SFC chairs >=20 > [1] http://tools.ietf.org/id/draft-quinn-sfc-problem-statement-02.txt > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail=_62EB99C6-5881-4F78-BA17-0018E5A5C0F0 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

None from my end.

On Jan 21, 2014:2:05 PM, at 2:05 PM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:

This email serves as a poll for knowledge of any IPR that applies to draft [1], to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). 

If you are listed as a document author or contributor please respond to this email whether or not you are aware of any relevant IPR. The draft will not be adopted until a response has been received from each author and major contributor. 

If you are on the SFC WG mailing list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. 

Thank you,

Jim & Thomas
SFC chairs

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

--Apple-Mail=_62EB99C6-5881-4F78-BA17-0018E5A5C0F0-- --Apple-Mail=_7B74469E-7327-4DA4-88FC-27294EFC18B6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJS3tCSAAoJEPcO+I7eiUJZONgP/3soAFNvOqBYiepcTzdPiJRX e5Cjh1wHMcKk87+CfoTIJsSUzHeQOACfejHzyDJJ8cWzyeJlgqLLu4SUzzonHifr sy+tnVOEovbeI6iwuZg4UoxZKDwJrFq4hQpW3p0X3Tz+4i0wr/SdFWpU1C99VcNp cXInqot4OSJ3n6NwsVMP88t5Vlh90y1K7B+qG6SOvnvZnFgv4ACJdzfD7Q8ei5fI iEgmyOQXIE4SIQRtFGF53J0hItOZ15L/y1gdLU6kf9jM7+btudleP5y79/qRyand +lIaBxvq17wNH3utYfL8izkUIlF1GqemA6ydAZNtHKz/9Pu866iPnkL0t+5nqVxr un3bSa9yF9Lr9jaeIz0prcA3DLLSle5i/LiCyMQQwFFgX1Q3i9zPYX0BMiNPSmVR Mhu8cmRuFiLmHGnZoLLhUN3H0nN2xMr3Bstry3t1Mkxar7nf+v0+s/ynyzhDE2At Ymr37/eFicgWv3Zu6z55HAo0EqH+4esZSNT090him9K6zkQXYryIThaGEpQilvDY rE6t1pEtvhGYaIvTKeHIdmdoKh4JCcDa+THX7qsZ+CEPed2wSXspaE/Zr6FtguWn uHbuT1BldOg8u7Lcq1Ed/fqOqzmCecY1ks3D2ca0vdmLJI+NTm6PIXjpMQN9Xob1 d9FmD+gEs6k3EcQt/KES =fNFe -----END PGP SIGNATURE----- --Apple-Mail=_7B74469E-7327-4DA4-88FC-27294EFC18B6-- From kegray@cisco.com Tue Jan 21 12:18:37 2014 Return-Path: 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 978201A0247 for ; Tue, 21 Jan 2014 12:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 j1SjAxgS2rWR for ; Tue, 21 Jan 2014 12:18:35 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6261A0182 for ; Tue, 21 Jan 2014 12:18:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5362; q=dns/txt; s=iport; t=1390335515; x=1391545115; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=mbddi3Q6yZyGQ8xJK2HFiK1no7UmRhdmyIYJWqNoWMM=; b=XUnQAiwN7PGz5eJaszxvQBjFwn2ueXzz2hksycSEbbc1IkVp/tOfHIUC z7tysJoE/NrEF9Prmjob33estUs+SpA9dPacCiQhCM1TYsxN2K+0MeK8I GV933GF0KsHPDg9ic74qpUzeSbfiG9aL8JTxHBQv71YuFXJLlPz5OqEjC M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEHABjV3lKtJV2c/2dsb2JhbABZgkdEOFazIIhSgRYWdIIlAQEBBAEBAWsLEgEIDgMDAQIoLgsUCQgCBAENBYgFDcMUF44dEQE/DQQHhDgEmCKBMpBmgy2BcTk X-IronPort-AV: E=Sophos;i="4.95,697,1384300800"; d="scan'208,217";a="14458438" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP; 21 Jan 2014 20:18:35 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0LKIYjE018268 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jan 2014 20:18:34 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.76]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 14:18:34 -0600 From: "Ken Gray (kegray)" To: Thomas Nadeau , "Jim Guichard (jguichar)" Thread-Topic: [sfc] IPR check for draft-quinn-sfc-problem-statement Thread-Index: AQHPFtu2NSEh36Zfh0G0Wjova3ew6JqP/DAA//+Ae4A= Date: Tue, 21 Jan 2014 20:18:34 +0000 Message-ID: In-Reply-To: <6A6E5EEA-975B-482B-AFC7-7472DB9C1B00@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.147.142] Content-Type: multipart/alternative; boundary="_000_CF041613235Ckegrayciscocom_" MIME-Version: 1.0 Cc: Thomas Narten , "sfc@ietf.org" Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 20:18:37 -0000 --_000_CF041613235Ckegrayciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ditto From: Thomas Nadeau > Date: Tuesday, January 21, 2014 2:54 PM To: "Jim Guichard (jguichar)" > Cc: Thomas Narten >, "sfc@ietf.= org" > Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement None from my end. On Jan 21, 2014:2:05 PM, at 2:05 PM, Jim Guichard (jguichar) > wrote: This email serves as a poll for knowledge of any IPR that applies to draft = [1], to ensure that IPR has been disclosed in compliance with IETF IPR rule= s (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email whether or not you are aware of any relevant IPR. The draft will no= t be adopted until a response has been received from each author and major = contributor. If you are on the SFC WG mailing list but are not listed as an author or co= ntributor, then please explicitly respond only if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. Thank you, Jim & Thomas SFC chairs [1] http://tools.ietf.org/id/draft-quinn-sfc-problem-statement-02.txt _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_CF041613235Ckegrayciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Ditto

From: Thomas Nadeau <tnadeau@lucidvision.com>
Date: Tuesday, January 21, 2014 2:5= 4 PM
To: "Jim Guichard (jguichar)&q= uot; <jguichar@cisco.com> Cc: Thomas Narten <narten@us.ibm.com>, "sfc@ietf.org" <sf= c@ietf.org>
Subject: Re: [sfc] IPR check for dr= aft-quinn-sfc-problem-statement


None from m= y end.

On Jan 21, 2014:2:05 PM, at 2:05 PM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:

This email serves as a poll for knowledge of any IPR that applies to d= raft [1], to ensure that IPR has been disclosed in compliance with IETF IPR= rules (see RFCs 3979, 4879, 3669 and 5378 for more details). 

If you are listed as a document author or contributor please respond t= o this email whether or not you are aware of any relevant IPR. The draft wi= ll not be adopted until a response has been received from each author and m= ajor contributor. 

If you are on the SFC WG mailing list but are not listed as an author = or contributor, then please explicitly respond only if you are aware of any= IPR that has not yet been disclosed in conformance with IETF rules. <= /div>

Thank you,

Jim & Thomas
SFC chairs

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

 --_000_CF041613235Ckegrayciscocom_-- From smkumar@cisco.com Tue Jan 21 14:54:19 2014 Return-Path: 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 2A5F11A0263 for ; Tue, 21 Jan 2014 14:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 ecB0_Q9DcU6H for ; Tue, 21 Jan 2014 14:54:17 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5811A0240 for ; Tue, 21 Jan 2014 14:54:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7372; q=dns/txt; s=iport; t=1390344857; x=1391554457; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=n2eE4UAi8AqdQSWpb0yz2AM9xhilEwTGTi+QAjd6+Uo=; b=QCJzbbBtY3Fa2XkEQYh8+FyDrhRkYsnP7LthXsGBGm2DMSbUx0UjpDu7 PJHkcO2L8V7MkyaybyEk4KlJu6QxeIEFsC9IJ9QDD27bTt/Up3EeIIxKe 1SjlAFTy/fEIP19I6f3pdZiG3/zCCn5jPNBHUKPMoRiaJNyv/QvzVFFHi E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8HAK753lKtJV2b/2dsb2JhbABagkdEOEoMsx2IUoEXFnSCJQEBAQQBAQFrCxIBCBEDAQIoLgsUCQgCBA4FiAUNwmMXjh0RAT8NBAeEOASYIoEykGaDLYFxOQ X-IronPort-AV: E=Sophos;i="4.95,697,1384300800"; d="scan'208,217";a="298747605" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 21 Jan 2014 22:54:17 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0LMsGnB011538 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jan 2014 22:54:16 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.228]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 16:54:16 -0600 From: "Surendra Kumar (smkumar)" To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] IPR check for draft-quinn-sfc-problem-statement Thread-Index: AQHPFtu2NSEh36Zfh0G0Wjova3ew6JqP/DAA//+Ae4CAACuAgA== Date: Tue, 21 Jan 2014 22:54:16 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.155.165.126] Content-Type: multipart/alternative; boundary="_000_CF043A3F2D1ADsmkumarciscocom_" MIME-Version: 1.0 Cc: Thomas Narten , "sfc@ietf.org" Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 22:54:19 -0000 --_000_CF043A3F2D1ADsmkumarciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Surendra. From: "Ken Gray (kegray)" > Date: Tuesday, January 21, 2014 12:18 PM To: Thomas Nadeau >= , "Jim Guichard (jguichar)" > Cc: Thomas Narten >, "sfc@ietf.= org" > Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement Ditto From: Thomas Nadeau > Date: Tuesday, January 21, 2014 2:54 PM To: "Jim Guichard (jguichar)" > Cc: Thomas Narten >, "sfc@ietf.= org" > Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement None from my end. On Jan 21, 2014:2:05 PM, at 2:05 PM, Jim Guichard (jguichar) > wrote: This email serves as a poll for knowledge of any IPR that applies to draft = [1], to ensure that IPR has been disclosed in compliance with IETF IPR rule= s (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email whether or not you are aware of any relevant IPR. The draft will no= t be adopted until a response has been received from each author and major = contributor. If you are on the SFC WG mailing list but are not listed as an author or co= ntributor, then please explicitly respond only if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. Thank you, Jim & Thomas SFC chairs [1] http://tools.ietf.org/id/draft-quinn-sfc-problem-statement-02.txt _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_CF043A3F2D1ADsmkumarciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
+1

Surendra.

From: "Ken Gray (kegray)"= <kegray@cisco.com>
Date: Tuesday, January 21, 2014 12:= 18 PM
To: Thomas Nadeau <tnadeau@lucidvision.com>, "Jim Gu= ichard (jguichar)" <jguichar@= cisco.com>
Cc: Thomas Narten <narten@us.ibm.com>, "sfc@ietf.org" <sf= c@ietf.org>
Subject: Re: [sfc] IPR check for dr= aft-quinn-sfc-problem-statement

Ditto

From: Thomas Nadeau <tnadeau@lucidvision.com>
Date: Tuesday, January 21, 2014 2:5= 4 PM
To: "Jim Guichard (jguichar)&q= uot; <jguichar@cisco.com> Cc: Thomas Narten <narten@us.ibm.com>, "sfc@ietf.org" <sf= c@ietf.org>
Subject: Re: [sfc] IPR check for dr= aft-quinn-sfc-problem-statement


None from m= y end.

On Jan 21, 2014:2:05 PM, at 2:05 PM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:

This email serves as a poll for knowledge of any IPR that applies to d= raft [1], to ensure that IPR has been disclosed in compliance with IETF IPR= rules (see RFCs 3979, 4879, 3669 and 5378 for more details). 

If you are listed as a document author or contributor please respond t= o this email whether or not you are aware of any relevant IPR. The draft wi= ll not be adopted until a response has been received from each author and m= ajor contributor. 

If you are on the SFC WG mailing list but are not listed as an author = or contributor, then please explicitly respond only if you are aware of any= IPR that has not yet been disclosed in conformance with IETF rules. <= /div>

Thank you,

Jim & Thomas
SFC chairs

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

 --_000_CF043A3F2D1ADsmkumarciscocom_-- From rmanur@broadcom.com Tue Jan 21 15:08:38 2014 Return-Path: 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 4D5A61A0232 for ; Tue, 21 Jan 2014 15:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] 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 CkTaKqajy4LM for ; Tue, 21 Jan 2014 15:08:35 -0800 (PST) Received: from mail-gw1-out.broadcom.com (mail-gw1-out.broadcom.com [216.31.210.62]) by ietfa.amsl.com (Postfix) with ESMTP id AE2001A01CD for ; Tue, 21 Jan 2014 15:08:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,697,1384329600"; d="scan'208,217";a="10739263" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw1-out.broadcom.com with ESMTP; 21 Jan 2014 15:27:19 -0800 Received: from SJEXCHCAS05.corp.ad.broadcom.com (10.16.203.12) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.1.438.0; Tue, 21 Jan 2014 15:08:35 -0800 Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS05.corp.ad.broadcom.com ([::1]) with mapi id 14.01.0438.000; Tue, 21 Jan 2014 15:08:34 -0800 From: Rajeev Manur To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] IPR check for draft-quinn-sfc-problem-statement Thread-Index: AQHPFtu2NSEh36Zfh0G0Wjova3ew6JqQHbcAgAAGmACAACuBAP//fUIg Date: Tue, 21 Jan 2014 23:08:34 +0000 Message-ID: <1E714095C88C9D408749A723A59CF6ED1C06E441@SJEXCHMB12.corp.ad.broadcom.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] Content-Type: multipart/alternative; boundary="_000_1E714095C88C9D408749A723A59CF6ED1C06E441SJEXCHMB12corpa_" MIME-Version: 1.0 Cc: Thomas Narten , "sfc@ietf.org" Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 23:08:38 -0000 --_000_1E714095C88C9D408749A723A59CF6ED1C06E441SJEXCHMB12corpa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Thanks! --Rajeev From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Surendra Kumar (smkuma= r) Sent: Tuesday, January 21, 2014 2:54 PM To: Jim Guichard (jguichar) Cc: Thomas Narten; sfc@ietf.org Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement +1 Surendra. From: "Ken Gray (kegray)" > Date: Tuesday, January 21, 2014 12:18 PM To: Thomas Nadeau >= , "Jim Guichard (jguichar)" > Cc: Thomas Narten >, "sfc@ietf.= org" > Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement Ditto From: Thomas Nadeau > Date: Tuesday, January 21, 2014 2:54 PM To: "Jim Guichard (jguichar)" > Cc: Thomas Narten >, "sfc@ietf.= org" > Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement None from my end. On Jan 21, 2014:2:05 PM, at 2:05 PM, Jim Guichard (jguichar) > wrote: This email serves as a poll for knowledge of any IPR that applies to draft = [1], to ensure that IPR has been disclosed in compliance with IETF IPR rule= s (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email whether or not you are aware of any relevant IPR. The draft will no= t be adopted until a response has been received from each author and major = contributor. If you are on the SFC WG mailing list but are not listed as an author or co= ntributor, then please explicitly respond only if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. Thank you, Jim & Thomas SFC chairs [1] http://tools.ietf.org/id/draft-quinn-sfc-problem-statement-02.txt _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_1E714095C88C9D408749A723A59CF6ED1C06E441SJEXCHMB12corpa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 <= /p>

+1<= /p>

 <= /p>

Thanks!=

--Rajeev

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Surendra Kumar (smkumar)
Sent: Tuesday, January 21, 2014 2:54 PM
To: Jim Guichard (jguichar)
Cc: Thomas Narten; sfc@ietf.org
Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement

 

+1

 

Surendra.=

 

From: "Ken Gray (kegray)" <kegray@cisco.com>
Date: Tuesday, January 21, 2014 12:18 PM
To: Thomas Nadeau <tna= deau@lucidvision.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>
Cc: Thomas Narten <narten@us= .ibm.com>, "sfc@ietf.org&qu= ot; <sfc@ietf.org>
Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement

 

Ditto

 

From: Thomas Nadeau <tnadeau@lucidvision.com>
Date: Tuesday, January 21, 2014 2:54 PM
To: "Jim Guichard (jguichar)" <jguichar@cisco.com>
Cc: Thomas Narten <narten@us= .ibm.com>, "sfc@ietf.org&qu= ot; <sfc@ietf.org>
Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement

 

 

None from my end.

 

On Jan 21, 2014:2:05 PM, at= 2:05 PM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:



This email serves as a poll= for knowledge of any IPR that applies to draft [1], to ensure that IPR has= been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). 

 

If you are listed as a docu= ment author or contributor please respond to this email whether or not you = are aware of any relevant IPR. The draft will not be adopted until a response has been received from each author and major contributor.=  

 

If you are on the SFC WG ma= iling list but are not listed as an author or contributor, then please expl= icitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. 

 

Thank you,

 

Jim & Thomas=

SFC chairs

 

___________________________= ____________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/= mailman/listinfo/sfc

 

--_000_1E714095C88C9D408749A723A59CF6ED1C06E441SJEXCHMB12corpa_-- From bmcconne@rackspace.com Tue Jan 21 15:11:30 2014 Return-Path: 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 ED4601A0232 for ; Tue, 21 Jan 2014 15:11:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.434 X-Spam-Level: X-Spam-Status: No, score=-7.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535] 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 OqOcNPsCevwJ for ; Tue, 21 Jan 2014 15:11:27 -0800 (PST) Received: from mx1.ord1.rackspace.com (mx1.ord1.rackspace.com [173.203.4.135]) by ietfa.amsl.com (Postfix) with ESMTP id DA38D1A01D7 for ; Tue, 21 Jan 2014 15:11:26 -0800 (PST) X-SBRS: None X-SenderGroup: RELAYLIST-US X-MailFlowPolicy: $RELAYED-US X-IronPort-AV: E=McAfee;i="5400,1158,7325"; a="272727659" X-IronPort-AV: E=Sophos;i="4.95,697,1384322400"; d="scan'208,217";a="272727659" Received: from ord1exh01.rackspace.corp ([10.12.120.25]) by mx1.ord1.rackspace.com with ESMTP/TLS/AES128-SHA; 21 Jan 2014 17:11:25 -0600 Received: from ORD1EXD04.RACKSPACE.CORP ([fe80::7ca9:7766:7f3a:1a45]) by ORD1EXH01.RACKSPACE.CORP ([::1]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 17:11:25 -0600 From: Brad McConnell To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] IPR check for draft-quinn-sfc-problem-statement Thread-Index: AQHPFtu2NSEh36Zfh0G0Wjova3ew6JqP/DAA//+Ae4CAACuAgIAAih0A//+b94A= Date: Tue, 21 Jan 2014 23:11:24 +0000 Message-ID: <8F9A3BC8F79F244DB44EC1569235CB4F79FCC918@ORD1EXD04.RACKSPACE.CORP> References: , <1E714095C88C9D408749A723A59CF6ED1C06E441@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <1E714095C88C9D408749A723A59CF6ED1C06E441@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.122.117] Content-Type: multipart/alternative; boundary="_000_8F9A3BC8F79F244DB44EC1569235CB4F79FCC918ORD1EXD04RACKSP_" MIME-Version: 1.0 Cc: Thomas Narten , "sfc@ietf.org" Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 23:11:30 -0000 --_000_8F9A3BC8F79F244DB44EC1569235CB4F79FCC918ORD1EXD04RACKSP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm not aware of any. Thank you, Brad McConnell ________________________________ From: sfc [sfc-bounces@ietf.org] on behalf of Rajeev Manur [rmanur@broadcom= .com] Sent: Tuesday, January 21, 2014 5:08 PM To: Jim Guichard (jguichar) Cc: Thomas Narten; sfc@ietf.org Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement +1 Thanks! --Rajeev From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Surendra Kumar (smkuma= r) Sent: Tuesday, January 21, 2014 2:54 PM To: Jim Guichard (jguichar) Cc: Thomas Narten; sfc@ietf.org Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement +1 Surendra. From: "Ken Gray (kegray)" > Date: Tuesday, January 21, 2014 12:18 PM To: Thomas Nadeau >= , "Jim Guichard (jguichar)" > Cc: Thomas Narten >, "sfc@ietf.= org" > Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement Ditto From: Thomas Nadeau > Date: Tuesday, January 21, 2014 2:54 PM To: "Jim Guichard (jguichar)" > Cc: Thomas Narten >, "sfc@ietf.= org" > Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement None from my end. On Jan 21, 2014:2:05 PM, at 2:05 PM, Jim Guichard (jguichar) > wrote: This email serves as a poll for knowledge of any IPR that applies to draft = [1], to ensure that IPR has been disclosed in compliance with IETF IPR rule= s (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email whether or not you are aware of any relevant IPR. The draft will no= t be adopted until a response has been received from each author and major = contributor. If you are on the SFC WG mailing list but are not listed as an author or co= ntributor, then please explicitly respond only if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. Thank you, Jim & Thomas SFC chairs [1] http://tools.ietf.org/id/draft-quinn-sfc-problem-statement-02.txt _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_8F9A3BC8F79F244DB44EC1569235CB4F79FCC918ORD1EXD04RACKSP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'm not aware of any.

Thank you,

Brad McConnell

From: sfc [sfc-bounces@ietf.org] on behal= f of Rajeev Manur [rmanur@broadcom.com]
Sent: Tuesday, January 21, 2014 5:08 PM
To: Jim Guichard (jguichar)
Cc: Thomas Narten; sfc@ietf.org
Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement

 

+1

 

Thanks!

--Rajeev

 

From: sfc [m= ailto:sfc-bounces@ietf.org] On Behalf Of Surendra Kumar (smkumar)
Sent: Tuesday, January 21, 2014 2:54 PM
To: Jim Guichard (jguichar)
Cc: Thomas Narten; sfc@ietf.org
Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement

 

+1

 

Surendra.

 

From: "Ken Gray (kegray)" <kegray@cisco.com>=
Date: Tuesday, January 21, 2014 12:18 PM
To: Thomas Nadeau <tnadeau@lucidvision.com>, "Jim Guichard (jguicha= r)" <jguich= ar@cisco.com>
Cc: Thomas Narten <narten@us.ibm.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement

 

Ditto

 

From: Thomas Nadeau <tnadeau@lucidvision.com> Date: Tuesday, January 21, 2014 2:54 PM
To: "Jim Guichard (jguichar)" <jguichar@cisco.com>
Cc: Thomas Narten <narten@us.ibm.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement

 

 

None from my end.

 

On Jan 21, 2014:2:05 PM, = at 2:05 PM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:



This email serves as a po= ll for knowledge of any IPR that applies to draft [1], to ensure that IPR h= as been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). 

 

If you are listed as a do= cument author or contributor please respond to this email whether or not yo= u are aware of any relevant IPR. The draft will not be adopted until a response has been received from each author and major contributor.=  

 

If you are on the SFC WG = mailing list but are not listed as an author or contributor, then please ex= plicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. 

 

Thank you,

 

Jim & Thomas

SFC chairs

 

_________________________= ______________________
sfc mailing list
sfc@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sfc

 

--_000_8F9A3BC8F79F244DB44EC1569235CB4F79FCC918ORD1EXD04RACKSP_-- From paulq@cisco.com Tue Jan 21 17:00:59 2014 Return-Path: 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 547601A0266 for ; Tue, 21 Jan 2014 17:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 04-jjlKeUckH for ; Tue, 21 Jan 2014 17:00:56 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 482811A024F for ; Tue, 21 Jan 2014 17:00:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19985; q=dns/txt; s=iport; t=1390352456; x=1391562056; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DZmPvAWV5tEOYPa1uJrCoz86gt7VRN/361xcn95dC6k=; b=d7p6SHs81x8s4uRAPxLIE7TYxAO/B3BLMktJpIEzAzjpmnEeWX9DPvpm OgimYgQuTQFN4tJf5GmLgicUjZySDXl2iApg9rODkIaVNu6Wt3kM3LPaE QVwF8H1F5sFfjKYGuPOfDF9x6So+uHDbiQu2dXeGi0NpJg8u2+0fcZ1B6 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao4HAAUY31KtJV2Z/2dsb2JhbABagkdEOFazHIhSgRQWdIIlAQEBBAEBAWsLEAIBCBEDAQEBIQcHJwsUCQgCBA4FiAUNwlgXjh0RAT4BDQQGAYMkgRQEiQ+PE4EykGaDLYFxOQ X-IronPort-AV: E=Sophos;i="4.95,697,1384300800"; d="scan'208,217";a="14519509" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP; 22 Jan 2014 01:00:55 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0M10tuX019257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jan 2014 01:00:55 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.19]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 19:00:55 -0600 From: "Paul Quinn (paulq)" To: Brad McConnell Thread-Topic: [sfc] IPR check for draft-quinn-sfc-problem-statement Thread-Index: AQHPFtu2NSEh36Zfh0G0Wjova3ew6JqP/DAA//+Ae4CAACuAgIAAih0A//+b94CAAINqgA== Date: Wed, 22 Jan 2014 01:00:54 +0000 Message-ID: <64BC961C-E325-40C4-BFFF-0F4F395FF68F@cisco.com> References: , <1E714095C88C9D408749A723A59CF6ED1C06E441@SJEXCHMB12.corp.ad.broadcom.com> <8F9A3BC8F79F244DB44EC1569235CB4F79FCC918@ORD1EXD04.RACKSPACE.CORP> In-Reply-To: <8F9A3BC8F79F244DB44EC1569235CB4F79FCC918@ORD1EXD04.RACKSPACE.CORP> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.229] Content-Type: multipart/alternative; boundary="_000_64BC961CE32540C4BFFF0F4F395FF68Fciscocom_" MIME-Version: 1.0 Cc: Thomas Narten , "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 01:00:59 -0000 --_000_64BC961CE32540C4BFFF0F4F395FF68Fciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Me neither. Paul On Jan 21, 2014, at 6:11 PM, Brad McConnell > wrote: I'm not aware of any. Thank you, Brad McConnell ________________________________ From: sfc [sfc-bounces@ietf.org] on behalf of = Rajeev Manur [rmanur@broadcom.com] Sent: Tuesday, January 21, 2014 5:08 PM To: Jim Guichard (jguichar) Cc: Thomas Narten; sfc@ietf.org Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement +1 Thanks! --Rajeev From: sfc [mailto:sfc-bounces@ietf.org] On Behalf = Of Surendra Kumar (smkumar) Sent: Tuesday, January 21, 2014 2:54 PM To: Jim Guichard (jguichar) Cc: Thomas Narten; sfc@ietf.org Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement +1 Surendra. From: "Ken Gray (kegray)" > Date: Tuesday, January 21, 2014 12:18 PM To: Thomas Nadeau >= , "Jim Guichard (jguichar)" > Cc: Thomas Narten >, "sfc@ietf.= org" > Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement Ditto From: Thomas Nadeau > Date: Tuesday, January 21, 2014 2:54 PM To: "Jim Guichard (jguichar)" > Cc: Thomas Narten >, "sfc@ietf.= org" > Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement None from my end. On Jan 21, 2014:2:05 PM, at 2:05 PM, Jim Guichard (jguichar) > wrote: This email serves as a poll for knowledge of any IPR that applies to draft = [1], to ensure that IPR has been disclosed in compliance with IETF IPR rule= s (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email whether or not you are aware of any relevant IPR. The draft will no= t be adopted until a response has been received from each author and major = contributor. If you are on the SFC WG mailing list but are not listed as an author or co= ntributor, then please explicitly respond only if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. Thank you, Jim & Thomas SFC chairs [1] http://tools.ietf.org/id/draft-quinn-sfc-problem-statement-02.txt _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_64BC961CE32540C4BFFF0F4F395FF68Fciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable Me neither.

Paul


On Jan 21, 2014, at 6:11 PM, Brad McConnell <bmcconne@rackspace.com> wrote:

I'm n= ot aware of any.

Thank you,

Brad McConnell

From: sf= c [sfc-bounces@ietf.org] on behalf of Rajeev Manur [rmanur@broadcom.com]
Sent: Tuesday, Jan= uary 21, 2014 5:08 PM
To: Jim Guichard (= jguichar)
Cc: Thomas Narten;=  sfc@ietf.org<= /a>
Subject: Re: [sfc]= IPR check for draft-quinn-sfc-problem-statement

 

+1

 

Thanks!
--Rajeev

 

From:=  sfc [mailto:sfc-bounces@ietf.org] = On Behalf Of Surendra K= umar (smkumar)
Sent: Tuesday, Jan= uary 21, 2014 2:54 PM
To: Jim Guichard (= jguichar)
Cc: Thomas Narten;=  sfc@ietf.org<= /a>
Subject: Re: [sfc]= IPR check for draft-quinn-sfc-problem-statement

 

+= 1

 = ;

Suren= dra.

 = ;

From= : "Ken Gray (ke= gray)" <kegray@cisco.com> Date: Tuesday, Jan= uary 21, 2014 12:18 PM
To: Thomas Nadeau = <tnadeau@lucidvision.com>= , "Jim Guichard (jguichar)" < Thomas Narten = <narten@us.ibm.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc]= IPR check for draft-quinn-sfc-problem-statement

 = ;

Ditto=

 = ;

From= : Thomas Nadeau <= tnadeau@lucidvision.com>
Date: Tuesday, Jan= uary 21, 2014 2:54 PM
To: "Jim Guic= hard (jguichar)" <jguichar@cisco= .com>
Cc: Thomas Narten = <narten@us.ibm.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc]= IPR check for draft-quinn-sfc-problem-statement

 = ;

 = ;

None = from my end.

 = ;

On Ja= n 21, 2014:2:05 PM, at 2:05 PM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:


This = email serves as a poll for knowledge of any IPR that applies to draft [1], = to ensure that IPR has been disclosed in compliance with IETF IPR rules (se= e RFCs 3979, 4879, 3669 and 5378 for more details). 

 = ;

If yo= u are listed as a document author or contributor please respond to this ema= il whether or not you are aware of any relevant IPR. The draft will not be = adopted until a response has been received from each author and major contributor. 

 = ;

If yo= u are on the SFC WG mailing list but are not listed as an author or contrib= utor, then please explicitly respond only if you are aware of any IPR that = has not yet been disclosed in conformance with IETF rules. 

 = ;

Thank= you,

 = ;

Jim &= amp; Thomas
SFC c= hairs

 = ;

_____= __________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mai= lman/listinfo/sfc

 = ;

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc<= /a>

--_000_64BC961CE32540C4BFFF0F4F395FF68Fciscocom_-- From nyadav@insiemenetworks.com Tue Jan 21 17:51:55 2014 Return-Path: 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 6C4CF1A027D for ; Tue, 21 Jan 2014 17:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 iZwtfzn4cECV for ; Tue, 21 Jan 2014 17:51:53 -0800 (PST) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by ietfa.amsl.com (Postfix) with ESMTP id BC5E51A01B8 for ; Tue, 21 Jan 2014 17:51:52 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id w62so8688846wes.38 for ; Tue, 21 Jan 2014 17:51:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MjWxTsXPkjatdharFxNd0eU+GqQayqBVIVY96shAn0M=; b=WspfhC+xzDqvuJYDjwpNHBwllpKqQ6KyYnqzXruG/BbtfCxIWCYYu8KmKornPPsbfT MsibKOD50WHvZBTyhLkf2OJEwhuaqpjsB/3oWvuFtKw6OBi7RpTIrIAQI/caulG4Xjgv jlaeryyEtDWTmwrFdhTUrUBLYtseq3nohuo6gtIgC1j2GhOU70XEv96XDQNAqnjDE3HS Dq/Rn0bBun2NLZEl4OUI9pTtGSVlByoebic2yv3pIyFtWWSuOsdCdNRLuy2EVDa9J8yS +9hwa0s1cQ+jbBAJTAXQgBlIETZR1tYOkQhoLp3WaLDZHj5i0wefZ0ga4GVH5KzUGRh2 L1Mw== X-Gm-Message-State: ALoCoQnQ0LrgTu0u7F5Bf18Aqa4GN/B8m/62G9ukaqTfpzM+dSRnDGTwCoO5n/Q1XZ2quWCbrzTo MIME-Version: 1.0 X-Received: by 10.181.11.133 with SMTP id ei5mr560497wid.2.1390355511976; Tue, 21 Jan 2014 17:51:51 -0800 (PST) Received: by 10.194.15.106 with HTTP; Tue, 21 Jan 2014 17:51:51 -0800 (PST) In-Reply-To: <64BC961C-E325-40C4-BFFF-0F4F395FF68F@cisco.com> References: <1E714095C88C9D408749A723A59CF6ED1C06E441@SJEXCHMB12.corp.ad.broadcom.com> <8F9A3BC8F79F244DB44EC1569235CB4F79FCC918@ORD1EXD04.RACKSPACE.CORP> <64BC961C-E325-40C4-BFFF-0F4F395FF68F@cisco.com> Date: Tue, 21 Jan 2014 17:51:51 -0800 Message-ID: From: Navindra Yadav To: "Paul Quinn (paulq)" Content-Type: multipart/alternative; boundary=f46d043bdec667392104f0855e47 Cc: Thomas Narten , "Jim Guichard \(jguichar\)" , "sfc@ietf.org" , Brad McConnell Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 01:51:55 -0000 --f46d043bdec667392104f0855e47 Content-Type: text/plain; charset=ISO-8859-1 ditto. cheers Navindra On Tue, Jan 21, 2014 at 5:00 PM, Paul Quinn (paulq) wrote: > Me neither. > > Paul > > > On Jan 21, 2014, at 6:11 PM, Brad McConnell > wrote: > > I'm not aware of any. > > Thank you, > > Brad McConnell > > ------------------------------ > *From:* sfc [sfc-bounces@ietf.org] on behalf of Rajeev Manur [ > rmanur@broadcom.com] > *Sent:* Tuesday, January 21, 2014 5:08 PM > *To:* Jim Guichard (jguichar) > *Cc:* Thomas Narten; sfc@ietf.org > *Subject:* Re: [sfc] IPR check for draft-quinn-sfc-problem-statement > > > +1 > > > Thanks! > --Rajeev > > > *From:* sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Surendra Kumar > (smkumar) > *Sent:* Tuesday, January 21, 2014 2:54 PM > *To:* Jim Guichard (jguichar) > *Cc:* Thomas Narten; sfc@ietf.org > *Subject:* Re: [sfc] IPR check for draft-quinn-sfc-problem-statement > > > +1 > > > Surendra. > > > *From: *"Ken Gray (kegray)" > *Date: *Tuesday, January 21, 2014 12:18 PM > *To: *Thomas Nadeau , "Jim Guichard (jguichar)" < > jguichar@cisco.com> > *Cc: *Thomas Narten , "sfc@ietf.org" > *Subject: *Re: [sfc] IPR check for draft-quinn-sfc-problem-statement > > > Ditto > > > *From: *Thomas Nadeau > *Date: *Tuesday, January 21, 2014 2:54 PM > *To: *"Jim Guichard (jguichar)" > *Cc: *Thomas Narten , "sfc@ietf.org" > *Subject: *Re: [sfc] IPR check for draft-quinn-sfc-problem-statement > > > > > None from my end. > > > On Jan 21, 2014:2:05 PM, at 2:05 PM, Jim Guichard (jguichar) < > jguichar@cisco.com> wrote: > > > This email serves as a poll for knowledge of any IPR that applies to > draft [1], to ensure that IPR has been disclosed in compliance with IETF > IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). > > > If you are listed as a document author or contributor please respond to > this email whether or not you are aware of any relevant IPR. The draft will > not be adopted until a response has been received from each author and > major contributor. > > > If you are on the SFC WG mailing list but are not listed as an author > or contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > > Thank you, > > > Jim & Thomas > SFC chairs > > > [1] http://tools.ietf.org/id/draft-quinn-sfc-problem-statement-02.txt > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > --f46d043bdec667392104f0855e47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
ditto.
cheers
Navindra


On Tue, Jan 21, 2014 at 5:00 = PM, Paul Quinn (paulq) <paulq@cisco.com> wrote:
Me neither.

Paul


On Jan 21, 2014, at 6:11 PM, Brad McConnell <bmcconne@rackspace.com> wrote:=

I'm not = aware of any.

Thank you,

Brad McConnell

From:=A0sfc [sfc-bounces@ietf.org] on behalf of Rajeev Manur [rmanur@broadcom.com= ]
Sent:=A0Tuesday, January 21, 2014 5:08 PM
To:=A0Jim Guichard (jguichar)
Cc:=A0Thomas Narten;=A0sfc@ietf.org
Subject:=A0Re: [sfc] IPR check for draft-quinn-sfc-prob= lem-statement

=A0

+1

=A0

Thanks!
--Rajeev

=A0

From:=A0= sfc [mailto:sfc-bounces@ietf.org]=A0On Behalf Of=A0Surendra Kumar (smkumar)
Sent:=A0Tuesday, January 21, 2014 2:54 PM
To:=A0Jim Guichard (jguichar)
Cc:=A0Thomas Narten;=A0sfc@ietf.org
Subject:=A0Re: [sfc] IPR check for draft-quinn-sfc-prob= lem-statement

=A0

+1

=A0<= /p>

Surendra.

=A0<= /p>

From:=A0"Ken Gray (kegray)" <kegr= ay@cisco.com>
Date:=A0Tuesday, January 21, 2014 12:18 PM
To:=A0Thomas Nadeau <tnadeau@lucidvision.com>, "Jim Guichard (jguichar)" &l= t;jguichar@cisco.com>
Cc:=A0Thomas Narten <na= rten@us.ibm.com>, "sfc@ietf.org&quo= t; <sfc@ietf.org>
Subject:=A0Re: [sfc] IPR check for draft-quinn-sfc-prob= lem-statement

=A0<= /p>

Ditto

=A0<= /p>

From:=A0Thomas Nadeau <tnadeau@lucid= vision.com>
Date:=A0Tuesday, January 21, 2014 2:54 PM
To:=A0"Jim Guichard (jguichar)" <jguichar@cisco.com>
Cc:=A0Thomas Narten <na= rten@us.ibm.com>, "sfc@ietf.org&quo= t; <sfc@ietf.org>
Subject:=A0Re: [sfc] IPR check for draft-quinn-sfc-prob= lem-statement

=A0<= /p>

=A0<= /p>

None from m= y end.

=A0<= /p>

On Jan 21, = 2014:2:05 PM, at 2:05 PM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:


This email = serves as a poll for knowledge of any IPR that applies to draft [1], to ens= ure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs= 3979, 4879, 3669 and 5378 for more details).=A0

=A0<= /p>

If you are = listed as a document author or contributor please respond to this email whe= ther or not you are aware of any relevant IPR. The draft will not be adopte= d until a response has been received from each author and major contributor.=A0

=A0<= /p>

If you are = on the SFC WG mailing list but are not listed as an author or contributor, = then please explicitly respond only if you are aware of any IPR that has no= t yet been disclosed in conformance with IETF rules.=A0

=A0<= /p>

Thank you,<= /span>

=A0<= /p>

Jim & T= homas
SFC chairs<= /span>

=A0<= /p>

___________= ____________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/= listinfo/sfc

=A0<= /p>

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


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


--f46d043bdec667392104f0855e47-- From michsmit@cisco.com Tue Jan 21 17:10:11 2014 Return-Path: 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 5747C1A0343 for ; Tue, 21 Jan 2014 17:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 9n7yo-henYQE for ; Tue, 21 Jan 2014 17:10:08 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9D37F1A0229 for ; Tue, 21 Jan 2014 17:10:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21989; q=dns/txt; s=iport; t=1390353007; x=1391562607; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KGBp3AATDWA4Ajm22rssoOHcHUhcurBlv8KFAb8J50g=; b=BUnxLPw1Zk78d9wj9EfSrqhHM7Ay0V5Uox/8QL7YvmsR4XjinLS/4WJW puRKMwZieIBNFuAbIMhhVcO3A7nnla4tNiScOo/iY1CrI//yZLLGO8qE2 w2s5iMHsiqou2wGx2j55Zw59eqZFdGcp5bAdpM87Mj4PHcFODBTnSVwhS k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao4HAAoZ31KtJXG9/2dsb2JhbABagkdEOFazHIhSgRQWdIIlAQEBBAEBAWsLEAIBCBEDAQEBIQcHJwsUCQgCBAENBYgFDcJYF44dEQE+AQ0EBgGEOASYIoEykGaDLYFxOQ X-IronPort-AV: E=Sophos;i="4.95,697,1384300800"; d="scan'208,217";a="14517899" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-4.cisco.com with ESMTP; 22 Jan 2014 01:10:06 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0M1A6ku004570 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jan 2014 01:10:06 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.197]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 19:10:06 -0600 From: "Michael Smith (michsmit)" To: "Paul Quinn (paulq)" , Brad McConnell Thread-Topic: [sfc] IPR check for draft-quinn-sfc-problem-statement Thread-Index: AQHPFtu2NSEh36Zfh0G0Wjova3ew6JqP/DAA//+Ae4CAACuAgIAAih0A//+b94CAAINqgP//fHUA Date: Wed, 22 Jan 2014 01:10:05 +0000 Message-ID: References: <1E714095C88C9D408749A723A59CF6ED1C06E441@SJEXCHMB12.corp.ad.broadcom.com> <8F9A3BC8F79F244DB44EC1569235CB4F79FCC918@ORD1EXD04.RACKSPACE.CORP> <64BC961C-E325-40C4-BFFF-0F4F395FF68F@cisco.com> In-Reply-To: <64BC961C-E325-40C4-BFFF-0F4F395FF68F@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.156.2.198] Content-Type: multipart/alternative; boundary="_000_CF045A5131AAmichsmitciscocom_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 22 Jan 2014 03:44:56 -0800 Cc: Thomas Narten , "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 01:10:11 -0000 --_000_CF045A5131AAmichsmitciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not aware of any either. Michael From: "Paul Quinn (paulq)" > Date: Tuesday, January 21, 2014 5:00 PM To: Brad McConnell > Cc: Thomas Narten >, "Jim Guich= ard (jguichar)" >, "sfc@ietf.= org" > Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement Me neither. Paul On Jan 21, 2014, at 6:11 PM, Brad McConnell > wrote: I'm not aware of any. Thank you, Brad McConnell ________________________________ From: sfc [sfc-bounces@ietf.org] on behalf of = Rajeev Manur [rmanur@broadcom.com] Sent: Tuesday, January 21, 2014 5:08 PM To: Jim Guichard (jguichar) Cc: Thomas Narten; sfc@ietf.org Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement +1 Thanks! --Rajeev From: sfc [mailto:sfc-bounces@ietf.org] On Behalf = Of Surendra Kumar (smkumar) Sent: Tuesday, January 21, 2014 2:54 PM To: Jim Guichard (jguichar) Cc: Thomas Narten; sfc@ietf.org Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement +1 Surendra. From: "Ken Gray (kegray)" > Date: Tuesday, January 21, 2014 12:18 PM To: Thomas Nadeau >= , "Jim Guichard (jguichar)" > Cc: Thomas Narten >, "sfc@ietf.= org" > Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement Ditto From: Thomas Nadeau > Date: Tuesday, January 21, 2014 2:54 PM To: "Jim Guichard (jguichar)" > Cc: Thomas Narten >, "sfc@ietf.= org" > Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement None from my end. On Jan 21, 2014:2:05 PM, at 2:05 PM, Jim Guichard (jguichar) > wrote: This email serves as a poll for knowledge of any IPR that applies to draft = [1], to ensure that IPR has been disclosed in compliance with IETF IPR rule= s (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email whether or not you are aware of any relevant IPR. The draft will no= t be adopted until a response has been received from each author and major = contributor. If you are on the SFC WG mailing list but are not listed as an author or co= ntributor, then please explicitly respond only if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. Thank you, Jim & Thomas SFC chairs [1] http://tools.ietf.org/id/draft-quinn-sfc-problem-statement-02.txt _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_CF045A5131AAmichsmitciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <2A3311206950424C91C05C339BA1702B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
I'm not aware of any either.
Michael

From: "Paul Quinn (paulq)"= ; <paulq@cisco.com>
Date: Tuesday, January 21, 2014 5:0= 0 PM
To: Brad McConnell <bmcconne@rackspace.com>
Cc: Thomas Narten <narten@us.ibm.com>, "Jim Guichard (jgui= char)" <jguichar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] IPR check for dr= aft-quinn-sfc-problem-statement

Me neither.

Paul


On Jan 21, 2014, at 6:11 PM, Brad McConnell <bmcconne@rackspace.com> wrote:

I'm n= ot aware of any.

Thank you,

Brad McConnell

From: sf= c [sfc-bounces@ietf.org] on behalf of Rajeev Manur [rmanur@broadcom.com]
Sent: Tuesday, Jan= uary 21, 2014 5:08 PM
To: Jim Guichard (= jguichar)
Cc: Thomas Narten;=  sfc@ietf.org<= /a>
Subject: Re: [sfc]= IPR check for draft-quinn-sfc-problem-statement

 

+1

 

Thanks!
--Rajeev

 

From:=  sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Surendra K= umar (smkumar)
Sent: Tuesday, Jan= uary 21, 2014 2:54 PM
To: Jim Guichard (= jguichar)
Cc: Thomas Narten;=  sfc@ietf.org<= /a>
Subject: Re: [sfc]= IPR check for draft-quinn-sfc-problem-statement

 

+= 1

 = ;

Suren= dra.

 = ;

From= : "Ken Gray (ke= gray)" <kegray@cisco.com> Date: Tuesday, Jan= uary 21, 2014 12:18 PM
To: Thomas Nadeau = <tnadeau@lucidvision.com>= , "Jim Guichard (jguichar)" < Thomas Narten = <narten@us.ibm.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc]= IPR check for draft-quinn-sfc-problem-statement

 = ;

Ditto=

 = ;

From= : Thomas Nadeau <= tnadeau@lucidvision.com>
Date: Tuesday, Jan= uary 21, 2014 2:54 PM
To: "Jim Guic= hard (jguichar)" <jguichar@cisco= .com>
Cc: Thomas Narten = <narten@us.ibm.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc]= IPR check for draft-quinn-sfc-problem-statement

 = ;

 = ;

None = from my end.

 = ;

On Ja= n 21, 2014:2:05 PM, at 2:05 PM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:


This = email serves as a poll for knowledge of any IPR that applies to draft [1], = to ensure that IPR has been disclosed in compliance with IETF IPR rules (se= e RFCs 3979, 4879, 3669 and 5378 for more details). 

 = ;

If yo= u are listed as a document author or contributor please respond to this ema= il whether or not you are aware of any relevant IPR. The draft will not be = adopted until a response has been received from each author and major contributor. 

 = ;

If yo= u are on the SFC WG mailing list but are not listed as an author or contrib= utor, then please explicitly respond only if you are aware of any IPR that = has not yet been disclosed in conformance with IETF rules. 

 = ;

Thank= you,

 = ;

Jim &= amp; Thomas
SFC c= hairs

 = ;

_____= __________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mai= lman/listinfo/sfc

 = ;

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc<= /a>

 --_000_CF045A5131AAmichsmitciscocom_-- From cfrederick@sandvine.com Wed Jan 22 08:07:31 2014 Return-Path: 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 B38E91A035D for ; Wed, 22 Jan 2014 08:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.898 X-Spam-Level: X-Spam-Status: No, score=0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no 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 O7DldwuKdwfT for ; Wed, 22 Jan 2014 08:07:29 -0800 (PST) Received: from mail1.sandvine.com (unknown [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 570641A03FE for ; Wed, 22 Jan 2014 08:07:29 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%16]) with mapi id 14.01.0339.001; Wed, 22 Jan 2014 11:07:28 -0500 From: Chris Frederick To: "Michael Smith (michsmit)" , "Paul Quinn (paulq)" , Brad McConnell Thread-Topic: [sfc] IPR check for draft-quinn-sfc-problem-statement Thread-Index: AQHPFtu2O3ornJShr0OlqV+EtD9b+pqP/DAA//+Ae4CAACuAgIAAeVkAgAAAywCAAB6YAIAAApGAgACjNEA= Date: Wed, 22 Jan 2014 16:07:27 +0000 Message-ID: <802F0FD88084CC4D82A0663874219D1A1887DF44@wtl-exchp-2.sandvine.com> References: <1E714095C88C9D408749A723A59CF6ED1C06E441@SJEXCHMB12.corp.ad.broadcom.com> <8F9A3BC8F79F244DB44EC1569235CB4F79FCC918@ORD1EXD04.RACKSPACE.CORP> <64BC961C-E325-40C4-BFFF-0F4F395FF68F@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.194.252] Content-Type: multipart/alternative; boundary="_000_802F0FD88084CC4D82A0663874219D1A1887DF44wtlexchp2sandvi_" MIME-Version: 1.0 Cc: Thomas Narten , "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 16:07:31 -0000 --_000_802F0FD88084CC4D82A0663874219D1A1887DF44wtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Sandvine has intellectual property related to the granular steering of traf= fic flows, specifically where the session has been established. This techni= que enables steering on the basis of application, content, etc, vs. just th= e port that would be seen in the initial SYN packet. This is outlined here: http://www.google.com/patents/WO2004086714A1?cl=3Den This is not related to SFC specifically but I bring it to your attention as= this technique can be used to select flows that would then be redirected t= hrough a service function chain or path; Sandvine uses this mechanism in ou= r own SFC implementation for example. Best regards, Chris Frederick Director, Technology Partnerships cfrederick@sandvine.com From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Michael Smith (michsmi= t) Sent: Tuesday, January 21, 2014 8:10 PM To: Paul Quinn (paulq); Brad McConnell Cc: Thomas Narten; Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement I'm not aware of any either. Michael From: "Paul Quinn (paulq)" > Date: Tuesday, January 21, 2014 5:00 PM To: Brad McConnell > Cc: Thomas Narten >, "Jim Guich= ard (jguichar)" >, "sfc@ietf.= org" > Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement Me neither. Paul On Jan 21, 2014, at 6:11 PM, Brad McConnell > wrote: I'm not aware of any. Thank you, Brad McConnell ________________________________ From: sfc [sfc-bounces@ietf.org] on behalf of = Rajeev Manur [rmanur@broadcom.com] Sent: Tuesday, January 21, 2014 5:08 PM To: Jim Guichard (jguichar) Cc: Thomas Narten; sfc@ietf.org Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement +1 Thanks! --Rajeev From: sfc [mailto:sfc-bounces@ietf.org] On Behalf = Of Surendra Kumar (smkumar) Sent: Tuesday, January 21, 2014 2:54 PM To: Jim Guichard (jguichar) Cc: Thomas Narten; sfc@ietf.org Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement +1 Surendra. From: "Ken Gray (kegray)" > Date: Tuesday, January 21, 2014 12:18 PM To: Thomas Nadeau >= , "Jim Guichard (jguichar)" > Cc: Thomas Narten >, "sfc@ietf.= org" > Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement Ditto From: Thomas Nadeau > Date: Tuesday, January 21, 2014 2:54 PM To: "Jim Guichard (jguichar)" > Cc: Thomas Narten >, "sfc@ietf.= org" > Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement None from my end. On Jan 21, 2014:2:05 PM, at 2:05 PM, Jim Guichard (jguichar) > wrote: This email serves as a poll for knowledge of any IPR that applies to draft = [1], to ensure that IPR has been disclosed in compliance with IETF IPR rule= s (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email whether or not you are aware of any relevant IPR. The draft will no= t be adopted until a response has been received from each author and major = contributor. If you are on the SFC WG mailing list but are not listed as an author or co= ntributor, then please explicitly respond only if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. Thank you, Jim & Thomas SFC chairs [1] http://tools.ietf.org/id/draft-quinn-sfc-problem-statement-02.txt _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_802F0FD88084CC4D82A0663874219D1A1887DF44wtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,<= /p>

Sandvine has intellectual= property related to the granular steering of traffic flows, specifically w= here the session has been established. This technique enables steering on the basis of application, content, etc, vs. just the port that= would be seen in the initial SYN packet.

This is outlined here: http://www= .google.com/patents/WO2004086714A1?cl=3Den

This is not related to SF= C specifically but I bring it to your attention as this technique can be us= ed to select flows that would then be redirected through a service function chain or path; Sandvine uses this mechanism in our own = SFC implementation for example. Best regards,

 <= /p>

Chris Frederick Director, Technology Partnerships
cfrederick@sandvine.com

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Michael Smith (michsmit)
Sent: Tuesday, January 21, 2014 8:10 PM
To: Paul Quinn (paulq); Brad McConnell
Cc: Thomas Narten; Jim Guichard (jguichar); sfc@ietf.org
Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement

 

I'm not aware of any either= .

Michael

 

From: "Paul Quinn (paulq)" <paulq@cisco.com>
Date: Tuesday, January 21, 2014 5:00 PM
To: Brad McConnell <bmc= conne@rackspace.com>
Cc: Thomas Narten <narten@us= .ibm.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>, "sfc@ietf.org" <sfc@= ietf.org>
Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement

 

Me neither.

 

Paul

 

 

On Jan 21, 2014, at 6:11 PM= , Brad McConnell <bmcconne@rac= kspace.com> wrote:



I'm not aware of any.

Thank you,

Brad McConnell

From: sfc [sfc-= bounces@ietf.org] on behalf of Rajeev Manur [rmanur@broadcom.com= ]
Sent: Tuesday, Jan= uary 21, 2014 5:08 PM
To: Jim Guichard (= jguichar)
Cc: Thomas Narten;=  sfc@ietf.org
Subject: Re: [sfc]= IPR check for draft-quinn-sfc-problem-statement

 

+1

 

Thanks!

--Rajeev

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Surendra Kumar (smkumar)
Sent: Tuesday, Jan= uary 21, 2014 2:54 PM
To: Jim Guichard (= jguichar)
Cc: Thomas Narten;=  sfc@ietf.org
Subject: Re: [sfc]= IPR check for draft-quinn-sfc-problem-statement

 =

+1

 

Surendra.

 

From: "K= en Gray (kegray)" <kegray@cisco.com>
Date: Tuesday, Jan= uary 21, 2014 12:18 PM
To: Thomas Nadeau = <tnadeau@lucidvision.com>, "Jim Guicha= rd (jguichar)" <jguichar@cisco.com>
Cc: Thomas Narten = <narten@us.ibm.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc]= IPR check for draft-quinn-sfc-problem-statement

 

Ditto

 

From: Thomas = Nadeau <tnadeau@lucidvision.com>
Date: Tuesday, Jan= uary 21, 2014 2:54 PM
To: "Jim Guic= hard (jguichar)" <jguichar@cisco.com>
Cc: Thomas Narten = <narten@us.ibm.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc]= IPR check for draft-quinn-sfc-problem-statement

 

 

None from my end.

 

On Jan 21, 2014:2:05 PM, at= 2:05 PM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:

 

This email serves as a poll= for knowledge of any IPR that applies to draft [1], to ensure that IPR has= been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). 

 

If you are listed as a docu= ment author or contributor please respond to this email whether or not you = are aware of any relevant IPR. The draft will not be adopted until a response has been received from each author and major contributor.=  

 

If you are on the SFC WG ma= iling list but are not listed as an author or contributor, then please expl= icitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. 

 

Thank you,

 

Jim & Thomas

SFC chairs

 

___________________________= ____________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc<= /a>

 

_________________________= ______________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

 

--_000_802F0FD88084CC4D82A0663874219D1A1887DF44wtlexchp2sandvi_-- From Cathy.H.Zhang@huawei.com Wed Jan 22 12:12:52 2014 Return-Path: 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 2AF101A045D for ; Wed, 22 Jan 2014 12:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 lzNQqvso51sO for ; Wed, 22 Jan 2014 12:12:49 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBD01A0445 for ; Wed, 22 Jan 2014 12:12:48 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAI03795; Wed, 22 Jan 2014 20:12:46 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Jan 2014 20:11:41 +0000 Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Jan 2014 20:12:44 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML703-CHM.china.huawei.com ([169.254.5.128]) with mapi id 14.03.0158.001; Wed, 22 Jan 2014 12:12:27 -0800 From: Cathy Zhang To: "Jim Guichard (jguichar)" , "sfc@ietf.org" , Cathy Zhang Thread-Topic: WG adoption of draft-quinn-sfc-problem-statement-02 Thread-Index: AQHPFtz0BBXmRpg9rk2thNSnYBnFRZqPsP9w Date: Wed, 22 Jan 2014 20:12:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.145.86] Content-Type: multipart/alternative; boundary="_000_A2C96F6779E6A041BC7023CC207FC99418F0A191SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 20:12:52 -0000 --_000_A2C96F6779E6A041BC7023CC207FC99418F0A191SJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, I have the following questions/comments: 1. Definition of Service Function It mentions that "Multiple instances of the Service Function can be enabled= in the same administrative domain". There is also the case that multiple i= nstances of the Service Function can be instantiated on the same Service No= de. For example on a FW appliance, we can instantiate multiple FW service instances with each FW service instance having its own = filtering rules. Could we add this into the Definition? 2. Service Overlay AFAIK, there is a proposal for a new overlay mechanism. Shall we also explo= re and leverage existing overlay mechanism? I am thinking that we might als= o want to take current prevailing overlay mechanism into our consideration for service function ch= aining, such as VXLAN overlay which is supported in many virtual/physical s= witches and which has reserved fields that can be used to carry chain-ID and other meta= data. 3. "Enterprise Data Center Service Chaining" section is TBD. Is there = a plan to compete this section? Thanks, Cathy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Tuesday, January 21, 2014 11:14 AM To: sfc@ietf.org Subject: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 Thomas and I would like to remind you of the ongoing WG call for adoption o= f draft-quinn-sfc-problem-statement-02. We have received numerous positive = responses to our original email and plan to formally close out the call for= adoption this coming Friday (1/24/14). If folks have any additional commen= ts or concerns please voice them before this Friday. Jim & Thomas SFC chairs. --_000_A2C96F6779E6A041BC7023CC207FC99418F0A191SJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim,

 

I have the following q= uestions/comments:

1.&n= bsp;     Definition of = Service Function

It mentions tha= t “Multiple instances of the Service Function can be enabled in the s= ame administrative domain”. There is also the case that multiple inst= ances of the Service Function can be instantiated on the same Service Node. For example on a FW appliance, we can instantiat= e

multiple FW ser= vice instances with each FW service instance having its own filtering rules= . Could we add this into the Definition?

2.&n= bsp;     Service Overla= y

AFAIK, there is= a proposal for a new overlay mechanism. Shall we also explore and leverage= existing overlay mechanism? I am thinking that we might also want to take = current

prevailing over= lay mechanism into our consideration for service function chaining, such as= VXLAN overlay which is supported in many virtual/physical switches and

which has reser= ved fields that can be used to carry chain-ID and other metadata. 

 

3.&n= bsp;     “Enterpr= ise Data Center Service Chaining” section is TBD. Is there a plan to = compete this section?

 

Thanks,

Cathy

 <= /p>

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, January 21, 2014 11:14 AM
To: sfc@ietf.org
Subject: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

 

Thomas and I would like to = remind you of the ongoing WG call for adoption of draft-quinn-sfc-problem-s= tatement-02. We have received numerous positive responses to our original email and plan to formally close out the call for adoption= this coming Friday (1/24/14). If folks have any additional comments or con= cerns please voice them before this Friday.

 

Jim & Thomas=

SFC chairs. 

--_000_A2C96F6779E6A041BC7023CC207FC99418F0A191SJCEML701CHMchi_-- From cfrederick@sandvine.com Wed Jan 22 12:49:24 2014 Return-Path: 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 2A8131A048C for ; Wed, 22 Jan 2014 12:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] 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 OThD9n6Qx-RY for ; Wed, 22 Jan 2014 12:49:21 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7281A047E for ; Wed, 22 Jan 2014 12:49:20 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%20]) with mapi id 14.01.0339.001; Wed, 22 Jan 2014 15:49:19 -0500 From: Chris Frederick To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: WG adoption of draft-quinn-sfc-problem-statement-02 Thread-Index: AQHPFtz0BBXmRpg9rk2thNSnYBnFRZqPsP9wgAGCVlA= Date: Wed, 22 Jan 2014 20:49:19 +0000 Message-ID: <802F0FD88084CC4D82A0663874219D1A1887E1C4@wtl-exchp-2.sandvine.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.194.252] Content-Type: multipart/alternative; boundary="_000_802F0FD88084CC4D82A0663874219D1A1887E1C4wtlexchp2sandvi_" MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 20:49:24 -0000 --_000_802F0FD88084CC4D82A0663874219D1A1887E1C4wtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, Thomas, I think the draft looks good. My comment is that perhaps it doesn't consider all the challenges related t= o network asymmetry (i.e. where a flow's packets traverse different links). I've read subsection 12 of the Problem Space ("Symmetric Traffic Flows") an= d agree with the issue, as stated. However, we (Sandvine) take a somewhat different view of the challenges aro= und symmetry. In our experience (residential broadband service networks), s= ervice chains are always bidirectional; the reason is that most application= s manipulate the session state of the flow, which is impossible to do in on= ly one direction. We believe the primary challenge with symmetry - and one of the most import= ant issues with service chaining in general - is the graceful handling of n= etwork asymmetry, to facilitate stateful inspection of bidirectional flows. A redirected flow that needs to be chained (say, a Netflix flow for example= ) will often switch providers (+ network links) during its lifespan and thi= s can present issues for SFC; there are different ways to address this chal= lenge but they're not all equivalent in terms of efficacy and suitability. = Best regards, Chris From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Tuesday, January 21, 2014 11:14 AM To: sfc@ietf.org Subject: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 Thomas and I would like to remind you of the ongoing WG call for adoption o= f draft-quinn-sfc-problem-statement-02. We have received numerous positive = responses to our original email and plan to formally close out the call for= adoption this coming Friday (1/24/14). If folks have any additional commen= ts or concerns please voice them before this Friday. Jim & Thomas SFC chairs. --_000_802F0FD88084CC4D82A0663874219D1A1887E1C4wtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim, Thomas,

I think the draft looks g= ood.

My comment is that perhap= s it doesn’t consider all the challenges related to network asymmetry= (i.e. where a flow’s packets traverse different links).

I’ve read subsection 12 of the Proble=
m Space (“Symmetric Traffic Flow=
s”) and agree with the issue, as stated. 
However, we (Sandvine) take a somewhat diff=
erent view of the challenges around symmetry. In our experience (residentia=
l broadband service networks), service chains are always bidirectional; the=
 reason is that most applications manipulate the session state of the flow,=
 which is impossible to do in only one direction.

We believe the primary ch= allenge with symmetry – and one of the most important issues with ser= vice chaining in general – is the graceful handling of network asymmetry, to facilitate stateful inspection of bidirectional flows. =

A redirected flow that ne= eds to be chained (say, a Netflix flow for example) will often switch provi= ders (+ network links) during its lifespan and this can present issues for SFC; there are different ways to address this challenge= but they’re not all equivalent in terms of efficacy and suitability.= Best regards,

Chris

 <= /p>

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, January 21, 2014 11:14 AM
To: sfc@ietf.org
Subject: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

 

Thomas and I would like to = remind you of the ongoing WG call for adoption of draft-quinn-sfc-problem-s= tatement-02. We have received numerous positive responses to our original email and plan to formally close out the call for adoption= this coming Friday (1/24/14). If folks have any additional comments or con= cerns please voice them before this Friday.

 

Jim & Thomas=

SFC chairs. 

--_000_802F0FD88084CC4D82A0663874219D1A1887E1C4wtlexchp2sandvi_-- From Ron_Parker@affirmednetworks.com Wed Jan 22 13:01:08 2014 Return-Path: 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 3367E1A010C for ; Wed, 22 Jan 2014 13:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 AHd8PTmIGf8L for ; Wed, 22 Jan 2014 13:01:06 -0800 (PST) Received: from hub021-ca-6.exch021.serverdata.net (hub021-ca-6.exch021.serverdata.net [64.78.56.71]) by ietfa.amsl.com (Postfix) with ESMTP id EE7B01A012E for ; Wed, 22 Jan 2014 13:01:05 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.03.0158.001; Wed, 22 Jan 2014 13:01:05 -0800 From: Ron Parker To: Chris Frederick , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: WG adoption of draft-quinn-sfc-problem-statement-02 Thread-Index: AQHPFtz0BBXmRpg9rk2thNSnYBnFRZqPsP9wgAGCVlCAAAbCgA== Date: Wed, 22 Jan 2014 21:01:03 +0000 Message-ID: References: <802F0FD88084CC4D82A0663874219D1A1887E1C4@wtl-exchp-2.sandvine.com> In-Reply-To: <802F0FD88084CC4D82A0663874219D1A1887E1C4@wtl-exchp-2.sandvine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A7970ADMBX021W3CA2exch_" MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 21:01:08 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A7970ADMBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Chris. I agree that symmetric traffic flows are very important from a practical pe= rspective. Draft-quinn-sfc-problem-statement-02 does acknowledge that th= ey exist as part of the problem space. Perhaps this is an area that deser= ves particular attention in free-standing drafts and/or in what becomes the= final architecture spec. Do you also feel that more should be said in th= e problem statement document? Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Chris Frederick Sent: Wednesday, January 22, 2014 3:49 PM To: Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 Hi Jim, Thomas, I think the draft looks good. My comment is that perhaps it doesn't consider all the challenges related t= o network asymmetry (i.e. where a flow's packets traverse different links). I've read subsection 12 of the Problem Space ("Symmetric Traffic Flows") an= d agree with the issue, as stated. However, we (Sandvine) take a somewhat different view of the challenges aro= und symmetry. In our experience (residential broadband service networks), s= ervice chains are always bidirectional; the reason is that most application= s manipulate the session state of the flow, which is impossible to do in on= ly one direction. We believe the primary challenge with symmetry - and one of the most import= ant issues with service chaining in general - is the graceful handling of n= etwork asymmetry, to facilitate stateful inspection of bidirectional flows. A redirected flow that needs to be chained (say, a Netflix flow for example= ) will often switch providers (+ network links) during its lifespan and thi= s can present issues for SFC; there are different ways to address this chal= lenge but they're not all equivalent in terms of efficacy and suitability. = Best regards, Chris From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Tuesday, January 21, 2014 11:14 AM To: sfc@ietf.org Subject: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 Thomas and I would like to remind you of the ongoing WG call for adoption o= f draft-quinn-sfc-problem-statement-02. We have received numerous positive = responses to our original email and plan to formally close out the call for= adoption this coming Friday (1/24/14). If folks have any additional commen= ts or concerns please voice them before this Friday. Jim & Thomas SFC chairs. --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A7970ADMBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Chris.

 <= /p>

I agree that symmetric tr= affic flows are very important from a practical perspective.  &nb= sp; Draft-quinn-sfc-problem-statement-02 does acknowledge that they exist as part of the problem space.   Perhaps this is an area that des= erves particular attention in free-standing drafts and/or in what becomes t= he final architecture spec.   Do you also feel that more should b= e said in the problem statement document?

 <= /p>

   Ron

 <= /p>

 <= /p>

From: sfc [m= ailto:sfc-bounces@ietf.org] On Behalf Of Chris Frederick
Sent: Wednesday, January 22, 2014 3:49 PM
To: Jim Guichard (jguichar); sfc@ietf.org
Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-= 02

 

Hi Jim, Thomas,

I think the draft looks g= ood.

My comment is that perhap= s it doesn’t consider all the challenges related to network asymmetry= (i.e. where a flow’s packets traverse different links).

I’ve read subsection 12 of the Proble=
m Space (“Symmetric Traffic Flows”) and agree with the i=
ssue, as stated. 
However, we (Sandvine) take a somewhat diff=
erent view of the challenges around symmetry. In our experience (residentia=
l broadband service networks), service chains are always bidirectional; the=
 reason is that most applications manipulate the session state of the flow,=
 which is impossible to do in only one direction.

We believe the primary ch= allenge with symmetry – and one of the most important issues with ser= vice chaining in general – is the graceful handling of network asymmetry, to facilitate stateful inspection of bidirectional flows. =

A redirected flow that ne= eds to be chained (say, a Netflix flow for example) will often switch provi= ders (+ network links) during its lifespan and this can present issues for SFC; there are different ways to address this challenge= but they’re not all equivalent in terms of efficacy and suitability.= Best regards,

Chris

 <= /p>

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, January 21, 2014 11:14 AM
To: sfc@ietf.org
Subject: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

 

Thomas and I would like to = remind you of the ongoing WG call for adoption of draft-quinn-sfc-problem-s= tatement-02. We have received numerous positive responses to our original email and plan to formally close out the call for adoption= this coming Friday (1/24/14). If folks have any additional comments or con= cerns please voice them before this Friday.

 

Jim & Thomas=

SFC chairs. 

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A7970ADMBX021W3CA2exch_-- From Ron_Parker@affirmednetworks.com Wed Jan 22 13:05:50 2014 Return-Path: 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 47A9F1A0221 for ; Wed, 22 Jan 2014 13:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 iwzS6WOJEjPG for ; Wed, 22 Jan 2014 13:05:47 -0800 (PST) Received: from hub021-ca-1.exch021.serverdata.net (hub021-ca-1.exch021.serverdata.net [64.78.22.168]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD071A0239 for ; Wed, 22 Jan 2014 13:05:39 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-1.exch021.domain.local ([10.254.4.30]) with mapi id 14.03.0158.001; Wed, 22 Jan 2014 13:05:38 -0800 From: Ron Parker To: Cathy Zhang , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: WG adoption of draft-quinn-sfc-problem-statement-02 Thread-Index: AQHPFtz0BBXmRpg9rk2thNSnYBnFRZqPsP9wgAGLn2A= Date: Wed, 22 Jan 2014 21:05:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A7970E0MBX021W3CA2exch_" MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 21:05:50 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A7970E0MBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Cathy. There was considerable discussion on the thread regarding a common service = encapsulation to carry chain-id and other metadata inside of a choice of tr= ansport encapsulations, including VXLAN. The reasons presented to keep t= hese distinct and not try to introduce chain-id or other metadata into the = subset of transports that could effectively carry such a thing was to enhan= ce the universality and interoperability of the solution. Such an appro= ach lends itself well to current and perhaps future SDN techniques, but doe= s not mandate them. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Cathy Zhang Sent: Wednesday, January 22, 2014 3:12 PM To: Jim Guichard (jguichar); sfc@ietf.org; Cathy Zhang Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 Hi Jim, I have the following questions/comments: 1. Definition of Service Function It mentions that "Multiple instances of the Service Function can be enabled= in the same administrative domain". There is also the case that multiple i= nstances of the Service Function can be instantiated on the same Service No= de. For example on a FW appliance, we can instantiate multiple FW service instances with each FW service instance having its own = filtering rules. Could we add this into the Definition? 2. Service Overlay AFAIK, there is a proposal for a new overlay mechanism. Shall we also explo= re and leverage existing overlay mechanism? I am thinking that we might als= o want to take current prevailing overlay mechanism into our consideration for service function ch= aining, such as VXLAN overlay which is supported in many virtual/physical s= witches and which has reserved fields that can be used to carry chain-ID and other meta= data. 3. "Enterprise Data Center Service Chaining" section is TBD. Is there = a plan to compete this section? Thanks, Cathy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Tuesday, January 21, 2014 11:14 AM To: sfc@ietf.org Subject: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 Thomas and I would like to remind you of the ongoing WG call for adoption o= f draft-quinn-sfc-problem-statement-02. We have received numerous positive = responses to our original email and plan to formally close out the call for= adoption this coming Friday (1/24/14). If folks have any additional commen= ts or concerns please voice them before this Friday. Jim & Thomas SFC chairs. --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A7970E0MBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Cathy.

 <= /p>

There was considerable di= scussion on the thread regarding a common service encapsulation to carry ch= ain-id and other metadata inside of a choice of transport encapsulations, including VXLAN.    The reasons presented t= o keep these distinct and not try to introduce chain-id or other metadata i= nto the subset of transports that could effectively carry such a thing was = to enhance the universality and interoperability of the solution.     Such an approach lends itself wel= l to current and perhaps future SDN techniques, but does not mandate them.<= o:p>

 <= /p>

   Ron

 <= /p>

 <= /p>

From: sfc [m= ailto:sfc-bounces@ietf.org] On Behalf Of Cathy Zhang
Sent: Wednesday, January 22, 2014 3:12 PM
To: Jim Guichard (jguichar); sfc@ietf.org; Cathy Zhang
Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-= 02

 

Hi Jim,

 

I have the following q= uestions/comments:

1.&n= bsp;     Definition of = Service Function

It mentions tha= t “Multiple instances of the Service Function can be enabled in the s= ame administrative domain”. There is also the case that multiple inst= ances of the Service Function can be instantiated on the same Service Node. For example on a FW appliance, we can instantiat= e

multiple FW ser= vice instances with each FW service instance having its own filtering rules= . Could we add this into the Definition?

2.&n= bsp;     Service Overla= y

AFAIK, there is= a proposal for a new overlay mechanism. Shall we also explore and leverage= existing overlay mechanism? I am thinking that we might also want to take = current

prevailing over= lay mechanism into our consideration for service function chaining, such as= VXLAN overlay which is supported in many virtual/physical switches and

which has reser= ved fields that can be used to carry chain-ID and other metadata. 

 

3.&n= bsp;     “Enterpr= ise Data Center Service Chaining” section is TBD. Is there a plan to = compete this section?

 

Thanks,

Cathy

 <= /p>

 <= /p>

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, January 21, 2014 11:14 AM
To: sfc@ietf.org
Subject: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

 

Thomas and I would like to = remind you of the ongoing WG call for adoption of draft-quinn-sfc-problem-s= tatement-02. We have received numerous positive responses to our original email and plan to formally close out the call for adoption= this coming Friday (1/24/14). If folks have any additional comments or con= cerns please voice them before this Friday.

 

Jim & Thomas=

SFC chairs. 

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A7970E0MBX021W3CA2exch_-- From cfrederick@sandvine.com Wed Jan 22 13:10:19 2014 Return-Path: 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 C9A331A0239 for ; Wed, 22 Jan 2014 13:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] 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 VkfUSRyiiGqF for ; Wed, 22 Jan 2014 13:10:17 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id D44731A0171 for ; Wed, 22 Jan 2014 13:10:15 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%20]) with mapi id 14.01.0339.001; Wed, 22 Jan 2014 16:10:14 -0500 From: Chris Frederick To: Ron Parker , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: WG adoption of draft-quinn-sfc-problem-statement-02 Thread-Index: AQHPFtz0BBXmRpg9rk2thNSnYBnFRZqPsP9wgAGCVlCAAAbCgIAAA08Q Date: Wed, 22 Jan 2014 21:10:14 +0000 Message-ID: <802F0FD88084CC4D82A0663874219D1A1887E1FF@wtl-exchp-2.sandvine.com> References: <802F0FD88084CC4D82A0663874219D1A1887E1C4@wtl-exchp-2.sandvine.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.194.252] Content-Type: multipart/alternative; boundary="_000_802F0FD88084CC4D82A0663874219D1A1887E1FFwtlexchp2sandvi_" MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 21:10:20 -0000 --_000_802F0FD88084CC4D82A0663874219D1A1887E1FFwtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ron, >From our perspective this is one of the integral SFC challenges (at least i= n the SFC scenarios we encounter) and we'd welcome a more explicit examinat= ion in the problem statement document. Failing that, inclusion in the final architecture spec is a viable alternat= ive too, as you suggest. Either way, would be happy to have an open discuss= ion and provide input for consideration. Best, /c From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Wednesday, January 22, 2014 4:01 PM To: Chris Frederick; Jim Guichard (jguichar); sfc@ietf.org Subject: RE: WG adoption of draft-quinn-sfc-problem-statement-02 Hi, Chris. I agree that symmetric traffic flows are very important from a practical pe= rspective. Draft-quinn-sfc-problem-statement-02 does acknowledge that th= ey exist as part of the problem space. Perhaps this is an area that deser= ves particular attention in free-standing drafts and/or in what becomes the= final architecture spec. Do you also feel that more should be said in th= e problem statement document? Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Chris Frederick Sent: Wednesday, January 22, 2014 3:49 PM To: Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 Hi Jim, Thomas, I think the draft looks good. My comment is that perhaps it doesn't consider all the challenges related t= o network asymmetry (i.e. where a flow's packets traverse different links). I've read subsection 12 of the Problem Space ("Symmetric Traffic Flows") an= d agree with the issue, as stated. However, we (Sandvine) take a somewhat different view of the challenges aro= und symmetry. In our experience (residential broadband service networks), s= ervice chains are always bidirectional; the reason is that most application= s manipulate the session state of the flow, which is impossible to do in on= ly one direction. We believe the primary challenge with symmetry - and one of the most import= ant issues with service chaining in general - is the graceful handling of n= etwork asymmetry, to facilitate stateful inspection of bidirectional flows. A redirected flow that needs to be chained (say, a Netflix flow for example= ) will often switch providers (+ network links) during its lifespan and thi= s can present issues for SFC; there are different ways to address this chal= lenge but they're not all equivalent in terms of efficacy and suitability. = Best regards, Chris From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Tuesday, January 21, 2014 11:14 AM To: sfc@ietf.org Subject: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 Thomas and I would like to remind you of the ongoing WG call for adoption o= f draft-quinn-sfc-problem-statement-02. We have received numerous positive = responses to our original email and plan to formally close out the call for= adoption this coming Friday (1/24/14). If folks have any additional commen= ts or concerns please voice them before this Friday. Jim & Thomas SFC chairs. --_000_802F0FD88084CC4D82A0663874219D1A1887E1FFwtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ron,=

From our perspective this= is one of the integral SFC challenges (at least in the SFC scenarios we en= counter) and we’d welcome a more explicit examination in the problem statement document.

Failing that, inclusion i= n the final architecture spec is a viable alternative too, as you suggest. = Either way, would be happy to have an open discussion and provide input for consideration. Best,

/c

 <= /p>

From: Ron Park= er [mailto:Ron_Parker@affirmednetworks.com]
Sent: Wednesday, January 22, 2014 4:01 PM
To: Chris Frederick; Jim Guichard (jguichar); sfc@ietf.org
Subject: RE: WG adoption of draft-quinn-sfc-problem-statement-02

 

Hi, Chris.

 <= /p>

I agree that symmetric tr= affic flows are very important from a practical perspective.  &nb= sp; Draft-quinn-sfc-problem-statement-02 does acknowledge that they exist as part of the problem space.   Perhaps this is an area that des= erves particular attention in free-standing drafts and/or in what becomes t= he final architecture spec.   Do you also feel that more should b= e said in the problem statement document?

 <= /p>

   Ron

 <= /p>

 <= /p>

From: sfc [<= a href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org] On Behalf Of Chris Frederick
Sent: Wednesday, January 22, 2014 3:49 PM
To: Jim Guichard (jguichar); sfc@iet= f.org
Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-= 02

 

Hi Jim, Thomas,

I think the draft looks g= ood.

My comment is that perhap= s it doesn’t consider all the challenges related to network asymmetry= (i.e. where a flow’s packets traverse different links).

I’ve read subsection 12 of the Proble=
m Space (“Symmetric Traffic Flows”) and agree with the i=
ssue, as stated. 
However, we (Sandvine) take a somewhat diff=
erent view of the challenges around symmetry. In our experience (residentia=
l broadband service networks), service chains are always bidirectional; the=
 reason is that most applications manipulate the session state of the flow,=
 which is impossible to do in only one direction.

We believe the primary ch= allenge with symmetry – and one of the most important issues with ser= vice chaining in general – is the graceful handling of network asymmetry, to facilitate stateful inspection of bidirectional flows. =

A redirected flow that ne= eds to be chained (say, a Netflix flow for example) will often switch provi= ders (+ network links) during its lifespan and this can present issues for SFC; there are different ways to address this challenge= but they’re not all equivalent in terms of efficacy and suitability.= Best regards,

Chris

 <= /p>

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, January 21, 2014 11:14 AM
To: sfc@ietf.org
Subject: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

 

Thomas and I would like to = remind you of the ongoing WG call for adoption of draft-quinn-sfc-problem-s= tatement-02. We have received numerous positive responses to our original email and plan to formally close out the call for adoption= this coming Friday (1/24/14). If folks have any additional comments or con= cerns please voice them before this Friday.

 

Jim & Thomas=

SFC chairs. 

--_000_802F0FD88084CC4D82A0663874219D1A1887E1FFwtlexchp2sandvi_-- From jmoisand@juniper.net Wed Jan 22 13:39:28 2014 Return-Path: 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 E7B751A03AB for ; Wed, 22 Jan 2014 13:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 WeaLwHCLseDe for ; Wed, 22 Jan 2014 13:39:24 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id BE1FD1A0390 for ; Wed, 22 Jan 2014 13:39:23 -0800 (PST) Received: from mail203-co1-R.bigfish.com (10.243.78.239) by CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id 14.1.225.22; Wed, 22 Jan 2014 21:39:22 +0000 Received: from mail203-co1 (localhost [127.0.0.1]) by mail203-co1-R.bigfish.com (Postfix) with ESMTP id D57CA3A011D; Wed, 22 Jan 2014 21:39:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(zzbb2dI9371Ic85fhe0eah11fbIzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1c8fb4h1de097h186068h1df0a0iz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24ach24d7h9a9j1155h) Received-SPF: pass (mail203-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(199002)(189002)(377454003)(46034005)(479174003)(19580405001)(83322001)(19300405004)(86362001)(33646001)(51856001)(50986001)(74876001)(66066001)(74316001)(74706001)(83072002)(47976001)(80022001)(54356001)(47736001)(65816001)(49866001)(4396001)(19580395003)(46102001)(15202345003)(53806001)(81686001)(92566001)(90146001)(16236675002)(94316002)(93516002)(74366001)(93136001)(80976001)(2656002)(56816005)(76482001)(87936001)(85852003)(47446002)(74502001)(85306002)(81342001)(19609705001)(81542001)(81816001)(79102001)(63696002)(87266001)(31966008)(76576001)(76786001)(59766001)(54316002)(77982001)(15975445006)(74662001)(56776001)(18717965001)(69226001)(76796001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB715; H:CO2PR05MB716.namprd05.prod.outlook.com; CLIP:66.129.241.10; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail203-co1 (localhost.localdomain [127.0.0.1]) by mail203-co1 (MessageSwitch) id 1390426760294442_1448; Wed, 22 Jan 2014 21:39:20 +0000 (UTC) Received: from CO1EHSMHS021.bigfish.com (unknown [10.243.78.246]) by mail203-co1.bigfish.com (Postfix) with ESMTP id 4325358004C; Wed, 22 Jan 2014 21:39:20 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS021.bigfish.com (10.243.66.31) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 22 Jan 2014 21:39:20 +0000 Received: from CO2PR05MB715.namprd05.prod.outlook.com (10.141.228.150) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.395.1; Wed, 22 Jan 2014 21:39:16 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com (10.141.228.152) by CO2PR05MB715.namprd05.prod.outlook.com (10.141.228.150) with Microsoft SMTP Server (TLS) id 15.0.851.15; Wed, 22 Jan 2014 21:39:13 +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; Wed, 22 Jan 2014 21:39:13 +0000 From: Jerome Moisand To: Chris Frederick , Ron Parker , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: WG adoption of draft-quinn-sfc-problem-statement-02 Thread-Index: AQHPFtz0BBXmRpg9rk2thNSnYBnFRZqPsP9wgAGCVlCAAAbCgIAAA08QgAAHe7A= Date: Wed, 22 Jan 2014 21:39:13 +0000 Message-ID: References: <802F0FD88084CC4D82A0663874219D1A1887E1C4@wtl-exchp-2.sandvine.com> <802F0FD88084CC4D82A0663874219D1A1887E1FF@wtl-exchp-2.sandvine.com> In-Reply-To: <802F0FD88084CC4D82A0663874219D1A1887E1FF@wtl-exchp-2.sandvine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-forefront-prvs: 00997889E7 Content-Type: multipart/alternative; boundary="_000_cfaa6f702d0e46fd984f821937572cf6CO2PR05MB716namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 21:39:28 -0000 --_000_cfaa6f702d0e46fd984f821937572cf6CO2PR05MB716namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I share Chris' perspective, most practical fixed-broadband use cases requir= e symmetry (this is more than residential, btw, this also includes small/me= dium business and public sites) due to some form of state keeping. Same is = probably true for mobile-broadband. There are clearly scenarios which do no= t, though, e.g. when video streaming is involved, or URL filtering. And I a= gree with Chris that (selective) symmetrical forwarding is one of the most = vexing challenges we have with service chaining. So a bit more emphasis wouldn't hurt. But we can always do that as we progr= ess on the document, adoption by the work group isn't about freezing the do= cument as is... As a side note, IETF should expect some formal communication soon from the = Broadband Forum (BBF) about service chaining, including some representative= use cases. Cheers, Jerome From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Chris Frederick Sent: Wednesday, January 22, 2014 4:10 PM To: Ron Parker; Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 Hi Ron, >From our perspective this is one of the integral SFC challenges (at least i= n the SFC scenarios we encounter) and we'd welcome a more explicit examinat= ion in the problem statement document. Failing that, inclusion in the final architecture spec is a viable alternat= ive too, as you suggest. Either way, would be happy to have an open discuss= ion and provide input for consideration. Best, /c From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Wednesday, January 22, 2014 4:01 PM To: Chris Frederick; Jim Guichard (jguichar); sfc@ietf.org Subject: RE: WG adoption of draft-quinn-sfc-problem-statement-02 Hi, Chris. I agree that symmetric traffic flows are very important from a practical pe= rspective. Draft-quinn-sfc-problem-statement-02 does acknowledge that th= ey exist as part of the problem space. Perhaps this is an area that deser= ves particular attention in free-standing drafts and/or in what becomes the= final architecture spec. Do you also feel that more should be said in th= e problem statement document? Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Chris Frederick Sent: Wednesday, January 22, 2014 3:49 PM To: Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 Hi Jim, Thomas, I think the draft looks good. My comment is that perhaps it doesn't consider all the challenges related t= o network asymmetry (i.e. where a flow's packets traverse different links). I've read subsection 12 of the Problem Space ("Symmetric Traffic Flows") an= d agree with the issue, as stated. However, we (Sandvine) take a somewhat different view of the challenges aro= und symmetry. In our experience (residential broadband service networks), s= ervice chains are always bidirectional; the reason is that most application= s manipulate the session state of the flow, which is impossible to do in on= ly one direction. We believe the primary challenge with symmetry - and one of the most import= ant issues with service chaining in general - is the graceful handling of n= etwork asymmetry, to facilitate stateful inspection of bidirectional flows. A redirected flow that needs to be chained (say, a Netflix flow for example= ) will often switch providers (+ network links) during its lifespan and thi= s can present issues for SFC; there are different ways to address this chal= lenge but they're not all equivalent in terms of efficacy and suitability. = Best regards, Chris From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Tuesday, January 21, 2014 11:14 AM To: sfc@ietf.org Subject: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 Thomas and I would like to remind you of the ongoing WG call for adoption o= f draft-quinn-sfc-problem-statement-02. We have received numerous positive = responses to our original email and plan to formally close out the call for= adoption this coming Friday (1/24/14). If folks have any additional commen= ts or concerns please voice them before this Friday. Jim & Thomas SFC chairs. --_000_cfaa6f702d0e46fd984f821937572cf6CO2PR05MB716namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I share Chris’ pers= pective, most practical fixed-broadband use cases require symmetry (this is= more than residential, btw, this also includes small/medium business and public sites) due to some form of state keeping. Same is probably true= for mobile-broadband. There are clearly scenarios which do not, though, e.= g. when video streaming is involved, or URL filtering. And I agree with Chr= is that (selective) symmetrical forwarding is one of the most vexing challenges we have with service chain= ing.

 <= /p>

So a bit more emphasis wo= uldn’t hurt. But we can always do that as we progress on the document= , adoption by the work group isn’t about freezing the document as is…

 <= /p>

As a side note, IETF shou= ld expect some formal communication soon from the Broadband Forum (BBF) abo= ut service chaining, including some representative use cases.

 <= /p>

Cheers,=

Jerome<= /p>

 <= /p>

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Chris Frederick
Sent: Wednesday, January 22, 2014 4:10 PM
To: Ron Parker; Jim Guichard (jguichar); sfc@ietf.org
Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-= 02

 

Hi Ron,=

From our perspective this= is one of the integral SFC challenges (at least in the SFC scenarios we en= counter) and we’d welcome a more explicit examination in the problem statement document.

Failing that, inclusion i= n the final architecture spec is a viable alternative too, as you suggest. = Either way, would be happy to have an open discussion and provide input for consideration. Best,

/c

 <= /p>

From: Ron Park= er [mailto:Ron_Parker@af= firmednetworks.com]
Sent: Wednesday, January 22, 2014 4:01 PM
To: Chris Frederick; Jim Guichard (jguichar); sfc@ietf.org
Subject: RE: WG adoption of draft-quinn-sfc-problem-statement-02

 

Hi, Chris.

 <= /p>

I agree that symmetric tr= affic flows are very important from a practical perspective.  &nb= sp; Draft-quinn-sfc-problem-statement-02 does acknowledge that they exist as part of the problem space.   Perhaps this is an area that des= erves particular attention in free-standing drafts and/or in what becomes t= he final architecture spec.   Do you also feel that more should b= e said in the problem statement document?

 <= /p>

   Ron

 <= /p>

 <= /p>

From: sfc [<= a href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org] On Behalf Of Chris Frederick
Sent: Wednesday, January 22, 2014 3:49 PM
To: Jim Guichard (jguichar); sfc@iet= f.org
Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-= 02

 

Hi Jim, Thomas,

I think the draft looks g= ood.

My comment is that perhap= s it doesn’t consider all the challenges related to network asymmetry= (i.e. where a flow’s packets traverse different links).

I’ve read subsection 12 of the Proble=
m Space (“Symmetric Traffic Flows”) and agree with the i=
ssue, as stated. 
However, we (Sandvine) take a somewhat diff=
erent view of the challenges around symmetry. In our experience (residentia=
l broadband service networks), service chains are always bidirectional; the=
 reason is that most applications manipulate the session state of the flow,=
 which is impossible to do in only one direction.

We believe the primary ch= allenge with symmetry – and one of the most important issues with ser= vice chaining in general – is the graceful handling of network asymmetry, to facilitate stateful inspection of bidirectional flows. =

A redirected flow that ne= eds to be chained (say, a Netflix flow for example) will often switch provi= ders (+ network links) during its lifespan and this can present issues for SFC; there are different ways to address this challenge= but they’re not all equivalent in terms of efficacy and suitability.= Best regards,

Chris

 <= /p>

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, January 21, 2014 11:14 AM
To: sfc@ietf.org
Subject: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

 

Thomas and I would like to = remind you of the ongoing WG call for adoption of draft-quinn-sfc-problem-s= tatement-02. We have received numerous positive responses to our original email and plan to formally close out the call for adoption= this coming Friday (1/24/14). If folks have any additional comments or con= cerns please voice them before this Friday.

 

Jim & Thomas=

SFC chairs. 

--_000_cfaa6f702d0e46fd984f821937572cf6CO2PR05MB716namprd05pro_-- From Kevin.Glavin@riverbed.com Wed Jan 22 14:11:03 2014 Return-Path: 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 F294B1A012E for ; Wed, 22 Jan 2014 14:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, 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 WkYmxQQmtRmz for ; Wed, 22 Jan 2014 14:10:58 -0800 (PST) Received: from smtp1.riverbed.com (smtp1.riverbed.com [208.70.196.45]) by ietfa.amsl.com (Postfix) with ESMTP id 286FB1A010C for ; Wed, 22 Jan 2014 14:10:58 -0800 (PST) Received: from unknown (HELO 365EXCH-HUB-P1.nbttech.com) ([10.16.4.1]) by smtp1.riverbed.com with ESMTP; 22 Jan 2014 14:10:57 -0800 Received: from SFO1EXC-MBXP07.nbttech.com ([fe80::470:1b85:695b:b44e]) by 365EXCH-HUB-P1.nbttech.com ([::1]) with mapi id 14.02.0328.009; Wed, 22 Jan 2014 14:10:57 -0800 From: Kevin Glavin To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] IPR check for draft-quinn-sfc-problem-statement Thread-Index: AQHPF77SNSEh36Zfh0G0Wjova3ew6A== Date: Wed, 22 Jan 2014 22:10:56 +0000 Message-ID: <9EA32E60D7600C43B6FE22876DF564C81D898B58@SFO1EXC-MBXP07.nbttech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.205.250] Content-Type: multipart/alternative; boundary="_000_9EA32E60D7600C43B6FE22876DF564C81D898B58SFO1EXCMBXP07nb_" MIME-Version: 1.0 Cc: Thomas Narten Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 22:11:03 -0000 --_000_9EA32E60D7600C43B6FE22876DF564C81D898B58SFO1EXCMBXP07nb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nothing that I have to disclose. Kevin From: "Jim Guichard (jguichar)" > Date: Tuesday, January 21, 2014 11:05 AM To: "sfc@ietf.org" > Cc: Thomas Narten > Subject: [sfc] IPR check for draft-quinn-sfc-problem-statement This email serves as a poll for knowledge of any IPR that applies to draft = [1], to ensure that IPR has been disclosed in compliance with IETF IPR rule= s (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email whether or not you are aware of any relevant IPR. The draft will no= t be adopted until a response has been received from each author and major = contributor. If you are on the SFC WG mailing list but are not listed as an author or co= ntributor, then please explicitly respond only if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. Thank you, Jim & Thomas SFC chairs [1] http://tools.ietf.org/id/draft-quinn-sfc-problem-statement-02.txt --_000_9EA32E60D7600C43B6FE22876DF564C81D898B58SFO1EXCMBXP07nb_ Content-Type: text/html; charset="us-ascii" Content-ID: <117137194556F640BE5A0F7651AF10BD@riverbed.com> Content-Transfer-Encoding: quoted-printable
Nothing that I have to disclose. 

Kevin

From: "Jim Guichard (jguichar)= " <jguichar@cisco.com>=
Date: Tuesday, January 21, 2014 11:= 05 AM
To: "sfc@ietf.org" <sfc@ietf.= org>
Cc: Thomas Narten <narten@us.ibm.com>
Subject: [sfc] IPR check for draft-= quinn-sfc-problem-statement

This email serves as a poll for knowledge of any IPR that applies to d= raft [1], to ensure that IPR has been disclosed in compliance with IETF IPR= rules (see RFCs 3979, 4879, 3669 and 5378 for more details). 

If you are listed as a document author or contributor please respond t= o this email whether or not you are aware of any relevant IPR. The draft wi= ll not be adopted until a response has been received from each author and m= ajor contributor. 

If you are on the SFC WG mailing list but are not listed as an author = or contributor, then please explicitly respond only if you are aware of any= IPR that has not yet been disclosed in conformance with IETF rules. <= /div>

Thank you,

Jim & Thomas
SFC chairs

--_000_9EA32E60D7600C43B6FE22876DF564C81D898B58SFO1EXCMBXP07nb_-- From jguichar@cisco.com Wed Jan 22 14:36:52 2014 Return-Path: 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 0DD051A04FC for ; Wed, 22 Jan 2014 14:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 SzsgcJg6Bf12 for ; Wed, 22 Jan 2014 14:36:49 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id E569B1A04F9 for ; Wed, 22 Jan 2014 14:36:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17338; q=dns/txt; s=iport; t=1390430208; x=1391639808; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=EcC9We2DYy4N+yajW3cWNCCniEOZVsffa0toKGib9a8=; b=bhBB3ZXwORh+dFQ8s2M1kh0h6MAo1uteRvUpbYvdz1ImBJPx+TQzEz6H K/lN58jC9AxmX/h45NVOpBPovMqbIg9pHzS8aLh4/7tgzt9lmw02rRtGs zVIdu2LqG1RqCHo25NwpYYCUxXLhda0wnmP1llil/ENXlFWfuiXfZrJ09 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFANBG4FKtJV2a/2dsb2JhbABbgkhEOFa7XoETFnSCJQEBAQQdEEEdAQgRAwEBASg5FAkIAgQBEogFxBYXjhoRASwTFwEChDYEmCKSGIMtgXE5 X-IronPort-AV: E=Sophos;i="4.95,702,1384300800"; d="scan'208,217";a="14809207" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP; 22 Jan 2014 22:36:48 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0MMalC7032523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jan 2014 22:36:48 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.207]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Wed, 22 Jan 2014 16:36:47 -0600 From: "Jim Guichard (jguichar)" To: Cathy Zhang , "sfc@ietf.org" Thread-Topic: WG adoption of draft-quinn-sfc-problem-statement-02 Thread-Index: AQHPFtz0BBXmRpg9rk2thNSnYBnFRZqPsP9wgAG25QA= Date: Wed, 22 Jan 2014 22:36:47 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.183] Content-Type: multipart/alternative; boundary="_000_CF05AD35146E8jguicharciscocom_" MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 22:36:52 -0000 --_000_CF05AD35146E8jguicharciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Cathy, From: Cathy Zhang > Date: Wednesday, January 22, 2014 3:12 PM To: Jim Guichard >, "sfc@ietf= .org" >, Cathy Zhang= > Subject: RE: WG adoption of draft-quinn-sfc-problem-statement-02 Hi Jim, I have the following questions/comments: 1. Definition of Service Function It mentions that =93Multiple instances of the Service Function can be enabl= ed in the same administrative domain=94. There is also the case that multip= le instances of the Service Function can be instantiated on the same Servic= e Node. For example on a FW appliance, we can instantiate multiple FW service instances with each FW service instance having its own = filtering rules. Could we add this into the Definition? Jim: as this question is directly related to the text of the draft I will l= et the document authors respond. 2. Service Overlay AFAIK, there is a proposal for a new overlay mechanism. Shall we also explo= re and leverage existing overlay mechanism? I am thinking that we might als= o want to take current prevailing overlay mechanism into our consideration for service function ch= aining, such as VXLAN overlay which is supported in many virtual/physical s= witches and which has reserved fields that can be used to carry chain-ID and other meta= data. Jim: our charter is very clear on this point; we have a work item (with ass= ociated milestone) to produce a service-level data plane encapsulation that= : [1] indicates the sequence of service functions that make up the service = function chain, [2] specifies the service function path, and [3] communicat= es context information between nodes that implement service functions and s= ervice function chains. Further, our charter states that "the working group= will consider using an existing encapsulation (with extensions as appropri= ate) if a suitable candidate is found". 3. =93Enterprise Data Center Service Chaining=94 section is TBD. Is th= ere a plan to compete this section? Jim: Thomas and I have been discussing how best to approach the subject of = use cases within the working group; we will be starting a new thread on the= mailing list shortly to detail our thoughts and to solicit input. Thanks, Cathy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Tuesday, January 21, 2014 11:14 AM To: sfc@ietf.org Subject: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 Thomas and I would like to remind you of the ongoing WG call for adoption o= f draft-quinn-sfc-problem-statement-02. We have received numerous positive = responses to our original email and plan to formally close out the call for= adoption this coming Friday (1/24/14). If folks have any additional commen= ts or concerns please voice them before this Friday. Jim & Thomas SFC chairs. --_000_CF05AD35146E8jguicharciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Cathy= ,

From: Cathy Zhang <Cathy.H.Zhang@huawei.com>
Date: Wednesday, January 22, 2014 3= :12 PM
To: Jim Guichard <jguichar@cisco.com>, "sfc@ietf.org" <s= fc@ietf.org>, Cathy Zhang <Cathy.H.Zhang@huawei.com>
Subject: RE: WG adoption of draft-q= uinn-sfc-problem-statement-02

Hi Jim,

 

I have the following q= uestions/comments:

1.      Definition= of Service Function

It mentions tha= t =93Multiple instances of the Service Function can be enabled in the same = administrative domain=94. There is also the case that multiple instances of= the Service Function can be instantiated on the same Service Node. For example on a FW appliance, we can instantiat= e

multiple FW ser= vice instances with each FW service instance having its own filtering rules= . Could we add this into the Definition?

Jim: as = this question is directly related to the text of the draft I will let the d= ocument authors respond.

2.      Service Ov= erlay

AFAIK, there is= a proposal for a new overlay mechanism. Shall we also explore and leverage= existing overlay mechanism? I am thinking that we might also want to take = current

prevailing over= lay mechanism into our consideration for service function chaining, such as= VXLAN overlay which is supported in many virtual/physical switches and

which has reser= ved fields that can be used to carry chain-ID and other metadata.


Jim: our= charter is very clear on this point; we have a work item (with associated = milestone) to produce a service-level data plane encapsulation that: [1] in= dicates the sequence of service functions that make up the service function chain, [2] specifies the service functio= n path, and [3] communicates context information between nodes that impleme= nt service functions and service function chains. Further, our charter stat= es that "the working group will consider using an existing encapsulation (with extensions as appropriate) = if a suitable candidate is found". 

3.      =93Enterpr= ise Data Center Service Chaining=94 section is TBD. Is there a plan to comp= ete this section?

Jim: Thomas and I have been discussing how best to approach the subjec= t of use cases within the working group; we will be starting a new thread o= n the mailing list shortly to detail our thoughts and to solicit input.&nbs= p;

=

 

Thanks,

Cathy

 

 

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, January 21, 2014 11:14 AM
To: sfc@ietf.org
Subject: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

 

Thomas and I would like to remind you of th= e ongoing WG call for adoption of draft-quinn-sfc-problem-statement-02. We = have received numerous positive responses to our original email and plan to formally close out the call for adoption= this coming Friday (1/24/14). If folks have any additional comments or con= cerns please voice them before this Friday.

 

Jim & Thomas

SFC chairs. 

 --_000_CF05AD35146E8jguicharciscocom_-- From hongyu.li@huawei.com Wed Jan 22 18:24:39 2014 Return-Path: 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 055801A038D for ; Wed, 22 Jan 2014 18:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 DZcwC-Z9uIuz for ; Wed, 22 Jan 2014 18:24:37 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AFE641A0155 for ; Wed, 22 Jan 2014 18:24:35 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCV21236; Thu, 23 Jan 2014 02:24:34 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Jan 2014 02:24:12 +0000 Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Jan 2014 02:24:26 +0000 Received: from SZXEMA509-MBX.china.huawei.com ([169.254.1.51]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Thu, 23 Jan 2014 10:24:23 +0800 From: "Hongyu Li (Julio)" To: Thomas Nadeau , Guichard Jim Thread-Topic: [sfc] IPR check for draft-quinn-sfc-problem-statement Thread-Index: AQHPFtu2NSEh36Zfh0G0Wjova3ew6JqPEX8AgAKFMfA= Date: Thu, 23 Jan 2014 02:24:22 +0000 Message-ID: <6EB34CB5D82C4645B826C56144826EA97E9B6E01@SZXEMA509-MBX.china.huawei.com> References: <6A6E5EEA-975B-482B-AFC7-7472DB9C1B00@lucidvision.com> In-Reply-To: <6A6E5EEA-975B-482B-AFC7-7472DB9C1B00@lucidvision.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.114.234] Content-Type: multipart/alternative; boundary="_000_6EB34CB5D82C4645B826C56144826EA97E9B6E01SZXEMA509MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Thomas Narten , "sfc@ietf.org" Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 02:24:39 -0000 --_000_6EB34CB5D82C4645B826C56144826EA97E9B6E01SZXEMA509MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBUaG9tYXMgTmFkZWF1DQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjIsIDIwMTQgMzo1NSBB TQ0KVG86IEd1aWNoYXJkIEppbQ0KQ2M6IFRob21hcyBOYXJ0ZW47IHNmY0BpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtzZmNdIElQUiBjaGVjayBmb3IgZHJhZnQtcXVpbm4tc2ZjLXByb2JsZW0tc3Rh dGVtZW50DQoNCg0KICAgICAgIE5vbmUgZnJvbSBteSBlbmQuDQoNCk9uIEphbiAyMSwgMjAxNDoy OjA1IFBNLCBhdCAyOjA1IFBNLCBKaW0gR3VpY2hhcmQgKGpndWljaGFyKSA8amd1aWNoYXJAY2lz Y28uY29tPG1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20+PiB3cm90ZToNCg0KDQpUaGlzIGVtYWls IHNlcnZlcyBhcyBhIHBvbGwgZm9yIGtub3dsZWRnZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0 byBkcmFmdCBbMV0sIHRvIGVuc3VyZSB0aGF0IElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4gY29t cGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFu ZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLg0KDQpJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3Vt ZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsIHdo ZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4gVGhlIGRyYWZ0 IHdpbGwgbm90IGJlIGFkb3B0ZWQgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBm cm9tIGVhY2ggYXV0aG9yIGFuZCBtYWpvciBjb250cmlidXRvci4NCg0KSWYgeW91IGFyZSBvbiB0 aGUgU0ZDIFdHIG1haWxpbmcgbGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9y IGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3Ug YXJlIGF3YXJlIG9mIGFueSBJUFIgdGhhdCBoYXMgbm90IHlldCBiZWVuIGRpc2Nsb3NlZCBpbiBj b25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuDQoNClRoYW5rIHlvdSwNCg0KSmltICYgVGhvbWFz DQpTRkMgY2hhaXJzDQoNClsxXSBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtcXVpbm4t c2ZjLXByb2JsZW0tc3RhdGVtZW50LTAyLnR4dA0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZzxtYWls dG86c2ZjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z ZmMNCg0K --_000_6EB34CB5D82C4645B826C56144826EA97E9B6E01SZXEMA509MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0K CXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEg NiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBh bm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpw Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpzcGFuLmFwcGxlLXRhYi1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRhYi1z cGFuO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+JiM0MzsxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5v cmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlRob21hcyBOYWRlYXU8YnI+DQo8Yj5TZW50OjwvYj4g V2VkbmVzZGF5LCBKYW51YXJ5IDIyLCAyMDE0IDM6NTUgQU08YnI+DQo8Yj5Ubzo8L2I+IEd1aWNo YXJkIEppbTxicj4NCjxiPkNjOjwvYj4gVGhvbWFzIE5hcnRlbjsgc2ZjQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbc2ZjXSBJUFIgY2hlY2sgZm9yIGRyYWZ0LXF1aW5uLXNmYy1w cm9ibGVtLXN0YXRlbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+DQo8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPk5vbmUgZnJvbSBteSBlbmQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5PbiBKYW4gMjEsIDIwMTQ6MjowNSBQTSwgYXQgMjowNSBQTSwgSmltIEd1aWNo YXJkIChqZ3VpY2hhcikgJmx0OzxhIGhyZWY9Im1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20iPmpn dWljaGFyQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhpcyBlbWFpbCBz ZXJ2ZXMgYXMgYSBwb2xsIGZvciBrbm93bGVkZ2Ugb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8g ZHJhZnQgWzFdLCB0byBlbnN1cmUgdGhhdCBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBs aWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAoc2VlDQogUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFu ZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPklmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNv bnRyaWJ1dG9yIHBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwgd2hldGhlciBvciBub3QgeW91 IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLiBUaGUgZHJhZnQgd2lsbCBub3QgYmUgYWRv cHRlZA0KIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhv ciBhbmQgbWFqb3IgY29udHJpYnV0b3IuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+SWYgeW91IGFyZSBvbiB0aGUgU0ZDIFdHIG1haWxpbmcgbGlzdCBidXQgYXJl IG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBs aWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlIG9mIGFueSBJUFIgdGhhdCBoYXMN CiBub3QgeWV0IGJlZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNlIHdpdGggSUVURiBydWxlcy4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGFuayB5b3UsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SmltICZhbXA7IFRob21hczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNGQyBjaGFpcnM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5bMV0mbmJzcDs8YSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtcXVpbm4tc2ZjLXByb2JsZW0tc3RhdGVtZW50LTAyLnR4 dCI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXF1aW5uLXNmYy1wcm9ibGVtLXN0YXRl bWVudC0wMi50eHQ8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNmYyBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6EB34CB5D82C4645B826C56144826EA97E9B6E01SZXEMA509MBXchi_-- From pagarwal@broadcom.com Wed Jan 22 23:05:47 2014 Return-Path: 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 5C6511A0260 for ; Wed, 22 Jan 2014 23:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] 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 h-pl3R4cDtOp for ; Wed, 22 Jan 2014 23:05:45 -0800 (PST) Received: from mail-gw3-out.broadcom.com (mail-gw3-out.broadcom.com [216.31.210.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9D01A025E for ; Wed, 22 Jan 2014 23:05:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,704,1384329600"; d="scan'208,217";a="10578297" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw3-out.broadcom.com with ESMTP; 22 Jan 2014 23:12:25 -0800 Received: from SJEXCHCAS06.corp.ad.broadcom.com (10.16.203.14) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.1.438.0; Wed, 22 Jan 2014 23:05:44 -0800 Received: from SJEXCHMB06.corp.ad.broadcom.com ([fe80::65ea:1de7:41c4:e948]) by SJEXCHCAS06.corp.ad.broadcom.com ([::1]) with mapi id 14.01.0438.000; Wed, 22 Jan 2014 23:05:43 -0800 From: Puneet Agarwal To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] IPR check for draft-quinn-sfc-problem-statement Thread-Index: AQHPGAmHNIZEzGbXwUutDBY6PgQ9Ow== Date: Thu, 23 Jan 2014 07:05:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_C161C05F21D24B53811E7D0B5064B69Fbroadcomcom_" MIME-Version: 1.0 Cc: Thomas Narten , "sfc@ietf.org" Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 07:05:47 -0000 --_000_C161C05F21D24B53811E7D0B5064B69Fbroadcomcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am not aware of any. Thx Puneet On Jan 21, 2014, at 11:05 AM, "Jim Guichard (jguichar)" > wrote: This email serves as a poll for knowledge of any IPR that applies to draft = [1], to ensure that IPR has been disclosed in compliance with IETF IPR rule= s (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email whether or not you are aware of any relevant IPR. The draft will no= t be adopted until a response has been received from each author and major = contributor. If you are on the SFC WG mailing list but are not listed as an author or co= ntributor, then please explicitly respond only if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. Thank you, Jim & Thomas SFC chairs [1] http://tools.ietf.org/id/draft-quinn-sfc-problem-statement-02.txt _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_C161C05F21D24B53811E7D0B5064B69Fbroadcomcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I am not aware of any.

Thx

Puneet



On Jan 21, 2014, at 11:05 AM, "Jim Guichard (jguichar)" <jguichar@cisco.com> wrote:

This email serves as a poll for knowledge of any IPR that applies to d= raft [1], to ensure that IPR has been disclosed in compliance with IETF IPR= rules (see RFCs 3979, 4879, 3669 and 5378 for more details). 

If you are listed as a document author or contributor please respond t= o this email whether or not you are aware of any relevant IPR. The draft wi= ll not be adopted until a response has been received from each author and m= ajor contributor. 

If you are on the SFC WG mailing list but are not listed as an author = or contributor, then please explicitly respond only if you are aware of any= IPR that has not yet been disclosed in conformance with IETF rules. <= /div>

Thank you,

Jim & Thomas
SFC chairs

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.iet= f.org/mailman/listinfo/sfc
--_000_C161C05F21D24B53811E7D0B5064B69Fbroadcomcom_-- From paulq@cisco.com Thu Jan 23 04:49:49 2014 Return-Path: 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 95BFF1A0362 for ; Thu, 23 Jan 2014 04:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 XuMLahIVxKxr for ; Thu, 23 Jan 2014 04:49:47 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 314EB1A0171 for ; Thu, 23 Jan 2014 04:49:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19288; q=dns/txt; s=iport; t=1390481386; x=1391690986; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=x5jsXTbU3ovevfM1KKvQBEKa1rbVNTRUB4+K5R7soEo=; b=NeYqfqo50KwvGpxUHT3bjiEpcWezLTDCwxJQqYFNqA/WJ8gcR/V5ZZ49 32xC+EX8gtzSEjWhltfkeKgwJp2mUChmxFpPAt0OhXY6WJVRRff/3KqGi oGHEwecvxrGEgGHRyuj8S0zwwplD3ryaLTX9WCO/nXrDdCdgZ6G5zTTjS 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAFQP4VKtJXG//2dsb2JhbABbgkhEOFa7coEQFnSCJQEBAQQBAQEaCgZBCxACAQgRAwEBASgHJwsUCQgCBAENBYgFDcVXEwSOHhEBLBMRBgECgyKBFASYI5IYgy2BcTk X-IronPort-AV: E=Sophos;i="4.95,706,1384300800"; d="scan'208,217";a="14946619" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-3.cisco.com with ESMTP; 23 Jan 2014 12:49:46 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0NCnkBm002507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Jan 2014 12:49:46 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.19]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Thu, 23 Jan 2014 06:49:45 -0600 From: "Paul Quinn (paulq)" To: "Jim Guichard (jguichar)" , Cathy Zhang Thread-Topic: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 Thread-Index: AQHPFtz0BBXmRpg9rk2thNSnYBnFRZqPsP9wgAG25QCAAUIjgA== Date: Thu, 23 Jan 2014 12:49:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.229] Content-Type: multipart/alternative; boundary="_000_DE09C008A5194B269F543A188ED41BE5ciscocom_" MIME-Version: 1.0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 12:49:49 -0000 --_000_DE09C008A5194B269F543A188ED41BE5ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, On Jan 22, 2014, at 5:36 PM, Jim Guichard (jguichar) > wrote: Hi Cathy, From: Cathy Zhang > Date: Wednesday, January 22, 2014 3:12 PM To: Jim Guichard >, "sfc@ietf= .org" >, Cathy Zhang= > Subject: RE: WG adoption of draft-quinn-sfc-problem-statement-02 Hi Jim, I have the following questions/comments: 1. Definition of Service Function It mentions that =93Multiple instances of the Service Function can be enabl= ed in the same administrative domain=94. There is also the case that multip= le instances of the Service Function can be instantiated on the same Servic= e Node. For example on a FW appliance, we can instantiate multiple FW service instances with each FW service instance having its own = filtering rules. Could we add this into the Definition? Jim: as this question is directly related to the text of the draft I will l= et the document authors respond. PQ> The defintion for service function has the following sentence: "One of= multiple Service Functions can be embedded in the same network element." = I think that conveys what you are asking for, it places no limitations of t= he type of function instantiated. Do you agree? (I will fix the typo (of= --> or) and remove the word network so the defn is more generic.) 2. Service Overlay AFAIK, there is a proposal for a new overlay mechanism. Shall we also explo= re and leverage existing overlay mechanism? I am thinking that we might als= o want to take current prevailing overlay mechanism into our consideration for service function ch= aining, such as VXLAN overlay which is supported in many virtual/physical s= witches and which has reserved fields that can be used to carry chain-ID and other meta= data. Jim: our charter is very clear on this point; we have a work item (with ass= ociated milestone) to produce a service-level data plane encapsulation that= : [1] indicates the sequence of service functions that make up the service = function chain, [2] specifies the service function path, and [3] communicat= es context information between nodes that implement service functions and s= ervice function chains. Further, our charter states that "the working group= will consider using an existing encapsulation (with extensions as appropri= ate) if a suitable candidate is found". 3. =93Enterprise Data Center Service Chaining=94 section is TBD. Is th= ere a plan to compete this section? Jim: Thomas and I have been discussing how best to approach the subject of = use cases within the working group; we will be starting a new thread on the= mailing list shortly to detail our thoughts and to solicit input. Thanks, Cathy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Tuesday, January 21, 2014 11:14 AM To: sfc@ietf.org Subject: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 Thomas and I would like to remind you of the ongoing WG call for adoption o= f draft-quinn-sfc-problem-statement-02. We have received numerous positive = responses to our original email and plan to formally close out the call for= adoption this coming Friday (1/24/14). If folks have any additional commen= ts or concerns please voice them before this Friday. Jim & Thomas SFC chairs. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_DE09C008A5194B269F543A188ED41BE5ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi,



On Jan 22, 2014, at 5:36 PM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:

Hi Cathy= ,

From: Cathy Zhang <Cathy.H.Zhang@huawei.com>
Date: Wednesday, January 22, 2014 3= :12 PM
To: Jim Guichard <jguichar@cisco.com>, "sfc@ietf.org" <s= fc@ietf.org>, Cathy Zhang <Cathy.H.Zhang@huawei.com>
Subject: RE: WG adoption of draft-q= uinn-sfc-problem-statement-02

Hi Jim,
 
I have the following= questions/comments:

1.      Definition= of Service Function

It mentions t= hat =93Multiple instances of the Service Function can be enabled in the sam= e administrative domain=94. There is also the case that multiple instances = of the Service Function can be instantiated on the same Service Node. For example on a FW appliance, we can instantiat= e
multiple FW s= ervice instances with each FW service instance having its own filtering rul= es. Could we add this into the Definition?

Jim: as = this question is directly related to the text of the draft I will let the d= ocument authors respond.



PQ>  The defintion for service function has the following sent= ence: "One of multiple Service Functions can be embedded in the same n= etwork element."  I think that conveys what you are asking for, i= t places no limitations of the type of function instantiated.   Do you agree?  (I will fix the typo (of --> or) and remove = the word network so the defn is more generic.)



2.      Service Ov= erlay

AFAIK, there = is a proposal for a new overlay mechanism. Shall we also explore and levera= ge existing overlay mechanism? I am thinking that we might also want to tak= e current
prevailing ov= erlay mechanism into our consideration for service function chaining, such = as VXLAN overlay which is supported in many virtual/physical switches and
which has res= erved fields that can be used to carry chain-ID and other metadata.<= /div>

Jim: our= charter is very clear on this point; we have a work item (with associated = milestone) to produce a service-level data plane encapsulation that: [1] in= dicates the sequence of service functions that make up the service function chain, [2] specifies the service functio= n path, and [3] communicates context information between nodes that impleme= nt service functions and service function chains. Further, our charter stat= es that "the working group will consider using an existing encapsulation (with extensions as appropriate) = if a suitable candidate is found". 

3.      =93Enterpr= ise Data Center Service Chaining=94 section is TBD. Is there a plan to comp= ete this section?

Jim: Thomas and I have been discussing how best to approach the subjec= t of use cases within the working group; we will be starting a new thread o= n the mailing list shortly to detail our thoughts and to solicit input.&nbs= p;

=

 
Thanks,
Cathy
 
 
From: sfc [m= ailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, January 21, 2014 11:14 AM
To: sfc@ietf.org
Subject: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02
 
Thomas and I would like to remind you of the ongoing WG= call for adoption of draft-quinn-sfc-problem-statement-02. We have receive= d numerous positive responses to our original email and plan to formally close out the call for adoption this c= oming Friday (1/24/14). If folks have any additional comments or concerns p= lease voice them before this Friday.
 
Jim & Thomas
SFC chairs. 
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

--_000_DE09C008A5194B269F543A188ED41BE5ciscocom_-- From Cathy.H.Zhang@huawei.com Thu Jan 23 11:34:03 2014 Return-Path: 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 764201A0197 for ; Thu, 23 Jan 2014 11:34:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 69qAROcHuTRU for ; Thu, 23 Jan 2014 11:33:59 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 716211A01CD for ; Thu, 23 Jan 2014 11:33:58 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCW02532; Thu, 23 Jan 2014 19:33:56 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Jan 2014 19:33:49 +0000 Received: from SJCEML702-CHM.china.huawei.com (10.212.94.48) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Jan 2014 19:33:53 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML702-CHM.china.huawei.com ([169.254.4.68]) with mapi id 14.03.0158.001; Thu, 23 Jan 2014 11:33:36 -0800 From: Cathy Zhang To: "Paul Quinn (paulq)" , "Jim Guichard (jguichar)" , Cathy Zhang Thread-Topic: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 Thread-Index: AQHPFtz0BBXmRpg9rk2thNSnYBnFRZqPsP9wgAG25QCAAUIjgP//+sSw Date: Thu, 23 Jan 2014 19:33:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.145.86] Content-Type: multipart/alternative; boundary="_000_A2C96F6779E6A041BC7023CC207FC99418F0A482SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 19:34:03 -0000 --_000_A2C96F6779E6A041BC7023CC207FC99418F0A482SJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim and Paul, Thanks for your response! Please see inline. Cathy From: Paul Quinn (paulq) [mailto:paulq@cisco.com] Sent: Thursday, January 23, 2014 4:50 AM To: Jim Guichard (jguichar); Cathy Zhang Cc: sfc@ietf.org Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 Hi, On Jan 22, 2014, at 5:36 PM, Jim Guichard (jguichar) > wrote: Hi Cathy, From: Cathy Zhang > Date: Wednesday, January 22, 2014 3:12 PM To: Jim Guichard >, "sfc@ietf= .org" >, Cathy Zhang= > Subject: RE: WG adoption of draft-quinn-sfc-problem-statement-02 Hi Jim, I have the following questions/comments: 1. Definition of Service Function It mentions that "Multiple instances of the Service Function can be enabled= in the same administrative domain". There is also the case that multiple i= nstances of the Service Function can be instantiated on the same Service No= de. For example on a FW appliance, we can instantiate multiple FW service instances with each FW service instance having its own = filtering rules. Could we add this into the Definition? Jim: as this question is directly related to the text of the draft I will l= et the document authors respond. PQ> The defintion for service function has the following sentence: "One of= multiple Service Functions can be embedded in the same network element." = I think that conveys what you are asking for, it places no limitations of t= he type of function instantiated. Do you agree? (I will fix the typo (of= --> or) and remove the word network so the defn is more generic.) Cathy> Probably we need to clarify the meaning of Service Function and Serv= ice Instance in the spec? My understanding is that Service Instance is an i= nstantiation of a type of Service Function. So I see two cases here. One case is that one or multiple Service Functions= , such as FW (one type of Service Function) and LB (another type of Service= Function), can be embedded in the same network element. The other case is that multipl= e instances of the same Service Function, e.g. multiple instances of FW Ser= vice Function can be embedded in the same network element (different FW instances have di= fferent filtering rules). The document states that Multiple instances of th= e Service Function (eg. FW) can be enabled in the same administrative domain. My suggestion is to add c= larification that Multiple instances of the Service Function (eg. FW) can b= e enabled on the same network element too. What do you think? 2. Service Overlay AFAIK, there is a proposal for a new overlay mechanism. Shall we also explo= re and leverage existing overlay mechanism? I am thinking that we might als= o want to take current prevailing overlay mechanism into our consideration for service function ch= aining, such as VXLAN overlay which is supported in many virtual/physical s= witches and which has reserved fields that can be used to carry chain-ID and other meta= data. Jim: our charter is very clear on this point; we have a work item (with ass= ociated milestone) to produce a service-level data plane encapsulation that= : [1] indicates the sequence of service functions that make up the service = function chain, [2] specifies the service function path, and [3] communicat= es context information between nodes that implement service functions and s= ervice function chains. Further, our charter states that "the working group= will consider using an existing encapsulation (with extensions as appropri= ate) if a suitable candidate is found". 3. "Enterprise Data Center Service Chaining" section is TBD. Is there = a plan to compete this section? Jim: Thomas and I have been discussing how best to approach the subject of = use cases within the working group; we will be starting a new thread on the= mailing list shortly to detail our thoughts and to solicit input. Thanks, Cathy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Tuesday, January 21, 2014 11:14 AM To: sfc@ietf.org Subject: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 Thomas and I would like to remind you of the ongoing WG call for adoption o= f draft-quinn-sfc-problem-statement-02. We have received numerous positive = responses to our original email and plan to formally close out the call for= adoption this coming Friday (1/24/14). If folks have any additional commen= ts or concerns please voice them before this Friday. Jim & Thomas SFC chairs. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_A2C96F6779E6A041BC7023CC207FC99418F0A482SJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim and Paul,

 <= /p>

Thanks for your response!= Please see inline.

 <= /p>

Cathy

 <= /p>

From: Paul Qui= nn (paulq) [mailto:paulq@cisco.com]
Sent: Thursday, January 23, 2014 4:50 AM
To: Jim Guichard (jguichar); Cathy Zhang
Cc: sfc@ietf.org
Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-= 02

 

Hi,

 

 

 

On Jan 22, 2014, at 5:36 PM, Jim Guichard (jguichar)= <jguichar@cisco.com> wrote= :



Hi Cathy,

 

From: Cathy Zhang <Cathy.H.Zhang@huawei.com>
Date: Wednesday, January 22, 2014 3:12 PM
To: Jim Guichard <jguichar@= cisco.com>, "sfc@ietf.org&q= uot; <sfc@ietf.org>, Cathy Zhang = <Cathy.H.Zhang@huawei.com>
Subject: RE: WG adoption of draft-quinn-sfc-problem-statement-02

 

Hi Jim,

 

I have the following q= uestions/comments:

1.      Definition of Service= Function

It mentions that ̶= 0;Multiple instances of the Service Function can be enabled in the same adm= inistrative domain”. There is also the case that multiple instances o= f the Service Function can be instantiated on the same Service Node. For example on a FW appliance, we can instantiate

multiple FW service in= stances with each FW service instance having its own filtering rules. Could= we add this into the Definition?

 

Jim: as this question is directly relat= ed to the text of the draft I will let the document authors respond.

 

 

 

PQ>  The defintion for service function has = the following sentence: "One of multiple Service Functions can be embe= dded in the same network element."  I think that conveys what you= are asking for, it places no limitations of the type of function instantiated.   Do you agree?  (I will fix the typo (of= --> or) and remove the word network so the defn is more generic.)<= /o:p>

Cathy= > Probably we need to clarify the meaning of Service Function and Servic= e Instance in the spec? My understanding is that Service Instance is an ins= tantiation of a type of Service Function.

So I = see two cases here. One case is that one or multiple Service Functions, suc= h as FW (one type of Service Function) and LB (another type of Service Func= tion),  

can b= e embedded in the same network element. The other case is that multiple ins= tances of the same Service Function, e.g. multiple instances of FW Service = Function

can b= e embedded in the same network element (different FW instances have differe= nt filtering rules). The document states that Multiple instances of t= he Service Function (eg. FW)

can be = enabled in the same administrative domain. My suggestion is to a= dd clarification that Multiple instances of t= he Service Function (eg. FW) can be enabled on the same network = element too.  

What do= you think?



2.      Service Overlay

AFAIK, there is a prop= osal for a new overlay mechanism. Shall we also explore and leverage existi= ng overlay mechanism? I am thinking that we might also want to take current

prevailing overlay mec= hanism into our consideration for service function chaining, such as VXLAN = overlay which is supported in many virtual/physical switches and

which has reserved fie= lds that can be used to carry chain-ID and other metadata.

 

Jim: our charter is very clear on this = point; we have a work item (with associated milestone) to produce a service= -level data plane encapsulation that: [1] indicates the sequence of service functions that make up the service function chain, [2]= specifies the service function path, and [3] communicates context informat= ion between nodes that implement service functions and service function cha= ins. Further, our charter states that "the working group will consider using an existing encapsul= ation (with extensions as appropriate) if a suitable candidate is found&quo= t;. 

 =

3.      “Enterprise Dat= a Center Service Chaining” section is TBD. Is there a plan to compete= this section?

 

Jim: Thomas and I have been discussing how best to a= pproach the subject of use cases within the working group; we will be start= ing a new thread on the mailing list shortly to detail our thoughts and to = solicit input. 

 

Thanks,

Cathy

 <= /p>

 <= /p>

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, January 21, 2014 11:14 AM
To: sfc@ietf.org
Subject: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

 

Thomas and I would like to remind you o= f the ongoing WG call for adoption of draft-quinn-sfc-problem-statement-02.= We have received numerous positive responses to our original email and plan to formally close out the call for adoption this coming Fri= day (1/24/14). If folks have any additional comments or concerns please voi= ce them before this Friday.

 

Jim & Thomas

SFC chairs. 

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

 

--_000_A2C96F6779E6A041BC7023CC207FC99418F0A482SJCEML701CHMchi_-- From jmh@joelhalpern.com Thu Jan 23 13:16:40 2014 Return-Path: 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 7AC241A013B for ; Thu, 23 Jan 2014 13:16:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 9kQ6_H8O4Ri1 for ; Thu, 23 Jan 2014 13:16:35 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id CF5851A0197 for ; Thu, 23 Jan 2014 13:16:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 3EA074211A9; Thu, 23 Jan 2014 13:16:34 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (24-104-115-2-ip-static.hfc.comcastbusiness.net [24.104.115.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id F33414211A7; Thu, 23 Jan 2014 13:16:33 -0800 (PST) Message-ID: <52E186B0.5020809@joelhalpern.com> Date: Thu, 23 Jan 2014 16:16:32 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Cathy Zhang , "Paul Quinn (paulq)" , "Jim Guichard (jguichar)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 21:16:41 -0000 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. 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 From linda.dunbar@huawei.com Thu Jan 23 19:19:02 2014 Return-Path: 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 6CB141A02EB for ; Thu, 23 Jan 2014 19:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 VhOKJn3Ztakb for ; Thu, 23 Jan 2014 19:18:56 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 26BDF1A0141 for ; Thu, 23 Jan 2014 19:18:56 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAJ20415; Fri, 24 Jan 2014 03:18:54 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 03:18:34 +0000 Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 03:18:52 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml706-chm.china.huawei.com ([169.254.8.193]) with mapi id 14.03.0158.001; Thu, 23 Jan 2014 19:18:35 -0800 From: Linda Dunbar To: "Joel M. Halpern" , Cathy Zhang , "Paul Quinn (paulq)" , "Jim Guichard (jguichar)" Thread-Topic: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 Thread-Index: AQHPFtz0BBXmRpg9rk2thNSnYBnFRZqPsP9wgAG25QCAAUIjgP//+sSwgAC0XgD//907sA== Date: Fri, 24 Jan 2014 03:18:34 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C6F32D@dfweml701-chm.china.huawei.com> References: <52E186B0.5020809@joelhalpern.com> In-Reply-To: <52E186B0.5020809@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.156.39] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645C6F32Ddfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 03:19:02 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645C6F32Ddfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 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 appli= cation 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 ha= s its own Load Balancer among cluster of servers. A different situation is when load balancing is used internally to the serv= ice chaining to manage instances of the internal services (where cardinalit= y 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 collec= tion 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 mult= iplicity 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 https://www.ietf.org/mailman/listinfo/sfc --_000_4A95BA014132FF49AE685FAB4B9F17F645C6F32Ddfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
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
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 servic= e 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 i= s part of the service being delivered to the tenant, to help manage the ten= ants application traffic.
 
[Linda] do you mean when "Load Balancing&= quot; 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 cluste= r of servers.
 
 
A different situation is when load balancing is used internally to the= service chaining to manage instances of the internal services (where cardi= nality is invisible to the tenant / user).
 
In the former case, LB is a service.  And has to be able to direc= t traffic to the correct tenant application instance.
In the latter case, the load balancing may well be bundled in with a c= ollection of co-located service instances, with the whole looking like a se= rvice 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 remain= s to be seen.)
 
Yours,
Joel
_______________________________________________
sfc mailing list
 
 --_000_4A95BA014132FF49AE685FAB4B9F17F645C6F32Ddfweml701chmchi_-- From jmh@joelhalpern.com Thu Jan 23 19:35:47 2014 Return-Path: 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 D93531A0117 for ; Thu, 23 Jan 2014 19:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 HScL_OJbeDft for ; Thu, 23 Jan 2014 19:35:46 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id BF4491A0014 for ; Thu, 23 Jan 2014 19:35:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 198301C05A5; Thu, 23 Jan 2014 19:35:46 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (24-104-115-2-ip-static.hfc.comcastbusiness.net [24.104.115.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id D11EB1C0136; Thu, 23 Jan 2014 19:35:45 -0800 (PST) Message-ID: <52E1DF90.2070605@joelhalpern.com> Date: Thu, 23 Jan 2014 22:35:44 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Linda Dunbar , Cathy Zhang , "Paul Quinn (paulq)" , "Jim Guichard (jguichar)" References: <52E186B0.5020809@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C6F32D@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C6F32D@dfweml701-chm.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 03:35:48 -0000 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 > 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 > https://www.ietf.org/mailman/listinfo/sfc From Ron_Parker@affirmednetworks.com Fri Jan 24 06:21:01 2014 Return-Path: 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 9B16F1A04A7 for ; Fri, 24 Jan 2014 06:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 YDEP7ECrsW5u for ; Fri, 24 Jan 2014 06:21:00 -0800 (PST) Received: from hub021-ca-1.exch021.serverdata.net (hub021-ca-1.exch021.serverdata.net [64.78.22.168]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA781A04A6 for ; Fri, 24 Jan 2014 06:21:00 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-1.exch021.domain.local ([10.254.4.30]) with mapi id 14.03.0158.001; Fri, 24 Jan 2014 06:20:57 -0800 From: Ron Parker To: "Joel M. Halpern" , Linda Dunbar , Cathy Zhang , "Paul Quinn (paulq)" , "Jim Guichard (jguichar)" Thread-Topic: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 Thread-Index: AQHPFtz0BBXmRpg9rk2thNSnYBnFRZqPsP9wgAG25QCAAUIjgP//+sSwgAC0XgD//907sIAAjLcAgAArhjA= Date: Fri, 24 Jan 2014 14:20:57 +0000 Message-ID: References: <52E186B0.5020809@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C6F32D@dfweml701-chm.china.huawei.com> <52E1DF90.2070605@joelhalpern.com> In-Reply-To: <52E1DF90.2070605@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 14:21:01 -0000 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 balanci= ng * explicitly addressed service (e.g., DB server) with internal load balanci= ng * explicitly addressed service (e.g., Web HTTP server) requiring external l= oad 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 wo= uld typically present a single locator (i.e., IP address) to the outside wo= rld and manage redirection internally to the clustered application. =20 I think the last bullet, external load balancing for an explicitly addresse= d service (e.g., Web HTTP server) lends itself to load balancing as an expl= icit service function from an SFC perspective. That is, the service funct= ion 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 sti= ll firewall and not load balancer. However, I do think that SFC should ex= plicitly embrace the concept of a "load-balanced service function". I tri= ed to address this in http://datatracker.ietf.org/doc/draft-parker-sfc-chai= n-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 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 th= e 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 > 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=20 > service is for. Using load balancing as an example, there are two differ= ent cases. > One case, common in a data center, will bw where load balncing is=20 > part of the service being delivered to the tenant, to help manage the=20 > tenants application traffic. > [Linda] do you mean when "Load Balancing" among cluster of servers for=20 > one tenant application being offered as a service? > Isn't this kind of "load balancing" application specific? Like Oracle=20 > DB has its own Load Balancer among cluster of servers. > A different situation is when load balancing is used internally to the=20 > service chaining to manage instances of the internal services (where=20 > cardinality is invisible to the tenant / user). > In the former case, LB is a service. And has to be able to direct=20 > traffic to the correct tenant application instance. > In the latter case, the load balancing may well be bundled in with a=20 > collection of co-located service instances, with the whole looking=20 > like a service instance to service chaining and the end user. (There=20 > appear to be a multiplicity of ways to deliver this behavior. How=20 > much we need to specify in the architecture remains to be seen.)=20 > Yours, Joel _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From christian.jacquenet@orange.com Fri Jan 24 06:24:37 2014 Return-Path: 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 2AB0F1A0254 for ; Fri, 24 Jan 2014 06:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 OSbtAxtq4ChO for ; Fri, 24 Jan 2014 06:24:34 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1B61A00F2 for ; Fri, 24 Jan 2014 06:24:34 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 6ACD718DE8F for ; Fri, 24 Jan 2014 15:24:32 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 4F216238061 for ; Fri, 24 Jan 2014 15:24:32 +0100 (CET) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Fri, 24 Jan 2014 15:24:32 +0100 From: To: "sfc@ietf.org" Date: Fri, 24 Jan 2014 15:24:31 +0100 Thread-Topic: IPR check for draft-quinn-sfc-problem-statement Thread-Index: AQHPFtu2NSEh36Zfh0G0Wjova3ew6JqUAFUA///xqlA= Message-ID: <9553_1390573472_52E277A0_9553_209_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15EFAD4835C@PUEXCB1C.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_983A1D8DA0DA5F4EB747BF34CBEE5CD15EFAD4835CPUEXCB1Cnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 14:24:37 -0000 --_000_983A1D8DA0DA5F4EB747BF34CBEE5CD15EFAD4835CPUEXCB1Cnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, I'm not aware of any IPR that applies to the problem statement draft. Cheers, Christian. From: Jim Guichard > Date: Tuesday, January 21, 2014 at 2:05 PM To: "sfc@ietf.org" > Cc: Thomas Narten > Subject: IPR check for draft-quinn-sfc-problem-statement This email serves as a poll for knowledge of any IPR that applies to draft = [1], to ensure that IPR has been disclosed in compliance with IETF IPR rule= s (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email whether or not you are aware of any relevant IPR. The draft will no= t be adopted until a response has been received from each author and major = contributor. If you are on the SFC WG mailing list but are not listed as an author or co= ntributor, then please explicitly respond only if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. Thank you, Jim & Thomas SFC chairs [1] http://tools.ietf.org/id/draft-quinn-sfc-problem-statement-02.txt ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_983A1D8DA0DA5F4EB747BF34CBEE5CD15EFAD4835CPUEXCB1Cnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

I’m not aware of any IPR that applies to the problem statement dr= aft.

 

 = ;

Christian.

 

From: Jim Guichard <jguichar@cisco.com>
Date: <= /b>Tuesday, January 21, 2014 at 2:05 PM
To: "sfc@ietf.org" <sfc@ietf.org>
Cc: Thomas Narten <narten@us.ibm.com>
Subject: IPR check for = draft-quinn-sfc-problem-statement

 

=

This email serves as a poll for knowledge of any IPR that applies to draft= [1], to ensure that IPR has been disclosed in compliance with IETF IPR rul= es (see RFCs 3979, 4879, 3669 and 5378 for more details). <= /span>

 

If you are listed as a document author or contributor p= lease respond to this email whether or not you are aware of any relevant IP= R. The draft will not be adopted until a response has been received from ea= ch author and major contributor. 

 =

If yo= u are on the SFC WG mailing list but are not listed as an author or contrib= utor, then please explicitly respond only if you are aware of any IPR that = has not yet been disclosed in conformance with IETF rules. =

 

Thank you,

__________________________________=
___________________________________________________________________________=
____________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
= --_000_983A1D8DA0DA5F4EB747BF34CBEE5CD15EFAD4835CPUEXCB1Cnante_-- From mikebianc@aol.com Fri Jan 24 07:22:42 2014 Return-Path: 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 637DD1A00BE for ; Fri, 24 Jan 2014 07:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.065 X-Spam-Level: X-Spam-Status: No, score=0.065 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 pstYknUmNNEq for ; Fri, 24 Jan 2014 07:22:39 -0800 (PST) Received: from omr-m10.mx.aol.com (omr-m10.mx.aol.com [64.12.143.86]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEF41A0025 for ; Fri, 24 Jan 2014 07:22:38 -0800 (PST) Received: from mtaout-mae01.mx.aol.com (mtaout-mae01.mx.aol.com [172.26.254.141]) by omr-m10.mx.aol.com (Outbound Mail Relay) with ESMTP id C803E701EBCA5; Fri, 24 Jan 2014 10:22:37 -0500 (EST) Received: from mgs-aaa01.mail.aol.com (mgs-aaa01.mail.aol.com [149.174.106.43]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-mae01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 96EEF38000086; Fri, 24 Jan 2014 10:22:37 -0500 (EST) Date: Fri, 24 Jan 2014 10:22:37 -0500 From: "mikebianc@aol.com" To: Ron_Parker@affirmednetworks.com, jmh@joelhalpern.com, linda.dunbar@huawei.com, Cathy.H.Zhang@huawei.com, paulq@cisco.com, jguichar@cisco.com Message-ID: <184198357.1683.1390576957523.JavaMail.tomcat@mgs-aaa01.mail.aol.com> In-Reply-To: References: <52E186B0.5020809@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C6F32D@dfweml701-chm.china.huawei.com> <52E1DF90.2070605@joelhalpern.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1682_105551597.1390576957522" X-Originating-IP: 10.181.180.127, 205.188.60.49 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1390576957; bh=TLoYOb2Q82bo1X5seTlm1XNVTTmJDj4NUmTbTX+HmFE=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=RnGPAe31Eg4Z9xp4ApWVrr9nQuU5XKch77IN4HsRePeA91sDwUlgWFF2CmIJ8QEkP 4kbunirDes6cu0Z1GZRpucBoEGXgzR192jzBIPp8fuYifxXg9/VcvxPNAzBUc9a99u tZ4iAi21Qdf4fDQ1i/TiSzZNFnC/QriQnisPxQCY= x-aol-sid: 3039ac1afe8d52e2853d75b6 X-AOL-IP: 149.174.106.43 Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 15:22:42 -0000 ------=_Part_1682_105551597.1390576957522 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To avoid further confusion, should we refer to the selection of a service i= nstance as "service distribution" instead of "load balancing" to clearly di= fferentiate this from the "load balancer" service? From: Ron_Parker@affirmednetworks.com To: Joel M. Halpern,Linda Dunbar,Cathy Zhang,Paul Quinn (paulq),Jim Guichard (jguichar) cc: sfc@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. = =C2=A0 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 balanci= ng * explicitly addressed service (e.g., DB server) with internal load balanci= ng * explicitly addressed service (e.g., Web HTTP server) requiring external l= oad balancing >From an SFC perspective, I think we can ignore the cases where the mid-box = or explicit application is internally load balanced. =C2=A0 Such applicatio= ns would typically present a single locator (i.e., IP address) to the outsi= de world and manage redirection internally to the clustered application. = =C2=A0=C2=A0=20 I think the last bullet, external load balancing for an explicitly addresse= d service (e.g., Web HTTP server) lends itself to load balancing as an expl= icit service function from an SFC perspective. =C2=A0 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. =C2=A0 From an SFC perspective, my vie= w is that the service function that appears in the service function chain i= s still firewall and not load balancer. =C2=A0 However, I do think that SFC= should explicitly embrace the concept of a "load-balanced service function= ". =C2=A0 I tried to address this in http://datatracker.ietf.org/doc/draft-= parker-sfc-chain-to-path/ and would appreciate any feedback. Thanks. =C2=A0 Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. HalpernSent: T= hursday, January 23, 2014 10:36 PMTo: Linda Dunbar; Cathy Zhang; Paul Quinn= (paulq); Jim Guichard (jguichar)Cc: sfc@ietf.orgSubject: Re: [sfc] WG adop= tion of draft-quinn-sfc-problem-statement-02For apps that have their own in= ternal load balancer, I agree that there is no point in the tenant using th= e 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 balancin= g as a service for those tenants who want it.My only point was to distingui= sh load balancing as a service selected by the customer from load balancing= used by the oeprator internall;y to deliver some other service.Yours,JoelO= n 1/23/14 10:18 PM, Linda Dunbar wrote:> Joel,> Questions inserted below:> = -----Original Message-----> From: sfc [mailto:sfc-bounces@ietf.org] On Beha= lf 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> Subje= ct: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02> In looki= ng 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 cas= e, common in a data center, will bw where load balncing is > part of the s= ervice being delivered to the tenant, to help manage the > tenants applicat= ion traffic.> [Linda] do you mean when "Load Balancing" among cluster of se= rvers 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 loa= d balancing is used internally to the > service chaining to manage instance= s 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 direc= t > traffic to the correct tenant application instance.> In the latter case= , the load balancing may well be bundled in with a > collection of co-locat= ed service instances, with the whole looking > like a service instance to s= ervice 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 archit= ecture remains to be seen.) > Yours, Joel _________________________________= ______________> sfc mailing list> sfc@ietf.org > https= ://www.ietf.org/mailman/listinfo/sfc_______________________________________= ________sfc mailing listsfc@ietf.orghttps://www.ietf.org/mailman/listinfo/s= fc_______________________________________________sfc mailing listsfc@ietf.o= rghttps://www.ietf.org/mailman/listinfo/sfc ------=_Part_1682_105551597.1390576957522 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
To avoid furthe= r confusion, should we refer to the selection of a service instance as "ser= vice distribution" instead of "load balancing" to clearly differentiate thi= s from the "load balancer" service?





From: Ron_Parker@a= ffirmednetworks.com<Ron_Parker@affirmednetworks.com>
To: Jo= el M. Halpern<jmh@joelhalpern.com>,Linda Dunbar<linda.dunbar@huawe= i.com>,Cathy Zhang<Cathy.H.Zhang@huawei.com>,Paul Quinn (paulq)<paulq@cisco.com>,Jim Guichard (jguichar)<jguichar@c= isco.com>
cc: sfc@ietf.org<sfc@ietf.org>
Sent: Friday, January 24, 2014
Subject: Re: [sfc] WG adoption of draft= -quinn-sfc-problem-statement-02

Hi, Joel.

I th= ink 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 balan= cing
* explicitly addressed service (e.g., DB server) with internal load= balancing
* explicitly addressed service (e.g., Web HTTP server) requir= ing external load balancing

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

I think the last bull= et, 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 servi= ce function chain is "load balancer".

The second bullet, external lo= ad balancing for mid-box service function (e.g., firewall), is slightly tri= ckier.   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 t= his 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: Thursda= y, January 23, 2014 10:36 PM
To: Linda Dunbar; Cathy Zhang; P= aul Quinn (paulq); Jim Guichard (jguichar)
Cc: sfc@ietf.orgSubject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-stat= ement-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 h= ave 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 selec= ted 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 w= rote:
> Joel,
> Questions inserted below:=
> -----Original Message-----
> From: sfc= [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern
&= gt; Sent: Thursday, January 23, 2014 3:17 PM
> To: Cathy Z= hang; Paul Quinn (paulq); Jim Guichard (jguichar)
> Cc: sf= c@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. Usin= g load balancing as an example, there are two different cases.
> One case, common in a data center, will bw where load balncing is <= br class=3D"">> part of the service being delivered to the tenant, to he= lp manage the
> tenants application traffic.
> [Linda] do you mean when "Load Balancing" among cluster of servers f= or
> 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 balancin= g is used internally to the
> service chaining to manage = instances of the internal services (where
> cardinality i= s invisible to the tenant / user).
> In the former case, L= B is a service. And has to be able to direct
> traffic t= o 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 arch= itecture remains to be seen.)
> Yours, Joel _____________= __________________________________
> sfc mailing list
> sfc@ietf.org <mailto:sfc@ietf.org>
> = https://www.ietf.org/mailman/listinfo/sfc
___________________= ____________________________
sfc mailing list
s= fc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc
_______________________________________________
sfc ma= iling list
sfc@ietf.org
https://www.ietf.org/ma= ilman/listinfo/sfc
------=_Part_1682_105551597.1390576957522-- From prvs=094dca163=Nicolas.BOUTHORS@qosmos.com Fri Jan 24 07:32:01 2014 Return-Path: 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 585BD1A011E for ; Fri, 24 Jan 2014 07:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 lvE3xMQdIDlf for ; Fri, 24 Jan 2014 07:31:59 -0800 (PST) Received: from smtp-ft4.fr.colt.net (smtp-ft4.fr.colt.net [213.41.78.208]) by ietfa.amsl.com (Postfix) with ESMTP id 92DE61A0031 for ; Fri, 24 Jan 2014 07:31:59 -0800 (PST) Received: from smtp-ex6.fr.colt.net (smtp-ex6.fr.colt.net [213.41.78.122]) by smtp-ft4.fr.colt.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s0OFVvRw017265 for ; Fri, 24 Jan 2014 16:31:57 +0100 Received: from mx1.qosmos.fr ([195.68.92.43] helo=mx3.qosmos.com) by smtp-ex6.fr.colt.net with esmtp (Exim) (envelope-from ) id 1W6ijd-0005SR-24 for ; Fri, 24 Jan 2014 16:31:57 +0100 X-IronPort-AV: E=Sophos;i="4.95,713,1384297200"; d="scan'208,217";a="812169" Received: from unknown (HELO mailbox.jungle.qosmos.com) ([10.12.1.3]) by mx3.qosmos.com with ESMTP; 24 Jan 2014 16:31:54 +0100 Received: from LILAS.jungle.qosmos.com ([fe80::5524:2c18:b2c3:74d4]) by CAROUBIER.jungle.qosmos.com ([169.254.1.72]) with mapi id 14.01.0438.000; Fri, 24 Jan 2014 16:31:53 +0100 From: Nicolas BOUTHORS To: "sfc@ietf.org" Thread-Topic: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 Thread-Index: Ac8ZGAV658yRANKvS3CT2KvxYUAHhQ== Date: Fri, 24 Jan 2014 15:31:52 +0000 Message-ID: <76B41B8FACE1514795D30EC137FF391D3CFD98@LILAS.jungle.qosmos.com> Accept-Language: en-US, fr-FR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.0.22] Content-Type: multipart/alternative; boundary="_000_76B41B8FACE1514795D30EC137FF391D3CFD98LILASjungleqosmos_" MIME-Version: 1.0 X-ACL-Warn: 1/1 recipients OK. 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 15:32:01 -0000 --_000_76B41B8FACE1514795D30EC137FF391D3CFD98LILASjungleqosmos_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I recently started to follow this group, so my question has possibly been a= ddressed before. The document mentions multi tenancy as a source of topology viability issu= es, and refers to the NVO3 working group mentionning that it does not address multi-tenancy. As multi-tenancy is often tied to overlay based solutions, it could be usef= ull to note somewhere that this could have to compose with the notion of Service Overlay described in 3.1. This would be the case for example in Gi networks supporting MVNO traffic. Nicolas --_000_76B41B8FACE1514795D30EC137FF391D3CFD98LILASjungleqosmos_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I recently started to follow this group, so my question has possibly= been addressed before.

The document mentions multi tenancy  as a source of topology viab= ility issues, and refers to 
the  NV= O3 working group mentionning that it does not address multi-tenancy.=

As multi-tenancy = is often tied to overlay based solutions, it could be usefull to note somew= here that this
could have to com= pose with the notion of Service Overlay described in 3.1.

This would be the= case for example in Gi networks supporting MVNO traffic.


Nicolas
--_000_76B41B8FACE1514795D30EC137FF391D3CFD98LILASjungleqosmos_-- From jmoisand@juniper.net Fri Jan 24 07:33:56 2014 Return-Path: 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 ; 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 ; 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 ; 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 To: "mikebianc@aol.com" , "Ron_Parker@affirmednetworks.com" , "jmh@joelhalpern.com" , "linda.dunbar@huawei.com" , "Cathy.H.Zhang@huawei.com" , "paulq@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: References: <52E186B0.5020809@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C6F32D@dfweml701-chm.china.huawei.com> <52E1DF90.2070605@joelhalpern.com> <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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 15:33:56 -0000 --_000_aca97274f9c84c07bbb81da119298b93CO2PR05MB716namprd05pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3JlYXQgaWRlYSwgTWlrZS4NCg0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIG1pa2ViaWFuY0Bhb2wuY29tDQpTZW50OiBGcmlkYXksIEphbnVh cnkgMjQsIDIwMTQgMTA6MjMgQU0NClRvOiBSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29t OyBqbWhAam9lbGhhbHBlcm4uY29tOyBsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbTsgQ2F0aHkuSC5a aGFuZ0BodWF3ZWkuY29tOyBwYXVscUBjaXNjby5jb207IGpndWljaGFyQGNpc2NvLmNvbQ0KQ2M6 IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzZmNdIFdHIGFkb3B0aW9uIG9mIGRyYWZ0LXF1 aW5uLXNmYy1wcm9ibGVtLXN0YXRlbWVudC0wMg0KDQpUbyBhdm9pZCBmdXJ0aGVyIGNvbmZ1c2lv biwgc2hvdWxkIHdlIHJlZmVyIHRvIHRoZSBzZWxlY3Rpb24gb2YgYSBzZXJ2aWNlIGluc3RhbmNl IGFzICJzZXJ2aWNlIGRpc3RyaWJ1dGlvbiIgaW5zdGVhZCBvZiAibG9hZCBiYWxhbmNpbmciIHRv IGNsZWFybHkgZGlmZmVyZW50aWF0ZSB0aGlzIGZyb20gdGhlICJsb2FkIGJhbGFuY2VyIiBzZXJ2 aWNlPw0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IFJvbl9Q YXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb208Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNv bTxtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbSUzY1Jvbl9QYXJrZXJAYWZm aXJtZWRuZXR3b3Jrcy5jb20+Pg0KVG86IEpvZWwgTS4gSGFscGVybjxqbWhAam9lbGhhbHBlcm4u Y29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4sTGluZGEgRHVuYmFyPGxpbmRhLmR1bmJh ckBodWF3ZWkuY29tPG1haWx0bzpsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbT4+LENhdGh5IFpoYW5n PENhdGh5LkguWmhhbmdAaHVhd2VpLmNvbTxtYWlsdG86Q2F0aHkuSC5aaGFuZ0BodWF3ZWkuY29t Pj4sUGF1bCBRdWlubiAocGF1bHEpPHBhdWxxQGNpc2NvLmNvbTxtYWlsdG86cGF1bHFAY2lzY28u Y29tPj4sSmltIEd1aWNoYXJkIChqZ3VpY2hhcik8amd1aWNoYXJAY2lzY28uY29tPG1haWx0bzpq Z3VpY2hhckBjaXNjby5jb20+Pg0KY2M6IHNmY0BpZXRmLm9yZzxzZmNAaWV0Zi5vcmc8bWFpbHRv OnNmY0BpZXRmLm9yZyUzY3NmY0BpZXRmLm9yZz4+DQpTZW50OiBGcmlkYXksIEphbnVhcnkgMjQs IDIwMTQNClN1YmplY3Q6IFJlOiBbc2ZjXSBXRyBhZG9wdGlvbiBvZiBkcmFmdC1xdWlubi1zZmMt cHJvYmxlbS1zdGF0ZW1lbnQtMDINCg0KSGksIEpvZWwuDQoNCkkgdGhpbmsgeW91IHJhaXNlIGFu IGV4Y2VsbGVudCBwb2ludCBvbiB0aGUgYW1iaWd1aXR5IG9mIGxvYWQgYmFsYW5jaW5nLiAgIEkg d291bGQgcHJvcG9zZSB0aGF0IHRoZXJlIGFyZSBtb3JlIHRoYW4gMiBjYXNlcyBvZiBsb2FkIGJh bGFuY2luZzoNCg0KKiBtaWQtYm94IHNlcnZpY2UgZnVuY3Rpb24gKGUuZy4sIGZpcmV3YWxsKSB3 aXRoIGludGVybmFsIGxvYWQgYmFsYW5jaW5nDQoqIG1pZC1ib3ggc2VydmljZSBmdW5jdGlvbiAo ZS5nLiwgZmlyZXdhbGwpIHJlcXVpcmluZyBleHRlcm5hbCBsb2FkIGJhbGFuY2luZw0KKiBleHBs aWNpdGx5IGFkZHJlc3NlZCBzZXJ2aWNlIChlLmcuLCBEQiBzZXJ2ZXIpIHdpdGggaW50ZXJuYWwg bG9hZCBiYWxhbmNpbmcNCiogZXhwbGljaXRseSBhZGRyZXNzZWQgc2VydmljZSAoZS5nLiwgV2Vi IEhUVFAgc2VydmVyKSByZXF1aXJpbmcgZXh0ZXJuYWwgbG9hZCBiYWxhbmNpbmcNCg0KRnJvbSBh biBTRkMgcGVyc3BlY3RpdmUsIEkgdGhpbmsgd2UgY2FuIGlnbm9yZSB0aGUgY2FzZXMgd2hlcmUg dGhlIG1pZC1ib3ggb3IgZXhwbGljaXQgYXBwbGljYXRpb24gaXMgaW50ZXJuYWxseSBsb2FkIGJh bGFuY2VkLiAgIFN1Y2ggYXBwbGljYXRpb25zIHdvdWxkIHR5cGljYWxseSBwcmVzZW50IGEgc2lu Z2xlIGxvY2F0b3IgKGkuZS4sIElQIGFkZHJlc3MpIHRvIHRoZSBvdXRzaWRlIHdvcmxkIGFuZCBt YW5hZ2UgcmVkaXJlY3Rpb24gaW50ZXJuYWxseSB0byB0aGUgY2x1c3RlcmVkIGFwcGxpY2F0aW9u Lg0KDQpJIHRoaW5rIHRoZSBsYXN0IGJ1bGxldCwgZXh0ZXJuYWwgbG9hZCBiYWxhbmNpbmcgZm9y IGFuIGV4cGxpY2l0bHkgYWRkcmVzc2VkIHNlcnZpY2UgKGUuZy4sIFdlYiBIVFRQIHNlcnZlcikg bGVuZHMgaXRzZWxmIHRvIGxvYWQgYmFsYW5jaW5nIGFzIGFuIGV4cGxpY2l0IHNlcnZpY2UgZnVu Y3Rpb24gZnJvbSBhbiBTRkMgcGVyc3BlY3RpdmUuICAgVGhhdCBpcywgdGhlIHNlcnZpY2UgZnVu Y3Rpb24gaW4gdGhlIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW4gaXMgImxvYWQgYmFsYW5jZXIiLg0K DQpUaGUgc2Vjb25kIGJ1bGxldCwgZXh0ZXJuYWwgbG9hZCBiYWxhbmNpbmcgZm9yIG1pZC1ib3gg c2VydmljZSBmdW5jdGlvbiAoZS5nLiwgZmlyZXdhbGwpLCBpcyBzbGlnaHRseSB0cmlja2llci4g ICBGcm9tIGFuIFNGQyBwZXJzcGVjdGl2ZSwgbXkgdmlldyBpcyB0aGF0IHRoZSBzZXJ2aWNlIGZ1 bmN0aW9uIHRoYXQgYXBwZWFycyBpbiB0aGUgc2VydmljZSBmdW5jdGlvbiBjaGFpbiBpcyBzdGls bCBmaXJld2FsbCBhbmQgbm90IGxvYWQgYmFsYW5jZXIuICAgSG93ZXZlciwgSSBkbyB0aGluayB0 aGF0IFNGQyBzaG91bGQgZXhwbGljaXRseSBlbWJyYWNlIHRoZSBjb25jZXB0IG9mIGEgImxvYWQt YmFsYW5jZWQgc2VydmljZSBmdW5jdGlvbiIuICAgSSB0cmllZCB0byBhZGRyZXNzIHRoaXMgaW4g aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wYXJrZXItc2ZjLWNoYWluLXRv LXBhdGgvIGFuZCB3b3VsZCBhcHByZWNpYXRlIGFueSBmZWVkYmFjay4NCg0KVGhhbmtzLg0KDQog IFJvbg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCg0KRnJvbTogc2ZjIFttYWls dG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2VsIE0uIEhhbHBlcm4NClNl bnQ6IFRodXJzZGF5LCBKYW51YXJ5IDIzLCAyMDE0IDEwOjM2IFBNDQpUbzogTGluZGEgRHVuYmFy OyBDYXRoeSBaaGFuZzsgUGF1bCBRdWlubiAocGF1bHEpOyBKaW0gR3VpY2hhcmQgKGpndWljaGFy KQ0KQ2M6IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtz ZmNdIFdHIGFkb3B0aW9uIG9mIGRyYWZ0LXF1aW5uLXNmYy1wcm9ibGVtLXN0YXRlbWVudC0wMg0K DQpGb3IgYXBwcyB0aGF0IGhhdmUgdGhlaXIgb3duIGludGVybmFsIGxvYWQgYmFsYW5jZXIsIEkg YWdyZWUgdGhhdCB0aGVyZSBpcyBubyBwb2ludCBpbiB0aGUgdGVuYW50IHVzaW5nIHRoZSBkYXRh IGNlbnRlciBvZmZlcmVkIGxvYWQgYmFsYW5jZXIgc2VydmljZS4NCkJ1dCBtYW55IGFwcHMgZG8g bm90IGhhdmUgdGhlaXIgb3duIGN1c3RvbSBsb2FkIGJhbGFuY2VyLiBTbyBhIGRhdGEgY2VudGVy IG1pZ2h0IHdlbGwgb2ZmZXIgbG9hZCBiYWxhbmNpbmcgYXMgYSBzZXJ2aWNlIGZvciB0aG9zZSB0 ZW5hbnRzIHdobyB3YW50IGl0Lg0KDQpNeSBvbmx5IHBvaW50IHdhcyB0byBkaXN0aW5ndWlzaCBs b2FkIGJhbGFuY2luZyBhcyBhIHNlcnZpY2Ugc2VsZWN0ZWQgYnkgdGhlIGN1c3RvbWVyIGZyb20g bG9hZCBiYWxhbmNpbmcgdXNlZCBieSB0aGUgb2VwcmF0b3IgaW50ZXJuYWxsO3kgdG8gZGVsaXZl ciBzb21lIG90aGVyIHNlcnZpY2UuDQoNCllvdXJzLA0KSm9lbA0KDQpPbiAxLzIzLzE0IDEwOjE4 IFBNLCBMaW5kYSBEdW5iYXIgd3JvdGU6DQo+IEpvZWwsDQo+IFF1ZXN0aW9ucyBpbnNlcnRlZCBi ZWxvdzoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc2ZjIFttYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2VsIE0uIEhhbHBlcm4NCj4gU2Vu dDogVGh1cnNkYXksIEphbnVhcnkgMjMsIDIwMTQgMzoxNyBQTQ0KPiBUbzogQ2F0aHkgWmhhbmc7 IFBhdWwgUXVpbm4gKHBhdWxxKTsgSmltIEd1aWNoYXJkIChqZ3VpY2hhcikNCj4gQ2M6IHNmY0Bp ZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW3NmY10gV0cgYWRv cHRpb24gb2YgZHJhZnQtcXVpbm4tc2ZjLXByb2JsZW0tc3RhdGVtZW50LTAyDQo+IEluIGxvb2tp bmcgYXQgdGhlIHNlcnZpY2VzLCB3ZSBuZWVkIHRvIGJlIGNhcmVmdWwgYWJvdXQgd2hvIHRoZQ0K PiBzZXJ2aWNlIGlzIGZvci4gVXNpbmcgbG9hZCBiYWxhbmNpbmcgYXMgYW4gZXhhbXBsZSwgdGhl cmUgYXJlIHR3byBkaWZmZXJlbnQgY2FzZXMuDQo+IE9uZSBjYXNlLCBjb21tb24gaW4gYSBkYXRh IGNlbnRlciwgd2lsbCBidyB3aGVyZSBsb2FkIGJhbG5jaW5nIGlzDQo+IHBhcnQgb2YgdGhlIHNl cnZpY2UgYmVpbmcgZGVsaXZlcmVkIHRvIHRoZSB0ZW5hbnQsIHRvIGhlbHAgbWFuYWdlIHRoZQ0K PiB0ZW5hbnRzIGFwcGxpY2F0aW9uIHRyYWZmaWMuDQo+IFtMaW5kYV0gZG8geW91IG1lYW4gd2hl biAiTG9hZCBCYWxhbmNpbmciIGFtb25nIGNsdXN0ZXIgb2Ygc2VydmVycyBmb3INCj4gb25lIHRl bmFudCBhcHBsaWNhdGlvbiBiZWluZyBvZmZlcmVkIGFzIGEgc2VydmljZT8NCj4gSXNuJ3QgdGhp cyBraW5kIG9mICJsb2FkIGJhbGFuY2luZyIgYXBwbGljYXRpb24gc3BlY2lmaWM/IExpa2UgT3Jh Y2xlDQo+IERCIGhhcyBpdHMgb3duIExvYWQgQmFsYW5jZXIgYW1vbmcgY2x1c3RlciBvZiBzZXJ2 ZXJzLg0KPiBBIGRpZmZlcmVudCBzaXR1YXRpb24gaXMgd2hlbiBsb2FkIGJhbGFuY2luZyBpcyB1 c2VkIGludGVybmFsbHkgdG8gdGhlDQo+IHNlcnZpY2UgY2hhaW5pbmcgdG8gbWFuYWdlIGluc3Rh bmNlcyBvZiB0aGUgaW50ZXJuYWwgc2VydmljZXMgKHdoZXJlDQo+IGNhcmRpbmFsaXR5IGlzIGlu dmlzaWJsZSB0byB0aGUgdGVuYW50IC8gdXNlcikuDQo+IEluIHRoZSBmb3JtZXIgY2FzZSwgTEIg aXMgYSBzZXJ2aWNlLiBBbmQgaGFzIHRvIGJlIGFibGUgdG8gZGlyZWN0DQo+IHRyYWZmaWMgdG8g dGhlIGNvcnJlY3QgdGVuYW50IGFwcGxpY2F0aW9uIGluc3RhbmNlLg0KPiBJbiB0aGUgbGF0dGVy IGNhc2UsIHRoZSBsb2FkIGJhbGFuY2luZyBtYXkgd2VsbCBiZSBidW5kbGVkIGluIHdpdGggYQ0K PiBjb2xsZWN0aW9uIG9mIGNvLWxvY2F0ZWQgc2VydmljZSBpbnN0YW5jZXMsIHdpdGggdGhlIHdo b2xlIGxvb2tpbmcNCj4gbGlrZSBhIHNlcnZpY2UgaW5zdGFuY2UgdG8gc2VydmljZSBjaGFpbmlu ZyBhbmQgdGhlIGVuZCB1c2VyLiAoVGhlcmUNCj4gYXBwZWFyIHRvIGJlIGEgbXVsdGlwbGljaXR5 IG9mIHdheXMgdG8gZGVsaXZlciB0aGlzIGJlaGF2aW9yLiBIb3cNCj4gbXVjaCB3ZSBuZWVkIHRv IHNwZWNpZnkgaW4gdGhlIGFyY2hpdGVjdHVyZSByZW1haW5zIHRvIGJlIHNlZW4uKQ0KPiBZb3Vy cywgSm9lbCBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBzZmMgbWFpbGluZyBsaXN0DQo+IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiA8 bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGll dGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYw0K --_000_aca97274f9c84c07bbb81da119298b93CO2PR05MB716namprd05pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4 LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29u VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5HcmVhdCBpZGVhLCBNaWtlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5taWtlYmlhbmNAYW9sLmNvbTxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEph bnVhcnkgMjQsIDIwMTQgMTA6MjMgQU08YnI+DQo8Yj5Ubzo8L2I+IFJvbl9QYXJrZXJAYWZmaXJt ZWRuZXR3b3Jrcy5jb207IGptaEBqb2VsaGFscGVybi5jb207IGxpbmRhLmR1bmJhckBodWF3ZWku Y29tOyBDYXRoeS5ILlpoYW5nQGh1YXdlaS5jb207IHBhdWxxQGNpc2NvLmNvbTsgamd1aWNoYXJA Y2lzY28uY29tPGJyPg0KPGI+Q2M6PC9iPiBzZmNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtzZmNdIFdHIGFkb3B0aW9uIG9mIGRyYWZ0LXF1aW5uLXNmYy1wcm9ibGVtLXN0YXRl bWVudC0wMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UbyBh dm9pZCBmdXJ0aGVyIGNvbmZ1c2lvbiwgc2hvdWxkIHdlIHJlZmVyIHRvIHRoZSBzZWxlY3Rpb24g b2YgYSBzZXJ2aWNlIGluc3RhbmNlIGFzICZxdW90O3NlcnZpY2UgZGlzdHJpYnV0aW9uJnF1b3Q7 IGluc3RlYWQgb2YgJnF1b3Q7bG9hZCBiYWxhbmNpbmcmcXVvdDsgdG8gY2xlYXJseQ0KIGRpZmZl cmVudGlhdGUgdGhpcyBmcm9tIHRoZSAmcXVvdDtsb2FkIGJhbGFuY2VyJnF1b3Q7IHNlcnZpY2U/ PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibWFy Z2luLWJvdHRvbTo2Ljc1cHQ7dGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjEiIHdpZHRo PSIxMDAlIiBub3NoYWRlPSIiIHN0eWxlPSJjb2xvcjojOTk5OTk5IiBhbGlnbj0iY2VudGVyIj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ni43NXB0 Ij48Yj5Gcm9tOiA8L2I+PGEgaHJlZj0ibWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jr cy5jb20lM2NSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tIj5Sb25fUGFya2VyQGFmZmly bWVkbmV0d29ya3MuY29tJmx0O1Jvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb208L2E+Jmd0 Ozxicj4NCjxiPlRvOiA8L2I+Sm9lbCBNLiBIYWxwZXJuJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhA am9lbGhhbHBlcm4uY29tIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDssTGluZGEgRHVuYmFy Jmx0OzxhIGhyZWY9Im1haWx0bzpsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbSI+bGluZGEuZHVuYmFy QGh1YXdlaS5jb208L2E+Jmd0OyxDYXRoeSBaaGFuZyZsdDs8YSBocmVmPSJtYWlsdG86Q2F0aHku SC5aaGFuZ0BodWF3ZWkuY29tIj5DYXRoeS5ILlpoYW5nQGh1YXdlaS5jb208L2E+Jmd0OyxQYXVs DQogUXVpbm4gKHBhdWxxKSZsdDs8YSBocmVmPSJtYWlsdG86cGF1bHFAY2lzY28uY29tIj5wYXVs cUBjaXNjby5jb208L2E+Jmd0OyxKaW0gR3VpY2hhcmQgKGpndWljaGFyKSZsdDs8YSBocmVmPSJt YWlsdG86amd1aWNoYXJAY2lzY28uY29tIj5qZ3VpY2hhckBjaXNjby5jb208L2E+Jmd0Ozxicj4N CjxiPmNjOiA8L2I+PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyUzY3NmY0BpZXRmLm9yZyI+ c2ZjQGlldGYub3JnJmx0O3NmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U2VudDogPC9iPkZy aWRheSwgSmFudWFyeSAyNCwgMjAxNDxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW3NmY10gV0cg YWRvcHRpb24gb2YgZHJhZnQtcXVpbm4tc2ZjLXByb2JsZW0tc3RhdGVtZW50LTAyPGJyPg0KPGJy Pg0KSGksIEpvZWwuPGJyPg0KPGJyPg0KSSB0aGluayB5b3UgcmFpc2UgYW4gZXhjZWxsZW50IHBv aW50IG9uIHRoZSBhbWJpZ3VpdHkgb2YgbG9hZCBiYWxhbmNpbmcuICZuYnNwOyBJIHdvdWxkIHBy b3Bvc2UgdGhhdCB0aGVyZSBhcmUgbW9yZSB0aGFuIDIgY2FzZXMgb2YgbG9hZCBiYWxhbmNpbmc6 PGJyPg0KPGJyPg0KKiBtaWQtYm94IHNlcnZpY2UgZnVuY3Rpb24gKGUuZy4sIGZpcmV3YWxsKSB3 aXRoIGludGVybmFsIGxvYWQgYmFsYW5jaW5nPGJyPg0KKiBtaWQtYm94IHNlcnZpY2UgZnVuY3Rp b24gKGUuZy4sIGZpcmV3YWxsKSByZXF1aXJpbmcgZXh0ZXJuYWwgbG9hZCBiYWxhbmNpbmc8YnI+ DQoqIGV4cGxpY2l0bHkgYWRkcmVzc2VkIHNlcnZpY2UgKGUuZy4sIERCIHNlcnZlcikgd2l0aCBp bnRlcm5hbCBsb2FkIGJhbGFuY2luZzxicj4NCiogZXhwbGljaXRseSBhZGRyZXNzZWQgc2Vydmlj ZSAoZS5nLiwgV2ViIEhUVFAgc2VydmVyKSByZXF1aXJpbmcgZXh0ZXJuYWwgbG9hZCBiYWxhbmNp bmc8YnI+DQo8YnI+DQpGcm9tIGFuIFNGQyBwZXJzcGVjdGl2ZSwgSSB0aGluayB3ZSBjYW4gaWdu b3JlIHRoZSBjYXNlcyB3aGVyZSB0aGUgbWlkLWJveCBvciBleHBsaWNpdCBhcHBsaWNhdGlvbiBp cyBpbnRlcm5hbGx5IGxvYWQgYmFsYW5jZWQuICZuYnNwOyBTdWNoIGFwcGxpY2F0aW9ucyB3b3Vs ZCB0eXBpY2FsbHkgcHJlc2VudCBhIHNpbmdsZSBsb2NhdG9yIChpLmUuLCBJUCBhZGRyZXNzKSB0 byB0aGUgb3V0c2lkZSB3b3JsZCBhbmQgbWFuYWdlIHJlZGlyZWN0aW9uIGludGVybmFsbHkNCiB0 byB0aGUgY2x1c3RlcmVkIGFwcGxpY2F0aW9uLiAmbmJzcDsmbmJzcDsgPGJyPg0KPGJyPg0KSSB0 aGluayB0aGUgbGFzdCBidWxsZXQsIGV4dGVybmFsIGxvYWQgYmFsYW5jaW5nIGZvciBhbiBleHBs aWNpdGx5IGFkZHJlc3NlZCBzZXJ2aWNlIChlLmcuLCBXZWIgSFRUUCBzZXJ2ZXIpIGxlbmRzIGl0 c2VsZiB0byBsb2FkIGJhbGFuY2luZyBhcyBhbiBleHBsaWNpdCBzZXJ2aWNlIGZ1bmN0aW9uIGZy b20gYW4gU0ZDIHBlcnNwZWN0aXZlLiAmbmJzcDsgVGhhdCBpcywgdGhlIHNlcnZpY2UgZnVuY3Rp b24gaW4gdGhlIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW4NCiBpcyAmcXVvdDtsb2FkIGJhbGFuY2Vy JnF1b3Q7Ljxicj4NCjxicj4NClRoZSBzZWNvbmQgYnVsbGV0LCBleHRlcm5hbCBsb2FkIGJhbGFu Y2luZyBmb3IgbWlkLWJveCBzZXJ2aWNlIGZ1bmN0aW9uIChlLmcuLCBmaXJld2FsbCksIGlzIHNs aWdodGx5IHRyaWNraWVyLiAmbmJzcDsgRnJvbSBhbiBTRkMgcGVyc3BlY3RpdmUsIG15IHZpZXcg aXMgdGhhdCB0aGUgc2VydmljZSBmdW5jdGlvbiB0aGF0IGFwcGVhcnMgaW4gdGhlIHNlcnZpY2Ug ZnVuY3Rpb24gY2hhaW4gaXMgc3RpbGwgZmlyZXdhbGwgYW5kIG5vdCBsb2FkIGJhbGFuY2VyLg0K ICZuYnNwOyBIb3dldmVyLCBJIGRvIHRoaW5rIHRoYXQgU0ZDIHNob3VsZCBleHBsaWNpdGx5IGVt YnJhY2UgdGhlIGNvbmNlcHQgb2YgYSAmcXVvdDtsb2FkLWJhbGFuY2VkIHNlcnZpY2UgZnVuY3Rp b24mcXVvdDsuICZuYnNwOyBJIHRyaWVkIHRvIGFkZHJlc3MgdGhpcyBpbg0KPGEgaHJlZj0iaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wYXJrZXItc2ZjLWNoYWluLXRvLXBh dGgiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcGFya2VyLXNmYy1jaGFp bi10by1wYXRoPC9hPi8gYW5kIHdvdWxkIGFwcHJlY2lhdGUgYW55IGZlZWRiYWNrLjxicj4NCjxi cj4NClRoYW5rcy48YnI+DQo8YnI+DQombmJzcDsgUm9uPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQo8YnI+DQo8YnI+DQpGcm9tOiBzZmMgWzxhIGhyZWY9 Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn PC9hPl0gT24gQmVoYWxmIE9mIEpvZWwgTS4gSGFscGVybjxicj4NClNlbnQ6IFRodXJzZGF5LCBK YW51YXJ5IDIzLCAyMDE0IDEwOjM2IFBNPGJyPg0KVG86IExpbmRhIER1bmJhcjsgQ2F0aHkgWmhh bmc7IFBhdWwgUXVpbm4gKHBhdWxxKTsgSmltIEd1aWNoYXJkIChqZ3VpY2hhcik8YnI+DQpDYzog PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NClN1Ympl Y3Q6IFJlOiBbc2ZjXSBXRyBhZG9wdGlvbiBvZiBkcmFmdC1xdWlubi1zZmMtcHJvYmxlbS1zdGF0 ZW1lbnQtMDI8YnI+DQo8YnI+DQpGb3IgYXBwcyB0aGF0IGhhdmUgdGhlaXIgb3duIGludGVybmFs IGxvYWQgYmFsYW5jZXIsIEkgYWdyZWUgdGhhdCB0aGVyZSBpcyBubyBwb2ludCBpbiB0aGUgdGVu YW50IHVzaW5nIHRoZSBkYXRhIGNlbnRlciBvZmZlcmVkIGxvYWQgYmFsYW5jZXIgc2VydmljZS48 YnI+DQpCdXQgbWFueSBhcHBzIGRvIG5vdCBoYXZlIHRoZWlyIG93biBjdXN0b20gbG9hZCBiYWxh bmNlci4gU28gYSBkYXRhIGNlbnRlciBtaWdodCB3ZWxsIG9mZmVyIGxvYWQgYmFsYW5jaW5nIGFz IGEgc2VydmljZSBmb3IgdGhvc2UgdGVuYW50cyB3aG8gd2FudCBpdC48YnI+DQo8YnI+DQpNeSBv bmx5IHBvaW50IHdhcyB0byBkaXN0aW5ndWlzaCBsb2FkIGJhbGFuY2luZyBhcyBhIHNlcnZpY2Ug c2VsZWN0ZWQgYnkgdGhlIGN1c3RvbWVyIGZyb20gbG9hZCBiYWxhbmNpbmcgdXNlZCBieSB0aGUg b2VwcmF0b3IgaW50ZXJuYWxsO3kgdG8gZGVsaXZlciBzb21lIG90aGVyIHNlcnZpY2UuPGJyPg0K PGJyPg0KWW91cnMsPGJyPg0KSm9lbDxicj4NCjxicj4NCk9uIDEvMjMvMTQgMTA6MTggUE0sIExp bmRhIER1bmJhciB3cm90ZTo8YnI+DQomZ3Q7IEpvZWwsPGJyPg0KJmd0OyBRdWVzdGlvbnMgaW5z ZXJ0ZWQgYmVsb3c6PGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZn dDsgRnJvbTogc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0 bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBKb2VsIE0uIEhhbHBlcm48 YnI+DQomZ3Q7IFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDIzLCAyMDE0IDM6MTcgUE08YnI+DQom Z3Q7IFRvOiBDYXRoeSBaaGFuZzsgUGF1bCBRdWlubiAocGF1bHEpOyBKaW0gR3VpY2hhcmQgKGpn dWljaGFyKTxicj4NCiZndDsgQ2M6IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0Bp ZXRmLm9yZzwvYT48YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbc2ZjXSBXRyBhZG9wdGlvbiBvZiBk cmFmdC1xdWlubi1zZmMtcHJvYmxlbS1zdGF0ZW1lbnQtMDI8YnI+DQomZ3Q7IEluIGxvb2tpbmcg YXQgdGhlIHNlcnZpY2VzLCB3ZSBuZWVkIHRvIGJlIGNhcmVmdWwgYWJvdXQgd2hvIHRoZSA8YnI+ DQomZ3Q7IHNlcnZpY2UgaXMgZm9yLiBVc2luZyBsb2FkIGJhbGFuY2luZyBhcyBhbiBleGFtcGxl LCB0aGVyZSBhcmUgdHdvIGRpZmZlcmVudCBjYXNlcy48YnI+DQomZ3Q7IE9uZSBjYXNlLCBjb21t b24gaW4gYSBkYXRhIGNlbnRlciwgd2lsbCBidyB3aGVyZSBsb2FkIGJhbG5jaW5nIGlzIDxicj4N CiZndDsgcGFydCBvZiB0aGUgc2VydmljZSBiZWluZyBkZWxpdmVyZWQgdG8gdGhlIHRlbmFudCwg dG8gaGVscCBtYW5hZ2UgdGhlIDxicj4NCiZndDsgdGVuYW50cyBhcHBsaWNhdGlvbiB0cmFmZmlj Ljxicj4NCiZndDsgW0xpbmRhXSBkbyB5b3UgbWVhbiB3aGVuICZxdW90O0xvYWQgQmFsYW5jaW5n JnF1b3Q7IGFtb25nIGNsdXN0ZXIgb2Ygc2VydmVycyBmb3IgPGJyPg0KJmd0OyBvbmUgdGVuYW50 IGFwcGxpY2F0aW9uIGJlaW5nIG9mZmVyZWQgYXMgYSBzZXJ2aWNlPzxicj4NCiZndDsgSXNuJ3Qg dGhpcyBraW5kIG9mICZxdW90O2xvYWQgYmFsYW5jaW5nJnF1b3Q7IGFwcGxpY2F0aW9uIHNwZWNp ZmljPyBMaWtlIE9yYWNsZSA8YnI+DQomZ3Q7IERCIGhhcyBpdHMgb3duIExvYWQgQmFsYW5jZXIg YW1vbmcgY2x1c3RlciBvZiBzZXJ2ZXJzLjxicj4NCiZndDsgQSBkaWZmZXJlbnQgc2l0dWF0aW9u IGlzIHdoZW4gbG9hZCBiYWxhbmNpbmcgaXMgdXNlZCBpbnRlcm5hbGx5IHRvIHRoZSA8YnI+DQom Z3Q7IHNlcnZpY2UgY2hhaW5pbmcgdG8gbWFuYWdlIGluc3RhbmNlcyBvZiB0aGUgaW50ZXJuYWwg c2VydmljZXMgKHdoZXJlIDxicj4NCiZndDsgY2FyZGluYWxpdHkgaXMgaW52aXNpYmxlIHRvIHRo ZSB0ZW5hbnQgLyB1c2VyKS48YnI+DQomZ3Q7IEluIHRoZSBmb3JtZXIgY2FzZSwgTEIgaXMgYSBz ZXJ2aWNlLiBBbmQgaGFzIHRvIGJlIGFibGUgdG8gZGlyZWN0IDxicj4NCiZndDsgdHJhZmZpYyB0 byB0aGUgY29ycmVjdCB0ZW5hbnQgYXBwbGljYXRpb24gaW5zdGFuY2UuPGJyPg0KJmd0OyBJbiB0 aGUgbGF0dGVyIGNhc2UsIHRoZSBsb2FkIGJhbGFuY2luZyBtYXkgd2VsbCBiZSBidW5kbGVkIGlu IHdpdGggYSA8YnI+DQomZ3Q7IGNvbGxlY3Rpb24gb2YgY28tbG9jYXRlZCBzZXJ2aWNlIGluc3Rh bmNlcywgd2l0aCB0aGUgd2hvbGUgbG9va2luZyA8YnI+DQomZ3Q7IGxpa2UgYSBzZXJ2aWNlIGlu c3RhbmNlIHRvIHNlcnZpY2UgY2hhaW5pbmcgYW5kIHRoZSBlbmQgdXNlci4gKFRoZXJlIDxicj4N CiZndDsgYXBwZWFyIHRvIGJlIGEgbXVsdGlwbGljaXR5IG9mIHdheXMgdG8gZGVsaXZlciB0aGlz IGJlaGF2aW9yLiBIb3cgPGJyPg0KJmd0OyBtdWNoIHdlIG5lZWQgdG8gc3BlY2lmeSBpbiB0aGUg YXJjaGl0ZWN0dXJlIHJlbWFpbnMgdG8gYmUgc2Vlbi4pIDxicj4NCiZndDsgWW91cnMsIEpvZWwg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7 IHNmYyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmci PnNmY0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPm1haWx0 bzpzZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2ZjPC9hPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0Kc2ZjIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpz ZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmM8L2E+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpzZmMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv OnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_aca97274f9c84c07bbb81da119298b93CO2PR05MB716namprd05pro_-- From mikebianc@aol.com Fri Jan 24 08:04:59 2014 Return-Path: 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 9EC8D1A03FF for ; Fri, 24 Jan 2014 08:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.834 X-Spam-Level: X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 RWwnSLg5DgPx for ; Fri, 24 Jan 2014 08:04:55 -0800 (PST) Received: from omr-d09.mx.aol.com (omr-d09.mx.aol.com [205.188.108.133]) by ietfa.amsl.com (Postfix) with ESMTP id F24A01A001E for ; Fri, 24 Jan 2014 08:04:54 -0800 (PST) Received: from mtaout-mcc01.mx.aol.com (mtaout-mcc01.mx.aol.com [172.26.253.77]) by omr-d09.mx.aol.com (Outbound Mail Relay) with ESMTP id B9253701FBA59; Fri, 24 Jan 2014 11:04:53 -0500 (EST) Received: from mgs-aam01.mail.aol.com (mgs-aam01.mail.aol.com [64.12.250.54]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-mcc01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 825C13800008A; Fri, 24 Jan 2014 11:04:53 -0500 (EST) Date: Fri, 24 Jan 2014 11:04:53 -0500 From: "mikebianc@aol.com" To: Ron_Parker@affirmednetworks.com, jmh@joelhalpern.com, linda.dunbar@huawei.com, Cathy.H.Zhang@huawei.com, paulq@cisco.com, jguichar@cisco.com Message-ID: <204899072.8879.1390579493455.JavaMail.tomcat@mgs-aam01.mail.aol.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8878_1923892793.1390579493454" X-Originating-IP: 10.181.180.127, 64.12.75.136 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1390579493; bh=kwmM+OvShWQYKiyLgFTuWt4Hv+o5EiQQ6SP38nJdSkM=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=kyGK0sh85YqVq2yTngVb0Hluan2jyUzH2DzkSnLE3F48/1BUfCdHtmrsRIlUi9tfE oL5FxJsQiX4pXZSteNGcaCScp/3v0r1mYiCZg2vUGNtnBza8ifMffM7xAU6UCLuoQY RrKGHMUy32MhNjQXPjUOf5PdXEf2nuD8qugA0Vps= x-aol-sid: 3039ac1afd4d52e28f253366 X-AOL-IP: 64.12.250.54 Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 16:04:59 -0000 ------=_Part_8878_1923892793.1390579493454 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To contextualize my comments: Assuming you needed to insert a CDN into a chain and had 8 equally viable i= nstances (cdn1..cdn8), I see two primary methods of choosing which instance= receives a particular flow: 1. =C2=A0The chain includes either the pool of services (CDN) or a shim ser= vice (proxy, service lb) where the specific instance is selected on the fly 2. The specific instance is part of the chain (cdn1) If the latter (instance in chain), should SFC include a mechanism for remap= ping the chain to use another instance? In either case, should the selection of the instance ("service distribution= "? anyone? anyone?) be part of SFC or left up to implementation? Since we've already discussed dynamically inserting and removing services i= nto or from a chain (long flow use cases draft), it seems that specifying t= he specific service instance in a chain (#1 above) for a flow would be simp= ler than introducing a shim proxyish service. =C2=A0This approach might als= o simplify the requirements for stateful v non-stateful services. From: Ron_Parker@affirmednetworks.com To: Joel M. Halpern,Linda Dunbar,Cathy Zhang,Paul Quinn (paulq),Jim Guichard (jguichar) cc: sfc@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 balanci= ng * explicitly addressed service (e.g., DB server) with internal load balanci= ng * explicitly addressed service (e.g., Web HTTP server) requiring external l= oad 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 wo= uld typically present a single locator (i.e., IP address) to the outside wo= rld and manage redirection internally to the clustered application. =20 I think the last bullet, external load balancing for an explicitly addresse= d service (e.g., Web HTTP server) lends itself to load balancing as an expl= icit service function from an SFC perspective. That is, the service funct= ion 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 sti= ll firewall and not load balancer. However, I do think that SFC should ex= plicitly embrace the concept of a "load-balanced service function". I tri= ed to address this in http://datatracker.ietf.org/doc/draft-parker-sfc-chai= n-to-path/ and would appreciate any feedback. Thanks. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. HalpernSent: T= hursday, January 23, 2014 10:36 PMTo: Linda Dunbar; Cathy Zhang; Paul Quinn= (paulq); Jim Guichard (jguichar)Cc: sfc@ietf.orgSubject: Re: [sfc] WG adop= tion of draft-quinn-sfc-problem-statement-02For apps that have their own in= ternal load balancer, I agree that there is no point in the tenant using th= e 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 balancin= g as a service for those tenants who want it.My only point was to distingui= sh load balancing as a service selected by the customer from load balancing= used by the oeprator internall;y to deliver some other service.Yours,JoelO= n 1/23/14 10:18 PM, Linda Dunbar wrote:> Joel,> Questions inserted below:> = -----Original Message-----> From: sfc [mailto:sfc-bounces@ietf.org] On Beha= lf 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> Subje= ct: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02> In looki= ng 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 cas= e, common in a data center, will bw where load balncing is > part of the s= ervice being delivered to the tenant, to help manage the > tenants applicat= ion traffic.> [Linda] do you mean when "Load Balancing" among cluster of se= rvers 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 loa= d balancing is used internally to the > service chaining to manage instance= s 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 direc= t > traffic to the correct tenant application instance.> In the latter case= , the load balancing may well be bundled in with a > collection of co-locat= ed service instances, with the whole looking > like a service instance to s= ervice 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 archit= ecture remains to be seen.) > Yours, Joel _________________________________= ______________> sfc mailing list> sfc@ietf.org > https= ://www.ietf.org/mailman/listinfo/sfc_______________________________________= ________sfc mailing listsfc@ietf.orghttps://www.ietf.org/mailman/listinfo/s= fc_______________________________________________sfc mailing listsfc@ietf.o= rghttps://www.ietf.org/mailman/listinfo/sfc ------=_Part_8878_1923892793.1390579493454 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
To contextualiz= e my comments:
Assuming you needed to insert a CDN into a chain a= nd had 8 equally viable instances (cdn1..cdn8), I see two primary methods o= f choosing which instance receives a particular flow:
1.  Th= e chain includes either the pool of services (CDN) or a shim service (proxy= , service lb) where the specific instance is selected on the fly
= 2. The specific instance is part of the chain (cdn1)

If the latter (instance in chain), should SFC include a mechanism for re= mapping the chain to use another instance?
In either case, s= hould the selection of the instance ("service distribution"? anyone? anyo= ne?) be part of SFC or left up to implementation?

Since we've already discussed dynamically inserting and removing serv= ices into or from a chain (long flow use cases draft), it seems that specif= ying the specific service instance in a chain (#1 above) for a flow would b= e simpler than introducing a shim proxyish service.  This approach mig= ht also simplify the requirements for stateful v non-stateful services.




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

Hi, Joel.

I th= ink you raise an excellent point on the ambiguity of load balancing. I wo= uld propose that there are more than 2 cases of load balancing:

* mi= d-box service function (e.g., firewall) with internal load balancing
* m= id-box service function (e.g., firewall) requiring external load balancing<= br>* explicitly addressed service (e.g., DB server) with internal load bala= ncing
* explicitly addressed service (e.g., Web HTTP server) requiring e= xternal load balancing

From an SFC perspective, I think we can ignor= e the cases where the mid-box or explicit application is internally load ba= lanced. 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 ba= lancing for an explicitly addressed service (e.g., Web HTTP server) lends i= tself to load balancing as an explicit service function from an SFC perspec= tive. That is, the service function in the service function chain is "loa= d balancer".

The second bullet, external load balancing for mid-box = service function (e.g., firewall), is slightly trickier. From an SFC pers= pective, my view is that the service function that appears in the service f= unction chain is still firewall and not load balancer. However, I do thin= k that SFC should explicitly embrace the concept of a "load-balanced servic= e function". I tried to address this in http://datatracker.ietf.org/doc/d= raft-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. Halpe= rn
Sent: Thursday, January 23, 2014 10:36 PM
To= : Linda Dunbar; Cathy Zhang; Paul Quinn (paulq); Jim Guichard (jguichar)Cc: sfc@ietf.org
Subject: Re: [sfc] WG adoption o= f draft-quinn-sfc-problem-statement-02

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

My only point was to distinguish loa= d 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,
&g= t; Questions inserted below:
> -----Original Message-----<= br class=3D"">> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joe= l M. Halpern
> Sent: Thursday, January 23, 2014 3:17 PM> To: Cathy Zhang; Paul Quinn (paulq); Jim Guichard (jguicha= r)
> Cc: 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 d= ifferent cases.
> One case, common in a data center, will= bw where load balncing is
> part of the service being de= livered to the tenant, to help manage the
> tenants appli= cation traffic.
> [Linda] do you mean when "Load Balancing= " among cluster of servers for
> one tenant application b= eing offered as a service?
> Isn't this kind of "load bala= ncing" application specific? Like Oracle
> DB has its own= Load Balancer among cluster of servers.
> A different sit= uation 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 <= br class=3D"">> traffic to the correct tenant application instance.
> In the latter case, the load balancing may well be bundled i= n with a
> collection of co-located service instances, wi= th the whole looking
> like a service instance to service= chaining and the end user. (There
> appear to be a mult= iplicity of ways to deliver this behavior. How
> much we= need to specify in the architecture remains to be seen.)
&g= t; Yours, Joel _______________________________________________
> sfc mailing list
> sfc@ietf.org <mailto:sfc@ietf= .org>
> https://www.ietf.org/mailman/listinfo/sfc
_______________________________________________
sfc = mailing list
sfc@ietf.org
https://www.ietf.org/= mailman/listinfo/sfc
________________________________________= _______
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc
------=_Part_8878_1923892793.1390579493454-- From paulq@cisco.com Fri Jan 24 08:18:16 2014 Return-Path: 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 0BEB51A0037 for ; Fri, 24 Jan 2014 08:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.435 X-Spam-Level: X-Spam-Status: No, score=-14.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 qvwceqQDHAHv for ; Fri, 24 Jan 2014 08:18:11 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A56181A0010 for ; Fri, 24 Jan 2014 08:18:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16703; q=dns/txt; s=iport; t=1390580290; x=1391789890; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nbhmCAN1IJlQK7pyA5JL6Xzo+T0KeWFwus2Z8Dc8BBs=; b=YrEG5kRthYVxvfgmkn88U+qk/ko63EHAK76/UMEn1BqZBLgGfyk8KAtX dQUSQdQ8OMhhw2maN+LyJumTC8v8UCU+RTMUpFkXieZT7bIjq2nQb0Q9c c33Dw34H4jQEwxn9Twb7qY/A9HTm4Pq59c3/yzYEOyUQoIqhG5IiR704M A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisHAMmR4lKtJXG+/2dsb2JhbABagww4VoVfoxgyijmIU4EMFnSCJQEBAQQBAQFiCQsMBAIBCBEBAwEBAScHJwsUAwYIAgQOBYdxAxENyC4XjHaBaycEBgEGgx6BFASYJ4EykGyBQIFtgio X-IronPort-AV: E=Sophos;i="4.95,713,1384300800"; d="scan'208,217";a="299510405" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 24 Jan 2014 16:18:09 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0OGI9oc008358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Jan 2014 16:18:09 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.19]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Fri, 24 Jan 2014 10:18:09 -0600 From: "Paul Quinn (paulq)" To: "mikebianc@aol.com" Thread-Topic: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 Thread-Index: AQHPGR4EBBXmRpg9rk2thNSnYBnFRZqUcgwA Date: Fri, 24 Jan 2014 16:18:08 +0000 Message-ID: References: <204899072.8879.1390579493455.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: <204899072.8879.1390579493455.JavaMail.tomcat@mgs-aam01.mail.aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.229] Content-Type: multipart/alternative; boundary="_000_CC4C05B567774F40881329DDC19519E2ciscocom_" MIME-Version: 1.0 Cc: "" , "Jim Guichard \(jguichar\)" , "" , "" , "" , "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 16:18:16 -0000 --_000_CC4C05B567774F40881329DDC19519E2ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mike, On Jan 24, 2014, at 11:04 AM, mikebianc@aol.com w= rote: To contextualize my comments: Assuming you needed to insert a CDN into a chain and had 8 equally viable i= nstances (cdn1..cdn8), I see two primary methods of choosing which instance= receives a particular flow: 1. The chain includes either the pool of services (CDN) or a shim service = (proxy, service lb) where the specific instance is selected on the fly 2. The specific instance is part of the chain (cdn1) If the latter (instance in chain), should SFC include a mechanism for remap= ping the chain to use another instance? In either case, should the selection of the instance ("service distribution= "? anyone? anyone?) be part of SFC or left up to implementation? It depends :) In case #1, does the "shim service" present itself as a SF? = It might still have policy dependencies about being coupled with cdn, but = is it externally "visible"? Since we've already discussed dynamically inserting and removing services i= nto or from a chain (long flow use cases draft), it seems that specifying t= he specific service instance in a chain (#1 above) for a flow would be simp= ler than introducing a shim proxyish service. This approach might also sim= plify the requirements for stateful v non-stateful services. ________________________________ From: Ron_Parker@affirmednetworks.com> To: Joel M. Halpern>,Linda = Dunbar>,Cathy Zhang= >,Paul Quinn (pau= lq)>,Jim Guichard (jguichar)> cc: sfc@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 balanci= ng * explicitly addressed service (e.g., DB server) with internal load balanci= ng * explicitly addressed service (e.g., Web HTTP server) requiring external l= oad 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 woul= d typically present a single locator (i.e., IP address) to the outside worl= d and manage redirection internally to the clustered application. I think the last bullet, external load balancing for an explicitly addresse= d service (e.g., Web HTTP server) lends itself to load balancing as an expl= icit service function from an SFC perspective. That is, the service functio= n 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 th= at the service function that appears in the service function chain is still= firewall and not load balancer. However, I do think that SFC should explic= itly 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-p= ath/ 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 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 th= e 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 Behal= f 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 > 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 differe= nt 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 > https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_CC4C05B567774F40881329DDC19519E2ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <7866E621BA5E5A4BA8E7F0D53DB61484@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Hi Mike,


On Jan 24, 2014, at 11:04 AM, mik= ebianc@aol.com wrote:

To contextualize my comments:
Assuming you needed to insert a CDN into a chain and had 8 equally via= ble instances (cdn1..cdn8), I see two primary methods of choosing which ins= tance receives a particular flow:
1.  The chain includes either the pool of services (CDN) or a shi= m service (proxy, service lb) where the specific instance is selected on th= e fly
2. The specific instance is part of the chain (cdn1)

If the latter (instance in chain), should SFC include a mechanism for = remapping the chain to use another instance?
In either case, should the selection of the instance ("service di= stribution"? anyone? anyone?) be part of SFC or left up to implementat= ion?


It depends :)  In case #1, does the "shim service" pres= ent itself as a SF?  It might still have policy dependencies about bei= ng coupled with cdn, but is it externally "visible"?


Since we've already discussed dynamically inserting and removing servi= ces into or from a chain (long flow use cases draft), it seems that specify= ing the specific service instance in a chain (#1 above) for a flow would be= simpler than introducing a shim proxyish service.  This approach might also simplify the requirements= for stateful v non-stateful services.



From: Ron_Parker@= affirmednetworks.com<Ron_Parker@affirmednetworks.com>
To: Joel M. Halpern<jmh@jo= elhalpern.com>,Linda Dunbar<linda.dunbar@huawei.com>,Cathy Zhang<Cathy.H.Zhang@huawei.com>,Paul Quinn (paulq)<paulq@cisco.com>= ;,Jim Guichard (jguichar)<jguichar= @cisco.com>
cc: sfc@ietf.org<sfc@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 balanci= ng
* explicitly addressed service (e.g., DB server) with internal load balanci= ng
* explicitly addressed service (e.g., Web HTTP server) requiring external l= oad 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 woul= d typically present a single locator (i.e., IP address) to the outside worl= d and manage redirection internally to the clustered application.

I think the last bullet, external load balancing for an explicitly addresse= d service (e.g., Web HTTP server) lends itself to load balancing as an expl= icit service function from an SFC perspective. That is, the service functio= n 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 th= at 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 &q= uot;load-balanced service function". I tried to address this in = http://datatracker.ietf.org/doc/draft-parker-sfc-chain-to-path/ and wou= ld appreciate any feedback.

Thanks.

Ron


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


From: sfc [mailto:sfc-bounces@ietf.org<= /a>] 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)<= br class=3D""> Cc: 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 th= e 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
> 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 diff= erent 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 s= ervers for
> one tenant application being offered as a service?
> Isn't this kind of "load balancing" application specific? Li= ke 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 <= br class=3D""> > 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 <= br class=3D""> > collection of co-located service instances, with the whole looking > like a service instance to service chaining and the end user. (There <= br class=3D""> > 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>
> https://www.ietf= .org/mailman/listinfo/sfc
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

--_000_CC4C05B567774F40881329DDC19519E2ciscocom_-- From linda.dunbar@huawei.com Fri Jan 24 08:36:16 2014 Return-Path: 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 8B3051A04D1 for ; Fri, 24 Jan 2014 08:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.135 X-Spam-Level: X-Spam-Status: No, score=-4.135 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, RP_MATCHES_RCVD=-0.535, 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 INuqHLXVjsRJ for ; Fri, 24 Jan 2014 08:36:10 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 851B41A0010 for ; Fri, 24 Jan 2014 08:36:09 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCW85129; Fri, 24 Jan 2014 16:36:07 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 16:35:58 +0000 Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 16:36:05 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml706-chm.china.huawei.com ([169.254.8.193]) with mapi id 14.03.0158.001; Fri, 24 Jan 2014 08:35:56 -0800 From: Linda Dunbar To: "Paul Quinn (paulq)" , "mikebianc@aol.com" Thread-Topic: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 Thread-Index: AQHPGR4EBBXmRpg9rk2thNSnYBnFRZqUcgwA//+e4mA= Date: Fri, 24 Jan 2014 16:35:55 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C707E2@dfweml701-chm.china.huawei.com> References: <204899072.8879.1390579493455.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.117] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645C707E2dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Jim Guichard \(jguichar\)" , Cathy Zhang , "" , "" , "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 16:36:16 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645C707E2dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If a service function has a small number of instances, say less than 10, an= d they are relative stable, then it is doable for Service Chain to specify = the specific instances. But if there are large number of instances, say in hundreds, and those inst= ances' location/presence change over time (e.g. in NFV environment), then i= t is not scalable to have Service Chain path to specify the specific instan= ces. The instances selection should be left up to implementation, or at lea= st out of the SFC WG scope. Linda From: Paul Quinn (paulq) [mailto:paulq@cisco.com] To contextualize my comments: Assuming you needed to insert a CDN into a chain and had 8 equally viable i= nstances (cdn1..cdn8), I see two primary methods of choosing which instance= receives a particular flow: 1. The chain includes either the pool of services (CDN) or a shim service = (proxy, service lb) where the specific instance is selected on the fly 2. The specific instance is part of the chain (cdn1) If the latter (instance in chain), should SFC include a mechanism for remap= ping the chain to use another instance? In either case, should the selection of the instance ("service distribution= "? anyone? anyone?) be part of SFC or left up to implementation? It depends :) In case #1, does the "shim service" present itself as a SF? = It might still have policy dependencies about being coupled with cdn, but = is it externally "visible"? Since we've already discussed dynamically inserting and removing services i= nto or from a chain (long flow use cases draft), it seems that specifying t= he specific service instance in a chain (#1 above) for a flow would be simp= ler than introducing a shim proxyish service. This approach might also sim= plify the requirements for stateful v non-stateful services. ________________________________ From: Ron_Parker@affirmednetworks.com> To: Joel M. Halpern>,Linda = Dunbar>,Cathy Zhang= >,Paul Quinn (pau= lq)>,Jim Guichard (jguichar)> cc: sfc@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 balanci= ng * explicitly addressed service (e.g., DB server) with internal load balanci= ng * explicitly addressed service (e.g., Web HTTP server) requiring external l= oad 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 woul= d typically present a single locator (i.e., IP address) to the outside worl= d and manage redirection internally to the clustered application. I think the last bullet, external load balancing for an explicitly addresse= d service (e.g., Web HTTP server) lends itself to load balancing as an expl= icit service function from an SFC perspective. That is, the service functio= n 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 th= at the service function that appears in the service function chain is still= firewall and not load balancer. However, I do think that SFC should explic= itly 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-p= ath/ 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 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 th= e 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 Behal= f 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 > 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 differe= nt 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 > https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_4A95BA014132FF49AE685FAB4B9F17F645C707E2dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If a service function has= a small number of instances, say less than 10, and they are relative stabl= e, then it is doable for Service Chain to specify the specific instances.

 <= /p>

But if there are large nu= mber of instances, say in hundreds, and those instances’ location/pre= sence change over time (e.g. in NFV environment), then it is not scalable to have Service Chain path to specify the specific instances. The= instances selection should be left up to implementation, or at least out o= f the SFC WG scope.

 <= /p>

Linda

 <= /p>

From: Paul Qui= nn (paulq) [mailto:paulq@cisco.com]



To contextualize my comments:<= /span>

Assuming you needed to insert a CDN into = a chain and had 8 equally viable instances (cdn1..cdn8), I see two primary = methods of choosing which instance receives a particular flow:

1.  The chain includes either the po= ol of services (CDN) or a shim service (proxy, service lb) where the specif= ic instance is selected on the fly

2. The specific instance is part of the c= hain (cdn1)

 

If the latter (instance in chain), should= SFC include a mechanism for remapping the chain to use another instance?

In either case, should the selection of t= he instance ("service distribution"? anyone? anyone?) be part of = SFC or left up to implementation?

 <= /p>

 

 

It depends :)  In case #1, does the "shim = service" present itself as a SF?  It might still have policy depe= ndencies about being coupled with cdn, but is it externally "visible&q= uot;?

 



Since we've already discussed dynamically= inserting and removing services into or from a chain (long flow use cases = draft), it seems that specifying the specific service instance in a chain (#1 above) for a flow would be simpler than introducing a shim = proxyish service.  This approach might also simplify the requirements = for stateful v non-stateful services.

 



From: Ron_Parker@affirmednetworks.com= <Ron_Parker@affir= mednetworks.com>
To: Joel M. Halpern<jmh@jo= elhalpern.com>,Linda Dunbar<linda.dunbar@huawei.com>,Cathy Zhang<Cathy.H.Zhang@huawei.com>,Paul Quinn (paulq)<paulq@cisco.com>= ;,Jim Guichard (jguichar)<jguichar= @cisco.com>
cc: sfc@ietf.org<sfc@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 balanci= ng
* explicitly addressed service (e.g., DB server) with internal load balanci= ng
* explicitly addressed service (e.g., Web HTTP server) requiring external l= oad 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 woul= d typically present a single locator (i.e., IP address) to the outside worl= d and manage redirection internally to the clustered application.

I think the last bullet, external load balancing for an explicitly addresse= d service (e.g., Web HTTP server) lends itself to load balancing as an expl= icit service function from an SFC perspective. That is, the service functio= n 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 th= at 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 &q= uot;load-balanced service function". I tried to address this in = http://datatracker.ietf.org/doc/draft-parker-sfc-chain-to-path/ and wou= ld appreciate any feedback.

Thanks.

Ron


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


From: sfc [mailto:sfc-bounces@ietf.org<= /a>] 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)<= br> Cc: 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 th= e 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
> 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 diff= erent 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 s= ervers for
> one tenant application being offered as a service?
> Isn't this kind of "load balancing" application specific? Li= ke 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 <= br> > 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 <= br> > collection of co-located service instances, with the whole looking > like a service instance to service chaining and the end user. (There <= br> > 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>
> https://www.ietf= .org/mailman/listinfo/sfc
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/= mailman/listinfo/sfc
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/= mailman/listinfo/sfc
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/= mailman/listinfo/sfc

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645C707E2dfweml701chmchi_-- From cfrederick@sandvine.com Fri Jan 24 09:09:53 2014 Return-Path: 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 5839B1A0008 for ; Fri, 24 Jan 2014 09:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.834 X-Spam-Level: X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_91=0.6, RP_MATCHES_RCVD=-0.535] 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 NsK6ugyhjXXk for ; Fri, 24 Jan 2014 09:09:48 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id BC0A61A0057 for ; Fri, 24 Jan 2014 09:09:47 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%20]) with mapi id 14.01.0339.001; Fri, 24 Jan 2014 12:09:45 -0500 From: Chris Frederick To: Linda Dunbar , "Paul Quinn (paulq)" , "mikebianc@aol.com" Thread-Topic: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 Thread-Index: AQHPGR4EBBXmRpg9rk2thNSnYBnFRZqUcgwA//+e4mCAAAP3kA== Date: Fri, 24 Jan 2014 17:09:45 +0000 Message-ID: <802F0FD88084CC4D82A0663874219D1A1887EE12@wtl-exchp-2.sandvine.com> References: <204899072.8879.1390579493455.JavaMail.tomcat@mgs-aam01.mail.aol.com> <4A95BA014132FF49AE685FAB4B9F17F645C707E2@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C707E2@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.194.252] Content-Type: multipart/alternative; boundary="_000_802F0FD88084CC4D82A0663874219D1A1887EE12wtlexchp2sandvi_" MIME-Version: 1.0 Cc: "Jim Guichard \(jguichar\)" , Cathy Zhang , "" , "" , "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 17:09:53 -0000 --_000_802F0FD88084CC4D82A0663874219D1A1887EE12wtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Policy-based selection of a particular service function instance (path) can= be useful in a number of scenarios (say, where there's a desire to send a = particular app/protocol to cache1 vs. cache2, etc). In the interest of sharing approaches, we lb on internal IP of each flow (e= nsuring the same flow goes to the same instance) across named instances, ph= ysical or virtualized. This approach obviously implies a need to health check not just the chain = but individual instances as well, which we do w/ an inline health check, go= ing both directions through the chain. I think it makes sense to allow the specification of a set of equivalent ch= ains, decided by the start of the chain. Thx, /c From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Friday, January 24, 2014 11:36 AM To: Paul Quinn (paulq); mikebianc@aol.com Cc: Jim Guichard (jguichar); Cathy Zhang; ; ; Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 If a service function has a small number of instances, say less than 10, an= d they are relative stable, then it is doable for Service Chain to specify = the specific instances. But if there are large number of instances, say in hundreds, and those inst= ances' location/presence change over time (e.g. in NFV environment), then i= t is not scalable to have Service Chain path to specify the specific instan= ces. The instances selection should be left up to implementation, or at lea= st out of the SFC WG scope. Linda From: Paul Quinn (paulq) [mailto:paulq@cisco.com] To contextualize my comments: Assuming you needed to insert a CDN into a chain and had 8 equally viable i= nstances (cdn1..cdn8), I see two primary methods of choosing which instance= receives a particular flow: 1. The chain includes either the pool of services (CDN) or a shim service = (proxy, service lb) where the specific instance is selected on the fly 2. The specific instance is part of the chain (cdn1) If the latter (instance in chain), should SFC include a mechanism for remap= ping the chain to use another instance? In either case, should the selection of the instance ("service distribution= "? anyone? anyone?) be part of SFC or left up to implementation? It depends :) In case #1, does the "shim service" present itself as a SF? = It might still have policy dependencies about being coupled with cdn, but = is it externally "visible"? Since we've already discussed dynamically inserting and removing services i= nto or from a chain (long flow use cases draft), it seems that specifying t= he specific service instance in a chain (#1 above) for a flow would be simp= ler than introducing a shim proxyish service. This approach might also sim= plify the requirements for stateful v non-stateful services. ________________________________ From: Ron_Parker@affirmednetworks.com> To: Joel M. Halpern>,Linda = Dunbar>,Cathy Zhang= >,Paul Quinn (pau= lq)>,Jim Guichard (jguichar)> cc: sfc@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 balanci= ng * explicitly addressed service (e.g., DB server) with internal load balanci= ng * explicitly addressed service (e.g., Web HTTP server) requiring external l= oad 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 woul= d typically present a single locator (i.e., IP address) to the outside worl= d and manage redirection internally to the clustered application. I think the last bullet, external load balancing for an explicitly addresse= d service (e.g., Web HTTP server) lends itself to load balancing as an expl= icit service function from an SFC perspective. That is, the service functio= n 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 th= at the service function that appears in the service function chain is still= firewall and not load balancer. However, I do think that SFC should explic= itly 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-p= ath/ 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 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 th= e 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 Behal= f 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 > 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 differe= nt 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 > https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_802F0FD88084CC4D82A0663874219D1A1887EE12wtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Policy-based selection of= a particular service function instance (path) can be useful in a number of= scenarios (say, where there’s a desire to send a particular app/protocol to cache1 vs. cache2, etc).

In the interest of sharin= g approaches, we lb on internal IP of each flow (ensuring the same flow goe= s to the same instance) across named instances, physical or virtualized.

This  approach obvio= usly implies a need to health check not just the chain but individual insta= nces as well, which we do w/ an inline health check, going both directions through the chain.

I think it makes sense to allow the specification of a set of eq= uivalent chains, decided by the start of the chain. Thx,

/c

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Friday, January 24, 2014 11:36 AM
To: Paul Quinn (paulq); mikebianc@aol.com
Cc: Jim Guichard (jguichar); Cathy Zhang; <jmh@joelhalpern.com>= ;; <sfc@ietf.org>; <Ron_Parker@affirmednetworks.com>
Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-= 02

 

If a service function has= a small number of instances, say less than 10, and they are relative stabl= e, then it is doable for Service Chain to specify the specific instances.

 <= /p>

But if there are large nu= mber of instances, say in hundreds, and those instances’ location/pre= sence change over time (e.g. in NFV environment), then it is not scalable to have Service Chain path to specify the specific instances. The= instances selection should be left up to implementation, or at least out o= f the SFC WG scope.

 <= /p>

Linda

 <= /p>

From:<= /span> Paul Quinn (paulq) [mailto:paulq@cisco.com]

 

To contextualize my comments:<= /span>

Assuming you needed to insert a CDN into = a chain and had 8 equally viable instances (cdn1..cdn8), I see two primary = methods of choosing which instance receives a particular flow:

1.  The chain includes either the po= ol of services (CDN) or a shim service (proxy, service lb) where the specif= ic instance is selected on the fly

2. The specific instance is part of the c= hain (cdn1)

 

If the latter (instance in chain), should= SFC include a mechanism for remapping the chain to use another instance?

In either case, should the selection of t= he instance ("service distribution"? anyone? anyone?) be part of = SFC or left up to implementation?

 <= /p>

 

 

It depends :)  In case #1, does the "shim = service" present itself as a SF?  It might still have policy depe= ndencies about being coupled with cdn, but is it externally "visible&q= uot;?

 

 

Since we've already discussed dynamically= inserting and removing services into or from a chain (long flow use cases = draft), it seems that specifying the specific service instance in a chain (#1 above) for a flow would be simpler than introducing a shim = proxyish service.  This approach might also simplify the requirements = for stateful v non-stateful services.

 

 

From: Ron_Parker@affirmednetworks.com= <Ron_Parker@affir= mednetworks.com>
To: Joel M. Halpern<jmh@jo= elhalpern.com>,Linda Dunbar<linda.dunbar@huawei.com>,Cathy Zhang<Cathy.H.Zhang@huawei.com>,Paul Quinn (paulq)<paulq@cisco.com>= ;,Jim Guichard (jguichar)<jguichar= @cisco.com>
cc: sfc@ietf.org<sfc@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 balanci= ng
* explicitly addressed service (e.g., DB server) with internal load balanci= ng
* explicitly addressed service (e.g., Web HTTP server) requiring external l= oad 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 woul= d typically present a single locator (i.e., IP address) to the outside worl= d and manage redirection internally to the clustered application.

I think the last bullet, external load balancing for an explicitly addresse= d service (e.g., Web HTTP server) lends itself to load balancing as an expl= icit service function from an SFC perspective. That is, the service functio= n 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 th= at 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 &q= uot;load-balanced service function". I tried to address this in = http://datatracker.ietf.org/doc/draft-parker-sfc-chain-to-path/ and wou= ld appreciate any feedback.

Thanks.

Ron


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


From: sfc [mailto:sfc-bounces@ietf.org<= /a>] 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)<= br> Cc: 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 th= e 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
> 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 diff= erent 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 s= ervers for
> one tenant application being offered as a service?
> Isn't this kind of "load balancing" application specific? Li= ke 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 <= br> > 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 <= br> > collection of co-located service instances, with the whole looking > like a service instance to service chaining and the end user. (There <= br> > 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>
> https://www.ietf= .org/mailman/listinfo/sfc
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/= mailman/listinfo/sfc
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/= mailman/listinfo/sfc
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/= mailman/listinfo/sfc

 

--_000_802F0FD88084CC4D82A0663874219D1A1887EE12wtlexchp2sandvi_-- From repenno@cisco.com Fri Jan 24 09:14:07 2014 Return-Path: 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 3042B1A00A6 for ; Fri, 24 Jan 2014 09:14:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.436 X-Spam-Level: X-Spam-Status: No, score=-9.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_91=0.6, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 yGEp8WaPdsga for ; Fri, 24 Jan 2014 09:14:04 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB731A0008 for ; Fri, 24 Jan 2014 09:14:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8208; q=dns/txt; s=iport; t=1390583643; x=1391793243; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=2p8vWcED0kbl/i235fdb2D0/kgGQBTIaD7QfdDLTGc0=; b=TrH9NFgnkzOje9Un1e05GUlVXc6Nzo4pBaMKQiqLqMwyezbnqF6pL6v+ Vj4KF/DwHwVj0io1YDEaM6PtvYpVOJg66XUIsnByOsKmfkfEfU6k+vLsG pyoks2LDZrQylFlVMf1gOvyspRYtxtZoNX5Iqkcb8DcJjdoqU8iXmr1N0 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAFue4lKtJV2a/2dsb2JhbABagww4Vqh3kz6BDRZ0giUBAQEEAQEBYgkLDAYBCBEBAgEBAQEnLgsUAwYIAgQBDQWHcQMRDcgwF4x2gWsrBwaEMgSJEI8XgTKQbIMtgio X-IronPort-AV: E=Sophos;i="4.95,713,1384300800"; d="scan'208";a="15315407" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP; 24 Jan 2014 17:14:02 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0OHE2ZC015180 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Jan 2014 17:14:02 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.37]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Fri, 24 Jan 2014 11:14:02 -0600 From: "Reinaldo Penno (repenno)" To: Linda Dunbar , "Paul Quinn (paulq)" , "mikebianc@aol.com" Thread-Topic: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 Thread-Index: AQHPGR4EBBXmRpg9rk2thNSnYBnFRZqUcgwA//+e4mD//+qmgA== Date: Fri, 24 Jan 2014 17:14:01 +0000 Message-ID: In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C707E2@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.118.183] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <246C0E29EAC863429D800A6B8C04A0AB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Jim Guichard \(jguichar\)" , Cathy Zhang , "" , "" , "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 17:14:07 -0000 You bring good point, but it seems it still aligned with current proposal. A Service Chain does not specify the actual stateless firewall (out of the hundreds of function equivalent firewalls) that are going to be used in a chain. Just that a firewall is present on a chain. A Service Function Path is an instantiation of a Service Chain. It specifies the actual firewall (say, firewall-3) that will be traversed by the packets. The Service Path needs to be known before hand or stitched run-time (given the dynamic LB decision) since a forwarding decision need to be made regardless. So, in your example there would one chain, many service paths. Other combinations are possible of course depending on implementation strategy. From: Linda Dunbar Date: Friday, January 24, 2014 at 8:35 AM To: "Paul Quinn (paulq)" , "mikebianc@aol.com" Cc: "Jim Guichard (jguichar)" , Cathy Zhang , "" , "" , "" Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 If a service function has a small number of instances, say less than 10, and they are relative stable, then it is doable for Service Chain to specify the specific instances.=20 =20 But if there are large number of instances, say in hundreds, and those instances=B9 location/presence change over time (e.g. in NFV environment), then it is not scalable to have Service Chain path to specify the specific instances. The instances selection should be left up to implementation, or at least out of the SFC WG scope. =20 Linda =20 From: Paul Quinn (paulq) [mailto:paulq@cisco.com] To contextualize my comments: Assuming you needed to insert a CDN into a chain and had 8 equally viable instances (cdn1..cdn8), I see two primary methods of choosing which instance receives a particular flow: 1. The chain includes either the pool of services (CDN) or a shim service (proxy, service lb) where the specific instance is selected on the fly 2. The specific instance is part of the chain (cdn1) =20 If the latter (instance in chain), should SFC include a mechanism for remapping the chain to use another instance? In either case, should the selection of the instance ("service distribution"? anyone? anyone?) be part of SFC or left up to implementation? =20 =20 =20 It depends :) In case #1, does the "shim service" present itself as a SF? It might still have policy dependencies about being coupled with cdn, but is it externally "visible"? =20 Since we've already discussed dynamically inserting and removing services into or from a chain (long flow use cases draft), it seems that specifying the specific service instance in a chain (#1 above) for a flow would be simpler than introducing a shim proxyish service. This approach might also simplify the requirements for stateful v non-stateful services. =20 ________________________________________ From: Ron_Parker@affirmednetworks.com To: Joel M. Halpern,Linda Dunbar,Cathy Zhang,Paul Quinn (paulq),Jim Guichard (jguichar) cc: sfc@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 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 > 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 > https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc =20 From linda.dunbar@huawei.com Fri Jan 24 09:15:11 2014 Return-Path: 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 8ECD51A0008 for ; Fri, 24 Jan 2014 09:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.135 X-Spam-Level: X-Spam-Status: No, score=-4.135 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, RP_MATCHES_RCVD=-0.535, 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 7yngu558e7I1 for ; Fri, 24 Jan 2014 09:15:07 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCFC1A00B8 for ; Fri, 24 Jan 2014 09:15:05 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCW87368; Fri, 24 Jan 2014 17:15:03 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 17:14:42 +0000 Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Jan 2014 17:15:01 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml704-chm.china.huawei.com ([169.254.6.202]) with mapi id 14.03.0158.001; Fri, 24 Jan 2014 09:14:44 -0800 From: Linda Dunbar To: Jerome Moisand , "mikebianc@aol.com" , "Ron_Parker@affirmednetworks.com" , "jmh@joelhalpern.com" , Cathy Zhang , "paulq@cisco.com" , "jguichar@cisco.com" Thread-Topic: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 Thread-Index: AQHPFtz0BBXmRpg9rk2thNSnYBnFRZqPsP9wgAG25QCAAUIjgP//+sSwgAC0XgD//907sIAAjLcAgAArhjCAAJn6gIAAAxiA//+U1sA= Date: Fri, 24 Jan 2014 17:14:43 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C708A3@dfweml701-chm.china.huawei.com> References: <52E186B0.5020809@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C6F32D@dfweml701-chm.china.huawei.com> <52E1DF90.2070605@joelhalpern.com> <184198357.1683.1390576957523.JavaMail.tomcat@mgs-aaa01.mail.aol.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.117] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645C708A3dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 17:15:11 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645C708A3dfweml701chmchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCg0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBtaWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+DQoNCg0KVG8gYXZv aWQgZnVydGhlciBjb25mdXNpb24sIHNob3VsZCB3ZSByZWZlciB0byB0aGUgc2VsZWN0aW9uIG9m IGEgc2VydmljZSBpbnN0YW5jZSBhcyAic2VydmljZSBkaXN0cmlidXRpb24iIGluc3RlYWQgb2Yg ImxvYWQgYmFsYW5jaW5nIiB0byBjbGVhcmx5IGRpZmZlcmVudGlhdGUgdGhpcyBmcm9tIHRoZSAi bG9hZCBiYWxhbmNlciIgc2VydmljZT8NCg0KW0xpbmRhXSBEbyBmbG93cyBnbyB0aHJvdWdoIOKA nFNlcnZpY2UgRGlzdHJpYnV0aW9uIFBvaW504oCdIGJlZm9yZSBnb2luZyB0byBpbmRpdmlkdWFs IGluc3RhbmNlcz8gSWYgdGhlIHNlcnZpY2UgY2hhaW4gcGF0aCBpZGVudGlmeSB0aGUgaW5kaXZp ZHVhbCBpbnN0YW5jZXMsIHRoZW4gdGhlIOKAnHNlcnZpY2UgZGlzdHJpYnV0aW9u4oCdIGlzIG1v cmUgbGlrZSDigJxtYW5hZ2Vy4oCdIHJvbGUsIGkuZS4gdGhlIGRhdGEgZmxvd3MgZG9u4oCZdCBn byB0aHJvdWdoIHRoZSDigJxTZXJ2aWNlIERpc3RyaWJ1dGlvbuKAnSBwb2ludC4NCg0KTGluZGEN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IFJvbl9QYXJrZXJAYWZm aXJtZWRuZXR3b3Jrcy5jb208Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbTxtYWlsdG86 Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbSUzY1Jvbl9QYXJrZXJAYWZmaXJtZWRuZXR3 b3Jrcy5jb20+Pg0KVG86IEpvZWwgTS4gSGFscGVybjxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0 bzpqbWhAam9lbGhhbHBlcm4uY29tPj4sTGluZGEgRHVuYmFyPGxpbmRhLmR1bmJhckBodWF3ZWku Y29tPG1haWx0bzpsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbT4+LENhdGh5IFpoYW5nPENhdGh5Lkgu WmhhbmdAaHVhd2VpLmNvbTxtYWlsdG86Q2F0aHkuSC5aaGFuZ0BodWF3ZWkuY29tPj4sUGF1bCBR dWlubiAocGF1bHEpPHBhdWxxQGNpc2NvLmNvbTxtYWlsdG86cGF1bHFAY2lzY28uY29tPj4sSmlt IEd1aWNoYXJkIChqZ3VpY2hhcik8amd1aWNoYXJAY2lzY28uY29tPG1haWx0bzpqZ3VpY2hhckBj aXNjby5jb20+Pg0KY2M6IHNmY0BpZXRmLm9yZzxzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRm Lm9yZyUzY3NmY0BpZXRmLm9yZz4+DQpTZW50OiBGcmlkYXksIEphbnVhcnkgMjQsIDIwMTQNClN1 YmplY3Q6IFJlOiBbc2ZjXSBXRyBhZG9wdGlvbiBvZiBkcmFmdC1xdWlubi1zZmMtcHJvYmxlbS1z dGF0ZW1lbnQtMDINCg0KSGksIEpvZWwuDQoNCkkgdGhpbmsgeW91IHJhaXNlIGFuIGV4Y2VsbGVu dCBwb2ludCBvbiB0aGUgYW1iaWd1aXR5IG9mIGxvYWQgYmFsYW5jaW5nLiAgIEkgd291bGQgcHJv cG9zZSB0aGF0IHRoZXJlIGFyZSBtb3JlIHRoYW4gMiBjYXNlcyBvZiBsb2FkIGJhbGFuY2luZzoN Cg0KKiBtaWQtYm94IHNlcnZpY2UgZnVuY3Rpb24gKGUuZy4sIGZpcmV3YWxsKSB3aXRoIGludGVy bmFsIGxvYWQgYmFsYW5jaW5nDQoqIG1pZC1ib3ggc2VydmljZSBmdW5jdGlvbiAoZS5nLiwgZmly ZXdhbGwpIHJlcXVpcmluZyBleHRlcm5hbCBsb2FkIGJhbGFuY2luZw0KKiBleHBsaWNpdGx5IGFk ZHJlc3NlZCBzZXJ2aWNlIChlLmcuLCBEQiBzZXJ2ZXIpIHdpdGggaW50ZXJuYWwgbG9hZCBiYWxh bmNpbmcNCiogZXhwbGljaXRseSBhZGRyZXNzZWQgc2VydmljZSAoZS5nLiwgV2ViIEhUVFAgc2Vy dmVyKSByZXF1aXJpbmcgZXh0ZXJuYWwgbG9hZCBiYWxhbmNpbmcNCg0KRnJvbSBhbiBTRkMgcGVy c3BlY3RpdmUsIEkgdGhpbmsgd2UgY2FuIGlnbm9yZSB0aGUgY2FzZXMgd2hlcmUgdGhlIG1pZC1i b3ggb3IgZXhwbGljaXQgYXBwbGljYXRpb24gaXMgaW50ZXJuYWxseSBsb2FkIGJhbGFuY2VkLiAg IFN1Y2ggYXBwbGljYXRpb25zIHdvdWxkIHR5cGljYWxseSBwcmVzZW50IGEgc2luZ2xlIGxvY2F0 b3IgKGkuZS4sIElQIGFkZHJlc3MpIHRvIHRoZSBvdXRzaWRlIHdvcmxkIGFuZCBtYW5hZ2UgcmVk aXJlY3Rpb24gaW50ZXJuYWxseSB0byB0aGUgY2x1c3RlcmVkIGFwcGxpY2F0aW9uLg0KDQpJIHRo aW5rIHRoZSBsYXN0IGJ1bGxldCwgZXh0ZXJuYWwgbG9hZCBiYWxhbmNpbmcgZm9yIGFuIGV4cGxp Y2l0bHkgYWRkcmVzc2VkIHNlcnZpY2UgKGUuZy4sIFdlYiBIVFRQIHNlcnZlcikgbGVuZHMgaXRz ZWxmIHRvIGxvYWQgYmFsYW5jaW5nIGFzIGFuIGV4cGxpY2l0IHNlcnZpY2UgZnVuY3Rpb24gZnJv bSBhbiBTRkMgcGVyc3BlY3RpdmUuICAgVGhhdCBpcywgdGhlIHNlcnZpY2UgZnVuY3Rpb24gaW4g dGhlIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW4gaXMgImxvYWQgYmFsYW5jZXIiLg0KDQpUaGUgc2Vj b25kIGJ1bGxldCwgZXh0ZXJuYWwgbG9hZCBiYWxhbmNpbmcgZm9yIG1pZC1ib3ggc2VydmljZSBm dW5jdGlvbiAoZS5nLiwgZmlyZXdhbGwpLCBpcyBzbGlnaHRseSB0cmlja2llci4gICBGcm9tIGFu IFNGQyBwZXJzcGVjdGl2ZSwgbXkgdmlldyBpcyB0aGF0IHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIHRo YXQgYXBwZWFycyBpbiB0aGUgc2VydmljZSBmdW5jdGlvbiBjaGFpbiBpcyBzdGlsbCBmaXJld2Fs bCBhbmQgbm90IGxvYWQgYmFsYW5jZXIuICAgSG93ZXZlciwgSSBkbyB0aGluayB0aGF0IFNGQyBz aG91bGQgZXhwbGljaXRseSBlbWJyYWNlIHRoZSBjb25jZXB0IG9mIGEgImxvYWQtYmFsYW5jZWQg c2VydmljZSBmdW5jdGlvbiIuICAgSSB0cmllZCB0byBhZGRyZXNzIHRoaXMgaW4gaHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wYXJrZXItc2ZjLWNoYWluLXRvLXBhdGgvIGFu ZCB3b3VsZCBhcHByZWNpYXRlIGFueSBmZWVkYmFjay4NCg0KVGhhbmtzLg0KDQogIFJvbg0KDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCg0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2VsIE0uIEhhbHBlcm4NClNlbnQ6IFRodXJz ZGF5LCBKYW51YXJ5IDIzLCAyMDE0IDEwOjM2IFBNDQpUbzogTGluZGEgRHVuYmFyOyBDYXRoeSBa aGFuZzsgUGF1bCBRdWlubiAocGF1bHEpOyBKaW0gR3VpY2hhcmQgKGpndWljaGFyKQ0KQ2M6IHNm Y0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzZmNdIFdHIGFk b3B0aW9uIG9mIGRyYWZ0LXF1aW5uLXNmYy1wcm9ibGVtLXN0YXRlbWVudC0wMg0KDQpGb3IgYXBw cyB0aGF0IGhhdmUgdGhlaXIgb3duIGludGVybmFsIGxvYWQgYmFsYW5jZXIsIEkgYWdyZWUgdGhh dCB0aGVyZSBpcyBubyBwb2ludCBpbiB0aGUgdGVuYW50IHVzaW5nIHRoZSBkYXRhIGNlbnRlciBv ZmZlcmVkIGxvYWQgYmFsYW5jZXIgc2VydmljZS4NCkJ1dCBtYW55IGFwcHMgZG8gbm90IGhhdmUg dGhlaXIgb3duIGN1c3RvbSBsb2FkIGJhbGFuY2VyLiBTbyBhIGRhdGEgY2VudGVyIG1pZ2h0IHdl bGwgb2ZmZXIgbG9hZCBiYWxhbmNpbmcgYXMgYSBzZXJ2aWNlIGZvciB0aG9zZSB0ZW5hbnRzIHdo byB3YW50IGl0Lg0KDQpNeSBvbmx5IHBvaW50IHdhcyB0byBkaXN0aW5ndWlzaCBsb2FkIGJhbGFu Y2luZyBhcyBhIHNlcnZpY2Ugc2VsZWN0ZWQgYnkgdGhlIGN1c3RvbWVyIGZyb20gbG9hZCBiYWxh bmNpbmcgdXNlZCBieSB0aGUgb2VwcmF0b3IgaW50ZXJuYWxsO3kgdG8gZGVsaXZlciBzb21lIG90 aGVyIHNlcnZpY2UuDQoNCllvdXJzLA0KSm9lbA0KDQpPbiAxLzIzLzE0IDEwOjE4IFBNLCBMaW5k YSBEdW5iYXIgd3JvdGU6DQo+IEpvZWwsDQo+IFF1ZXN0aW9ucyBpbnNlcnRlZCBiZWxvdzoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2VsIE0uIEhhbHBlcm4NCj4gU2VudDogVGh1cnNk YXksIEphbnVhcnkgMjMsIDIwMTQgMzoxNyBQTQ0KPiBUbzogQ2F0aHkgWmhhbmc7IFBhdWwgUXVp bm4gKHBhdWxxKTsgSmltIEd1aWNoYXJkIChqZ3VpY2hhcikNCj4gQ2M6IHNmY0BpZXRmLm9yZzxt YWlsdG86c2ZjQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW3NmY10gV0cgYWRvcHRpb24gb2Yg ZHJhZnQtcXVpbm4tc2ZjLXByb2JsZW0tc3RhdGVtZW50LTAyDQo+IEluIGxvb2tpbmcgYXQgdGhl IHNlcnZpY2VzLCB3ZSBuZWVkIHRvIGJlIGNhcmVmdWwgYWJvdXQgd2hvIHRoZQ0KPiBzZXJ2aWNl IGlzIGZvci4gVXNpbmcgbG9hZCBiYWxhbmNpbmcgYXMgYW4gZXhhbXBsZSwgdGhlcmUgYXJlIHR3 byBkaWZmZXJlbnQgY2FzZXMuDQo+IE9uZSBjYXNlLCBjb21tb24gaW4gYSBkYXRhIGNlbnRlciwg d2lsbCBidyB3aGVyZSBsb2FkIGJhbG5jaW5nIGlzDQo+IHBhcnQgb2YgdGhlIHNlcnZpY2UgYmVp bmcgZGVsaXZlcmVkIHRvIHRoZSB0ZW5hbnQsIHRvIGhlbHAgbWFuYWdlIHRoZQ0KPiB0ZW5hbnRz IGFwcGxpY2F0aW9uIHRyYWZmaWMuDQo+IFtMaW5kYV0gZG8geW91IG1lYW4gd2hlbiAiTG9hZCBC YWxhbmNpbmciIGFtb25nIGNsdXN0ZXIgb2Ygc2VydmVycyBmb3INCj4gb25lIHRlbmFudCBhcHBs aWNhdGlvbiBiZWluZyBvZmZlcmVkIGFzIGEgc2VydmljZT8NCj4gSXNuJ3QgdGhpcyBraW5kIG9m ICJsb2FkIGJhbGFuY2luZyIgYXBwbGljYXRpb24gc3BlY2lmaWM/IExpa2UgT3JhY2xlDQo+IERC IGhhcyBpdHMgb3duIExvYWQgQmFsYW5jZXIgYW1vbmcgY2x1c3RlciBvZiBzZXJ2ZXJzLg0KPiBB IGRpZmZlcmVudCBzaXR1YXRpb24gaXMgd2hlbiBsb2FkIGJhbGFuY2luZyBpcyB1c2VkIGludGVy bmFsbHkgdG8gdGhlDQo+IHNlcnZpY2UgY2hhaW5pbmcgdG8gbWFuYWdlIGluc3RhbmNlcyBvZiB0 aGUgaW50ZXJuYWwgc2VydmljZXMgKHdoZXJlDQo+IGNhcmRpbmFsaXR5IGlzIGludmlzaWJsZSB0 byB0aGUgdGVuYW50IC8gdXNlcikuDQo+IEluIHRoZSBmb3JtZXIgY2FzZSwgTEIgaXMgYSBzZXJ2 aWNlLiBBbmQgaGFzIHRvIGJlIGFibGUgdG8gZGlyZWN0DQo+IHRyYWZmaWMgdG8gdGhlIGNvcnJl Y3QgdGVuYW50IGFwcGxpY2F0aW9uIGluc3RhbmNlLg0KPiBJbiB0aGUgbGF0dGVyIGNhc2UsIHRo ZSBsb2FkIGJhbGFuY2luZyBtYXkgd2VsbCBiZSBidW5kbGVkIGluIHdpdGggYQ0KPiBjb2xsZWN0 aW9uIG9mIGNvLWxvY2F0ZWQgc2VydmljZSBpbnN0YW5jZXMsIHdpdGggdGhlIHdob2xlIGxvb2tp bmcNCj4gbGlrZSBhIHNlcnZpY2UgaW5zdGFuY2UgdG8gc2VydmljZSBjaGFpbmluZyBhbmQgdGhl IGVuZCB1c2VyLiAoVGhlcmUNCj4gYXBwZWFyIHRvIGJlIGEgbXVsdGlwbGljaXR5IG9mIHdheXMg dG8gZGVsaXZlciB0aGlzIGJlaGF2aW9yLiBIb3cNCj4gbXVjaCB3ZSBuZWVkIHRvIHNwZWNpZnkg aW4gdGhlIGFyY2hpdGVjdHVyZSByZW1haW5zIHRvIGJlIHNlZW4uKQ0KPiBZb3VycywgSm9lbCBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzZmMgbWFp bGluZyBsaXN0DQo+IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiA8bWFpbHRvOnNm Y0BpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFp bGluZyBsaXN0DQpzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnPG1h aWx0bzpzZmNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYw0K --_000_4A95BA014132FF49AE685FAB4B9F17F645C708A3dfweml701chmchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNv QWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFs bG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0K c3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxT dHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNmYyBbPGEgaHJlZj0ibWFpbHRv OnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0K PGI+T24gQmVoYWxmIE9mIDwvYj48YSBocmVmPSJtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20iPm1p a2ViaWFuY0Bhb2wuY29tPC9hPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5UbyBhdm9pZCBmdXJ0aGVyIGNvbmZ1c2lvbiwgc2hvdWxkIHdl IHJlZmVyIHRvIHRoZSBzZWxlY3Rpb24gb2YgYSBzZXJ2aWNlIGluc3RhbmNlIGFzICZxdW90O3Nl cnZpY2UgZGlzdHJpYnV0aW9uJnF1b3Q7IGluc3RlYWQgb2YgJnF1b3Q7bG9hZCBiYWxhbmNpbmcm cXVvdDsgdG8gY2xlYXJseQ0KIGRpZmZlcmVudGlhdGUgdGhpcyBmcm9tIHRoZSAmcXVvdDtsb2Fk IGJhbGFuY2VyJnF1b3Q7IHNlcnZpY2U/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0xpbmRhXSBEbyBmbG93cyBnbyB0 aHJvdWdoIOKAnFNlcnZpY2UgRGlzdHJpYnV0aW9uIFBvaW504oCdIGJlZm9yZSBnb2luZyB0byBp bmRpdmlkdWFsIGluc3RhbmNlcz8gSWYgdGhlIHNlcnZpY2UgY2hhaW4gcGF0aCBpZGVudGlmeQ0K IHRoZSBpbmRpdmlkdWFsIGluc3RhbmNlcywgdGhlbiB0aGUg4oCcc2VydmljZSBkaXN0cmlidXRp b27igJ0gaXMgbW9yZSBsaWtlIOKAnG1hbmFnZXLigJ0gcm9sZSwgaS5lLiB0aGUgZGF0YSBmbG93 cyBkb27igJl0IGdvIHRocm91Z2ggdGhlIOKAnFNlcnZpY2UgRGlzdHJpYnV0aW9u4oCdIHBvaW50 Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+TGluZGENCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9Im1hcmdpbi1ib3R0b206Ni43NXB0Ij4NCjxkaXYgY2xh c3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4N CjxociBzaXplPSIxIiB3aWR0aD0iMTAwJSIgbm9zaGFkZT0iIiBzdHlsZT0iY29sb3I6Izk5OTk5 OSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206Ni43NXB0Ij48Yj5Gcm9tOiA8L2I+PGEgaHJlZj0ibWFpbHRv OlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20lM2NSb25fUGFya2VyQGFmZmlybWVkbmV0 d29ya3MuY29tIj5Sb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tJmx0O1Jvbl9QYXJrZXJA YWZmaXJtZWRuZXR3b3Jrcy5jb208L2E+Jmd0Ozxicj4NCjxiPlRvOiA8L2I+Sm9lbCBNLiBIYWxw ZXJuJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhAam9lbGhhbHBl cm4uY29tPC9hPiZndDssTGluZGEgRHVuYmFyJmx0OzxhIGhyZWY9Im1haWx0bzpsaW5kYS5kdW5i YXJAaHVhd2VpLmNvbSI+bGluZGEuZHVuYmFyQGh1YXdlaS5jb208L2E+Jmd0OyxDYXRoeSBaaGFu ZyZsdDs8YSBocmVmPSJtYWlsdG86Q2F0aHkuSC5aaGFuZ0BodWF3ZWkuY29tIj5DYXRoeS5ILlpo YW5nQGh1YXdlaS5jb208L2E+Jmd0OyxQYXVsDQogUXVpbm4gKHBhdWxxKSZsdDs8YSBocmVmPSJt YWlsdG86cGF1bHFAY2lzY28uY29tIj5wYXVscUBjaXNjby5jb208L2E+Jmd0OyxKaW0gR3VpY2hh cmQgKGpndWljaGFyKSZsdDs8YSBocmVmPSJtYWlsdG86amd1aWNoYXJAY2lzY28uY29tIj5qZ3Vp Y2hhckBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPmNjOiA8L2I+PGEgaHJlZj0ibWFpbHRvOnNm Y0BpZXRmLm9yZyUzY3NmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnJmx0O3NmY0BpZXRmLm9yZzwv YT4mZ3Q7PGJyPg0KPGI+U2VudDogPC9iPkZyaWRheSwgSmFudWFyeSAyNCwgMjAxNDxicj4NCjxi PlN1YmplY3Q6IDwvYj5SZTogW3NmY10gV0cgYWRvcHRpb24gb2YgZHJhZnQtcXVpbm4tc2ZjLXBy b2JsZW0tc3RhdGVtZW50LTAyPGJyPg0KPGJyPg0KSGksIEpvZWwuPGJyPg0KPGJyPg0KSSB0aGlu ayB5b3UgcmFpc2UgYW4gZXhjZWxsZW50IHBvaW50IG9uIHRoZSBhbWJpZ3VpdHkgb2YgbG9hZCBi YWxhbmNpbmcuICZuYnNwOyBJIHdvdWxkIHByb3Bvc2UgdGhhdCB0aGVyZSBhcmUgbW9yZSB0aGFu IDIgY2FzZXMgb2YgbG9hZCBiYWxhbmNpbmc6PGJyPg0KPGJyPg0KKiBtaWQtYm94IHNlcnZpY2Ug ZnVuY3Rpb24gKGUuZy4sIGZpcmV3YWxsKSB3aXRoIGludGVybmFsIGxvYWQgYmFsYW5jaW5nPGJy Pg0KKiBtaWQtYm94IHNlcnZpY2UgZnVuY3Rpb24gKGUuZy4sIGZpcmV3YWxsKSByZXF1aXJpbmcg ZXh0ZXJuYWwgbG9hZCBiYWxhbmNpbmc8YnI+DQoqIGV4cGxpY2l0bHkgYWRkcmVzc2VkIHNlcnZp Y2UgKGUuZy4sIERCIHNlcnZlcikgd2l0aCBpbnRlcm5hbCBsb2FkIGJhbGFuY2luZzxicj4NCiog ZXhwbGljaXRseSBhZGRyZXNzZWQgc2VydmljZSAoZS5nLiwgV2ViIEhUVFAgc2VydmVyKSByZXF1 aXJpbmcgZXh0ZXJuYWwgbG9hZCBiYWxhbmNpbmc8YnI+DQo8YnI+DQpGcm9tIGFuIFNGQyBwZXJz cGVjdGl2ZSwgSSB0aGluayB3ZSBjYW4gaWdub3JlIHRoZSBjYXNlcyB3aGVyZSB0aGUgbWlkLWJv eCBvciBleHBsaWNpdCBhcHBsaWNhdGlvbiBpcyBpbnRlcm5hbGx5IGxvYWQgYmFsYW5jZWQuICZu YnNwOyBTdWNoIGFwcGxpY2F0aW9ucyB3b3VsZCB0eXBpY2FsbHkgcHJlc2VudCBhIHNpbmdsZSBs b2NhdG9yIChpLmUuLCBJUCBhZGRyZXNzKSB0byB0aGUgb3V0c2lkZSB3b3JsZCBhbmQgbWFuYWdl IHJlZGlyZWN0aW9uIGludGVybmFsbHkNCiB0byB0aGUgY2x1c3RlcmVkIGFwcGxpY2F0aW9uLiAm bmJzcDsmbmJzcDsgPGJyPg0KPGJyPg0KSSB0aGluayB0aGUgbGFzdCBidWxsZXQsIGV4dGVybmFs IGxvYWQgYmFsYW5jaW5nIGZvciBhbiBleHBsaWNpdGx5IGFkZHJlc3NlZCBzZXJ2aWNlIChlLmcu LCBXZWIgSFRUUCBzZXJ2ZXIpIGxlbmRzIGl0c2VsZiB0byBsb2FkIGJhbGFuY2luZyBhcyBhbiBl eHBsaWNpdCBzZXJ2aWNlIGZ1bmN0aW9uIGZyb20gYW4gU0ZDIHBlcnNwZWN0aXZlLiAmbmJzcDsg VGhhdCBpcywgdGhlIHNlcnZpY2UgZnVuY3Rpb24gaW4gdGhlIHNlcnZpY2UgZnVuY3Rpb24gY2hh aW4NCiBpcyAmcXVvdDtsb2FkIGJhbGFuY2VyJnF1b3Q7Ljxicj4NCjxicj4NClRoZSBzZWNvbmQg YnVsbGV0LCBleHRlcm5hbCBsb2FkIGJhbGFuY2luZyBmb3IgbWlkLWJveCBzZXJ2aWNlIGZ1bmN0 aW9uIChlLmcuLCBmaXJld2FsbCksIGlzIHNsaWdodGx5IHRyaWNraWVyLiAmbmJzcDsgRnJvbSBh biBTRkMgcGVyc3BlY3RpdmUsIG15IHZpZXcgaXMgdGhhdCB0aGUgc2VydmljZSBmdW5jdGlvbiB0 aGF0IGFwcGVhcnMgaW4gdGhlIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW4gaXMgc3RpbGwgZmlyZXdh bGwgYW5kIG5vdCBsb2FkIGJhbGFuY2VyLg0KICZuYnNwOyBIb3dldmVyLCBJIGRvIHRoaW5rIHRo YXQgU0ZDIHNob3VsZCBleHBsaWNpdGx5IGVtYnJhY2UgdGhlIGNvbmNlcHQgb2YgYSAmcXVvdDts b2FkLWJhbGFuY2VkIHNlcnZpY2UgZnVuY3Rpb24mcXVvdDsuICZuYnNwOyBJIHRyaWVkIHRvIGFk ZHJlc3MgdGhpcyBpbg0KPGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1wYXJrZXItc2ZjLWNoYWluLXRvLXBhdGgiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtcGFya2VyLXNmYy1jaGFpbi10by1wYXRoPC9hPi8gYW5kIHdvdWxkIGFwcHJl Y2lhdGUgYW55IGZlZWRiYWNrLjxicj4NCjxicj4NClRoYW5rcy48YnI+DQo8YnI+DQombmJzcDsg Um9uPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQo8YnI+ DQo8YnI+DQpGcm9tOiBzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+ bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIEpvZWwgTS4gSGFs cGVybjxicj4NClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDIzLCAyMDE0IDEwOjM2IFBNPGJyPg0K VG86IExpbmRhIER1bmJhcjsgQ2F0aHkgWmhhbmc7IFBhdWwgUXVpbm4gKHBhdWxxKTsgSmltIEd1 aWNoYXJkIChqZ3VpY2hhcik8YnI+DQpDYzogPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+ c2ZjQGlldGYub3JnPC9hPjxicj4NClN1YmplY3Q6IFJlOiBbc2ZjXSBXRyBhZG9wdGlvbiBvZiBk cmFmdC1xdWlubi1zZmMtcHJvYmxlbS1zdGF0ZW1lbnQtMDI8YnI+DQo8YnI+DQpGb3IgYXBwcyB0 aGF0IGhhdmUgdGhlaXIgb3duIGludGVybmFsIGxvYWQgYmFsYW5jZXIsIEkgYWdyZWUgdGhhdCB0 aGVyZSBpcyBubyBwb2ludCBpbiB0aGUgdGVuYW50IHVzaW5nIHRoZSBkYXRhIGNlbnRlciBvZmZl cmVkIGxvYWQgYmFsYW5jZXIgc2VydmljZS48YnI+DQpCdXQgbWFueSBhcHBzIGRvIG5vdCBoYXZl IHRoZWlyIG93biBjdXN0b20gbG9hZCBiYWxhbmNlci4gU28gYSBkYXRhIGNlbnRlciBtaWdodCB3 ZWxsIG9mZmVyIGxvYWQgYmFsYW5jaW5nIGFzIGEgc2VydmljZSBmb3IgdGhvc2UgdGVuYW50cyB3 aG8gd2FudCBpdC48YnI+DQo8YnI+DQpNeSBvbmx5IHBvaW50IHdhcyB0byBkaXN0aW5ndWlzaCBs b2FkIGJhbGFuY2luZyBhcyBhIHNlcnZpY2Ugc2VsZWN0ZWQgYnkgdGhlIGN1c3RvbWVyIGZyb20g bG9hZCBiYWxhbmNpbmcgdXNlZCBieSB0aGUgb2VwcmF0b3IgaW50ZXJuYWxsO3kgdG8gZGVsaXZl ciBzb21lIG90aGVyIHNlcnZpY2UuPGJyPg0KPGJyPg0KWW91cnMsPGJyPg0KSm9lbDxicj4NCjxi cj4NCk9uIDEvMjMvMTQgMTA6MTggUE0sIExpbmRhIER1bmJhciB3cm90ZTo8YnI+DQomZ3Q7IEpv ZWwsPGJyPg0KJmd0OyBRdWVzdGlvbnMgaW5zZXJ0ZWQgYmVsb3c6PGJyPg0KJmd0OyAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogc2ZjIFs8YSBocmVmPSJtYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9u IEJlaGFsZiBPZiBKb2VsIE0uIEhhbHBlcm48YnI+DQomZ3Q7IFNlbnQ6IFRodXJzZGF5LCBKYW51 YXJ5IDIzLCAyMDE0IDM6MTcgUE08YnI+DQomZ3Q7IFRvOiBDYXRoeSBaaGFuZzsgUGF1bCBRdWlu biAocGF1bHEpOyBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTxicj4NCiZndDsgQ2M6IDxhIGhyZWY9 Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IFN1YmplY3Q6 IFJlOiBbc2ZjXSBXRyBhZG9wdGlvbiBvZiBkcmFmdC1xdWlubi1zZmMtcHJvYmxlbS1zdGF0ZW1l bnQtMDI8YnI+DQomZ3Q7IEluIGxvb2tpbmcgYXQgdGhlIHNlcnZpY2VzLCB3ZSBuZWVkIHRvIGJl IGNhcmVmdWwgYWJvdXQgd2hvIHRoZSA8YnI+DQomZ3Q7IHNlcnZpY2UgaXMgZm9yLiBVc2luZyBs b2FkIGJhbGFuY2luZyBhcyBhbiBleGFtcGxlLCB0aGVyZSBhcmUgdHdvIGRpZmZlcmVudCBjYXNl cy48YnI+DQomZ3Q7IE9uZSBjYXNlLCBjb21tb24gaW4gYSBkYXRhIGNlbnRlciwgd2lsbCBidyB3 aGVyZSBsb2FkIGJhbG5jaW5nIGlzIDxicj4NCiZndDsgcGFydCBvZiB0aGUgc2VydmljZSBiZWlu ZyBkZWxpdmVyZWQgdG8gdGhlIHRlbmFudCwgdG8gaGVscCBtYW5hZ2UgdGhlIDxicj4NCiZndDsg dGVuYW50cyBhcHBsaWNhdGlvbiB0cmFmZmljLjxicj4NCiZndDsgW0xpbmRhXSBkbyB5b3UgbWVh biB3aGVuICZxdW90O0xvYWQgQmFsYW5jaW5nJnF1b3Q7IGFtb25nIGNsdXN0ZXIgb2Ygc2VydmVy cyBmb3IgPGJyPg0KJmd0OyBvbmUgdGVuYW50IGFwcGxpY2F0aW9uIGJlaW5nIG9mZmVyZWQgYXMg YSBzZXJ2aWNlPzxicj4NCiZndDsgSXNuJ3QgdGhpcyBraW5kIG9mICZxdW90O2xvYWQgYmFsYW5j aW5nJnF1b3Q7IGFwcGxpY2F0aW9uIHNwZWNpZmljPyBMaWtlIE9yYWNsZSA8YnI+DQomZ3Q7IERC IGhhcyBpdHMgb3duIExvYWQgQmFsYW5jZXIgYW1vbmcgY2x1c3RlciBvZiBzZXJ2ZXJzLjxicj4N CiZndDsgQSBkaWZmZXJlbnQgc2l0dWF0aW9uIGlzIHdoZW4gbG9hZCBiYWxhbmNpbmcgaXMgdXNl ZCBpbnRlcm5hbGx5IHRvIHRoZSA8YnI+DQomZ3Q7IHNlcnZpY2UgY2hhaW5pbmcgdG8gbWFuYWdl IGluc3RhbmNlcyBvZiB0aGUgaW50ZXJuYWwgc2VydmljZXMgKHdoZXJlIDxicj4NCiZndDsgY2Fy ZGluYWxpdHkgaXMgaW52aXNpYmxlIHRvIHRoZSB0ZW5hbnQgLyB1c2VyKS48YnI+DQomZ3Q7IElu IHRoZSBmb3JtZXIgY2FzZSwgTEIgaXMgYSBzZXJ2aWNlLiBBbmQgaGFzIHRvIGJlIGFibGUgdG8g ZGlyZWN0IDxicj4NCiZndDsgdHJhZmZpYyB0byB0aGUgY29ycmVjdCB0ZW5hbnQgYXBwbGljYXRp b24gaW5zdGFuY2UuPGJyPg0KJmd0OyBJbiB0aGUgbGF0dGVyIGNhc2UsIHRoZSBsb2FkIGJhbGFu Y2luZyBtYXkgd2VsbCBiZSBidW5kbGVkIGluIHdpdGggYSA8YnI+DQomZ3Q7IGNvbGxlY3Rpb24g b2YgY28tbG9jYXRlZCBzZXJ2aWNlIGluc3RhbmNlcywgd2l0aCB0aGUgd2hvbGUgbG9va2luZyA8 YnI+DQomZ3Q7IGxpa2UgYSBzZXJ2aWNlIGluc3RhbmNlIHRvIHNlcnZpY2UgY2hhaW5pbmcgYW5k IHRoZSBlbmQgdXNlci4gKFRoZXJlIDxicj4NCiZndDsgYXBwZWFyIHRvIGJlIGEgbXVsdGlwbGlj aXR5IG9mIHdheXMgdG8gZGVsaXZlciB0aGlzIGJlaGF2aW9yLiBIb3cgPGJyPg0KJmd0OyBtdWNo IHdlIG5lZWQgdG8gc3BlY2lmeSBpbiB0aGUgYXJjaGl0ZWN0dXJlIHJlbWFpbnMgdG8gYmUgc2Vl bi4pIDxicj4NCiZndDsgWW91cnMsIEpvZWwgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IHNmYyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxh IGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9 Im1haWx0bzpzZmNAaWV0Zi5vcmciPm1haWx0bzpzZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZn dDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2ZjIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzZmMgbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4A95BA014132FF49AE685FAB4B9F17F645C708A3dfweml701chmchi_-- From prvs=094dca163=Nicolas.BOUTHORS@qosmos.com Fri Jan 24 09:18:08 2014 Return-Path: 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 4B9EA1A04E5 for ; Fri, 24 Jan 2014 09:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 mRKnk004mALR for ; Fri, 24 Jan 2014 09:18:05 -0800 (PST) Received: from smtp-ft5.fr.colt.net (smtp-ft5.fr.colt.net [213.41.78.197]) by ietfa.amsl.com (Postfix) with ESMTP id 01DC91A04D5 for ; Fri, 24 Jan 2014 09:18:04 -0800 (PST) Received: from smtp-ex1.fr.colt.net (smtp-ex1.fr.colt.net [213.41.78.194]) by smtp-ft5.fr.colt.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s0OHI39M030159 for ; Fri, 24 Jan 2014 18:18:03 +0100 Received: from mx3.qosmos.fr ([195.68.92.43] helo=mx3.qosmos.com) by smtp-ex1.fr.colt.net with esmtp (Exim) (envelope-from ) id 1W6kOG-0006MF-2r for ; Fri, 24 Jan 2014 18:18:02 +0100 X-IronPort-AV: E=Sophos;i="4.95,713,1384297200"; d="scan'208,217";a="812414" Received: from unknown (HELO mailbox.jungle.qosmos.com) ([10.12.1.3]) by mx3.qosmos.com with ESMTP; 24 Jan 2014 18:18:01 +0100 Received: from LILAS.jungle.qosmos.com ([fe80::5524:2c18:b2c3:74d4]) by CAROUBIER.jungle.qosmos.com ([169.254.1.72]) with mapi id 14.01.0438.000; Fri, 24 Jan 2014 18:17:59 +0100 From: Nicolas BOUTHORS To: "mikebianc@aol.com" , "Ron_Parker@affirmednetworks.com" , "jmh@joelhalpern.com" , "linda.dunbar@huawei.com" , "Cathy.H.Zhang@huawei.com" , "paulq@cisco.com" , "jguichar@cisco.com" Thread-Topic: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 Thread-Index: AQHPGR/o58yRANKvS3CT2KvxYUAHhZqUFS+G Date: Fri, 24 Jan 2014 17:17:59 +0000 Message-ID: <76B41B8FACE1514795D30EC137FF391D3CFDBC@LILAS.jungle.qosmos.com> References: <204899072.8879.1390579493455.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: <204899072.8879.1390579493455.JavaMail.tomcat@mgs-aam01.mail.aol.com> Accept-Language: en-US, fr-FR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.0.22] Content-Type: multipart/alternative; boundary="_000_76B41B8FACE1514795D30EC137FF391D3CFDBCLILASjungleqosmos_" MIME-Version: 1.0 X-ACL-Warn: 1/1 recipients OK. Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 17:18:08 -0000 --_000_76B41B8FACE1514795D30EC137FF391D3CFDBCLILASjungleqosmos_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ________________________________ >To contextualize my comments: > Assuming you needed to insert a CDN into a chain and had 8 equally viable= instances (cdn1..cdn8), I see two primary methods > of choosing which instance receives a particular flow: > 1. The chain includes either the pool of services (CDN) or a shim servic= e (proxy, service lb) where the specific instance is > selected on the fly > 2. The specific instance is part of the chain (cdn1) Could this lead to "chaining chains"? Let's take the example of load balancing traffic to transparent proxies for= say, header insertion. (This is a classic case in Gi Networks). * The load balancer should be part of the service chain if the balancin= g algorithm dynamically selects the specific proxy instance (think of IP so= urce stickiness). On its way in, the proxies need then not be part of the = service chain. * On the way out, the proxy could be part of a second chain, since it c= reates a new TCP connection, thus avoiding to have to reroute the traffic b= ack to the load balancer. So: chain1 : GGSN - some services -LBS chain2: Proxy-other services- Internet FW In addition, the Proxy instances could have a responsibility to pass inform= ation (metadata?) from chain1 to chain 2. In particular when the second ser= vice chain should be selected based on the subscriber id, as there is no wa= y to identify this subscriber based on the networking information held in t= he traffic going out to the internet. How this would be possible is an ope= n question. Nicolas ________________________________ From: Ron_Parker@affirmednetworks.com To: Joel M. Halpern,Linda Dunbar,Cathy Zhang,Paul Quinn (paulq),Jim Guichard (jguichar) cc: sfc@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 balanci= ng * explicitly addressed service (e.g., DB server) with internal load balanci= ng * explicitly addressed service (e.g., Web HTTP server) requiring external l= oad 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 woul= d typically present a single locator (i.e., IP address) to the outside worl= d and manage redirection internally to the clustered application. I think the last bullet, external load balancing for an explicitly addresse= d service (e.g., Web HTTP server) lends itself to load balancing as an expl= icit service function from an SFC perspective. That is, the service functio= n 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 th= at the service function that appears in the service function chain is still= firewall and not load balancer. However, I do think that SFC should explic= itly 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-p= ath/ 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 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 th= e 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 > 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 differe= nt 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 > https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_76B41B8FACE1514795D30EC137FF391D3CFDBCLILASjungleqosmos_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


>To contextualize my co= mments:
> Assuming you needed to inse= rt a CDN into a chain and had 8 equally viable instances (cdn1..cdn8), I se= e two primary methods 
> of choosing which instance = receives a particular flow:
> 1.  The chain includes= either the pool of services (CDN) or a shim service (proxy, service lb) wh= ere the specific instance is
>      selecte= d on the fly
> 2. The specific instance is= part of the chain (cdn1)

Could this lead to &qu= ot;chaining chains"? 

Let's take the example= of load balancing traffic to transparent proxies for say, header insertion= . (This is a classic case in Gi Networks).
  • The load balancer should be part of the service chain if the balancing = algorithm dynamically selects the specific proxy instance (think of IP sour= ce stickiness).  On its way in, the proxies need then not be part of t= he service chain.
  • On the way out, the proxy could be part of a second chain, since = it creates a new TCP connection, thus avoiding to have to reroute the traff= ic b= ack to the load balancer.

So: chain1 :  GGS= N - some services -LBS
      c= hain2:  Proxy-other services- Internet FW

In addition, the Proxy= instances could have a responsibility to pass information (metadata?) from= chain1 to chain 2. In particular when the second service chain should be s= elected based on the subscriber id, as there is no way to identify this subscriber based on the networking inf= ormation held in the traffic going out to the internet.  How this woul= d be possible is an open question.

Nicolas



From: Ron_Parker@affirmednetworks.com<Ron_Pa= rker@affirmednetworks.com>
To: Joel M. Halpern<jmh@joelhalpern.com>,= Linda Dunbar<linda.dunbar@huawei.com>,Cathy Zhang<Cathy.H.Zhang@hu= awei.com>,Paul Quinn (paulq)<paulq@cisco.com>,Jim Guichard (jguichar)<jguichar@cisco.com>
cc: sfc@ietf.org<sfc@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 excell= ent point on the ambiguity of load balancing. I would propose that there ar= e 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 serv= ice (e.g., DB server) with internal load balancing
* explicitly addressed serv= ice (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 singl= e locator (i.e., IP address) to the outside world and manage redirection internally to the clustered applicati= on.

I think the last bullet, ex= ternal load balancing for an explicitly addressed service (e.g., Web HTTP s= erver) 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 tha= t appears in the service function chain is still firewall and not load balancer. However, I do think that SFC shou= ld explicitly embrace the concept of a "load-balanced service function= ". I tried to address this in ht= tp://datatracker.ietf.org/doc/draft-parker-sfc-chain-to-path/ and would appreciate any feedback.

Thanks.

Ron


-----Original Message-----<= /font>


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

For apps that have their ow= n internal load balancer, I agree that there is no point in the tenant usin= g the data center offered load balancer service.
But many apps do not have t= heir own custom load balancer. So a data center might well offer load balan= cing as a service for those tenants who want it.

My only point was to distin= guish load balancing as a service selected by the customer from load balanc= ing used by the oeprator internall;y to deliver some other service.<= br class=3D"">
Yours,
Joel

On 1/23/14 10:18 PM, Linda = Dunbar wrote:
> Joel,
> Questions inserted bel= ow:
> -----Original Message-= ----
> From: sfc [mailto:sfc-= bounces@ietf.org] On Behalf Of Joel M. Halpern
> Sent: Thursday, Januar= y 23, 2014 3:17 PM
> To: Cathy Zhang; Paul = Quinn (paulq); Jim Guichard (jguichar)
> Cc: sfc@ietf.org
> Subject: Re: [sfc] WG = adoption of draft-quinn-sfc-problem-statement-02
> In looking at the serv= ices, 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 be= ing delivered to the tenant, to help manage the
> tenants application tr= affic.
> [Linda] do you mean wh= en "Load Balancing" among cluster of servers for
> one tenant application= being offered as a service?
> Isn't this kind of &qu= ot;load balancing" application specific? Like Oracle
> DB has its own Load Ba= lancer among cluster of servers.
> A different situation = is when load balancing is used internally to the
> service chaining to ma= nage instances of the internal services (where
> cardinality is invisib= le 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, th= e load balancing may well be bundled in with a
> collection of co-locat= ed service instances, with the whole looking
> like a service instanc= e to service chaining and the end user. (There
> appear to be a multipl= icity of ways to deliver this behavior. How
> much we need to specif= y in the architecture remains to be seen.)
> Yours, Joel __________= _____________________________________
> sfc mailing list
> sfc@ietf.org <mailt= o:sfc@ietf.org>
> https://www.ietf.org/m= ailman/listinfo/sfc
___________________________= ____________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailma= n/listinfo/sfc
___________________________= ____________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailma= n/listinfo/sfc
--_000_76B41B8FACE1514795D30EC137FF391D3CFDBCLILASjungleqosmos_-- From mikebianc@aol.com Fri Jan 24 09:29:52 2014 Return-Path: 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 270BB1A008F for ; Fri, 24 Jan 2014 09:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.834 X-Spam-Level: X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 Ioon-wUtaiLI for ; Fri, 24 Jan 2014 09:29:48 -0800 (PST) Received: from omr-d09.mx.aol.com (omr-d09.mx.aol.com [205.188.108.133]) by ietfa.amsl.com (Postfix) with ESMTP id 66DBC1A003C for ; Fri, 24 Jan 2014 09:29:48 -0800 (PST) Received: from mtaout-mac02.mx.aol.com (mtaout-mac02.mx.aol.com [172.26.222.206]) by omr-d09.mx.aol.com (Outbound Mail Relay) with ESMTP id 10D8A701FB5EE; Fri, 24 Jan 2014 12:29:47 -0500 (EST) Received: from mgs-aad01.mail.aol.com (mgs-aad01.mail.aol.com [205.188.178.60]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-mac02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id B279C380000B0; Fri, 24 Jan 2014 12:29:46 -0500 (EST) Date: Fri, 24 Jan 2014 12:29:46 -0500 From: "mikebianc@aol.com" To: Nicolas.BOUTHORS@qosmos.com, Ron_Parker@affirmednetworks.com, jmh@joelhalpern.com, linda.dunbar@huawei.com, Cathy.H.Zhang@huawei.com, paulq@cisco.com, jguichar@cisco.com Message-ID: <27707091.9359.1390584586633.JavaMail.tomcat@mgs-aad01.mail.aol.com> In-Reply-To: <76B41B8FACE1514795D30EC137FF391D3CFDBC@LILAS.jungle.qosmos.com> References: <204899072.8879.1390579493455.JavaMail.tomcat@mgs-aam01.mail.aol.com> <76B41B8FACE1514795D30EC137FF391D3CFDBC@LILAS.jungle.qosmos.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9358_233571001.1390584586632" X-Originating-IP: 10.181.180.127, 205.188.60.49 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1390584587; bh=LNkQ9CyJ9cgrwqLiNiy2OHSgBVs0EmjURpq6E8zcqaY=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=VQC+4bT9Ez00CSCfIa52xbMGPKxyWLLQ89sYFBj0qcZJ/UzZry99z0FoMWPSC2Qpc uYqg4qeSNHY435pr8eJs4IX9aEQrZGFJxEznlt23ukeAu1q1xVCPaiDK8JEd6vnHXF uIDw3VaXfDuFDPE+qNh6HbxzTYc+FGwe/OvQhVUY= x-aol-sid: 3039ac1adece52e2a30a5e00 X-AOL-IP: 205.188.178.60 Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 17:29:52 -0000 ------=_Part_9358_233571001.1390584586632 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable We might want to be able to chain chains if the chain needs to extend throu= gh multiple entities. =C2=A0e.g. if you have one chain within the datacente= r, but then want to signal the backbone provider (not you) to add services = to the chain. =C2=A0Could be one big dynamic chain. =C2=A0Could be chained/= sequential chains. From: Nicolas.BOUTHORS@qosmos.com To: mikebianc@aol.com,Ron_Parker@affirmednetworks.com,jmh@joelhalpern.com,lin= da.dunbar@huawei.com,Cathy.H.Zhang@huawei.com,paulq@cisco.com,jguichar@cisco.com cc: sfc@ietf.org Sent: Friday, January 24, 2014 Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 >To contextualize my comments: > Assuming you needed to insert a CDN into a chain and had 8 equally viable= instances (cdn1..cdn8), I see two primary methods=20 > of choosing which instance receives a particular flow: > 1. The chain includes either the pool of services (CDN) or a shim servic= e (proxy, service lb) where the specific instance is > selected on the fly > 2. The specific instance is part of the chain (cdn1) Could this lead to "chaining chains"?=20 Let's take the example of load balancing traffic to transparent proxies for= say, header insertion. (This is a classic case in Gi Networks). The load balancer should be part of the service chain if the balancing algo= rithm dynamically selects the specific proxy instance (think of IP source s= tickiness). On its way in, the proxies need then not be part of the servic= e chain.On the way out, the proxy could be part of a second chain, since it= creates a new TCP connection, thus avoiding to have to reroute the traffic= back to the load balancer. So: chain1 : GGSN - some services -LBS chain2: Proxy-other services- Internet FW In addition, the Proxy instances could have a responsibility to pass inform= ation (metadata?) from chain1 to chain 2. In particular when the second ser= vice chain should be selected based on the subscriber id, as there is no way to identify this subscriber based on the networking inf= ormation held in the traffic going out to the internet. How this would be = possible is an open question. Nicolas From: Ron_Parker@affirmednetworks.com To: Joel M. Halpern,Linda Dunbar,Cathy Zhang,Paul Quinn (paulq),Jim Guichard (jguichar) cc: sfc@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 balanci= ng * explicitly addressed service (e.g., DB server) with internal load balanci= ng * explicitly addressed service (e.g., Web HTTP server) requiring external l= oad 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 woul= d typically present a single locator (i.e., IP address) to the outside world and manage redirection internally to the clustered applicati= on.=20 I think the last bullet, external load balancing for an explicitly addresse= d service (e.g., Web HTTP server) lends itself to load balancing as an expl= icit 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 th= at the service function that appears in the service function chain is still firewall and not load balancer. However, I do think that SFC shou= ld 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 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 th= e 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 > 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 differe= nt 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 > https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc ------=_Part_9358_233571001.1390584586632 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
We might want t= o be able to chain chains if the chain needs to extend through multiple ent= ities.  e.g. if you have one chain within the datacenter, but then wan= t to signal the backbone provider (not you) to add services to the chain. &= nbsp;Could be one big dynamic chain.  Could be chained/sequential chai= ns.





From: Nicolas.BOUTHORS@qosmos.com<Nicolas.BOUTH= ORS@qosmos.com>
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<lind= a.dunbar@huawei.com>,Cathy.H.Zhang@huawei.com<Cathy.H.Zhang@huawei.co= m>,paulq@cisco.com<paulq@cisco.com>,jguichar@cisco.com<jguichar= @cisco.com>
cc: sfc@ietf.org<sfc@ietf.org>
Sent: <= /b>Friday, January 24, 2014
Subject: Re: [sfc] WG adoption of dra= ft-quinn-sfc-problem-statement-02



>To contextualize my co= mments:
> Assuming you needed to inse= rt a CDN into a chain and had 8 equally viable instances (cdn1..cdn8), I se= e two primary methods
> of choosing which instance = receives a particular flow:
> 1. The chain includes eith= er the pool of services (CDN) or a shim service (proxy, service lb) where t= he specific instance is
> selected on the fly
> 2. The specific instance is= part of the chain (cdn1)

Could this lead to "ch= aining chains"?

Let's take the example= of load balancing traffic to transparent proxies for say, header insertion= . (This is a classic case in Gi Networks).
  • The load balancer should be part of the service chain if the balancing = algorithm dynamically selects the specific proxy instance (think of IP sour= ce stickiness). On its way in, the proxies need then not be part of the se= rvice chain.
  • On the way out, the proxy could be part of a second chain, since it cr= eates a new TCP connection, thus avoiding to have to reroute the traffic back to the load balancer.

So: chain1 : GGSN - s= ome services -LBS
chain2: Proxy-o= ther services- Internet FW

In addition, the Proxy= instances could have a responsibility to pass information (metadata?) from= chain1 to chain 2. In particular when the second service chain should be s= elected based on the subscriber id, as there is no way to identify this subscriber based on the networking inf= ormation held in the traffic going out to the internet. How this would be = possible is an open question.

Nicolas



From: Ron_Parker@affirmednetworks.com<Ron_Parker@affirmednetworks.com>
To: Joel M. Halpern<jmh@joelhalpern.com>,Linda Dunbar<linda.dunbar@huawei.com>,Cathy Zhang<<= a href=3D"mailto:Cathy.H.Zhang@huawei.com">Cathy.H.Zhang@huawei.com>= ,Paul Quinn (paulq)<paulq@cisco.com>,Jim Guichard (jguichar)<jguichar@cisco.com= >
cc: sfc@ietf.or= g<sfc@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 excell= ent point on the ambiguity of load balancing. I would propose that there ar= e 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 serv= ice (e.g., DB server) with internal load balancing
* explicitly addressed serv= ice (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 singl= e locator (i.e., IP address) to the outside world and manage redirection internally to the clustered applicati= on.

I think the last bullet, ex= ternal load balancing for an explicitly addressed service (e.g., Web HTTP s= erver) 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 tha= t appears in the service function chain is still firewall and not load balancer. However, I do think that SFC shou= ld explicitly embrace the concept of a "load-balanced service function". I = tried to address this in ht= tp://datatracker.ietf.org/doc/draft-parker-sfc-chain-to-path/ and would appreciate any feedback.

Thanks.

Ron


-----Original Message-----<= /font>


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 Zha= ng; Paul Quinn (paulq); Jim Guichard (jguichar)
Cc: sfc@ietf.org
Subject: Re: [sfc] WG adopt= ion of draft-quinn-sfc-problem-statement-02

For apps that have their ow= n internal load balancer, I agree that there is no point in the tenant usin= g the data center offered load balancer service.
But many apps do not have t= heir own custom load balancer. So a data center might well offer load balan= cing as a service for those tenants who want it.

My only point was to distin= guish load balancing as a service selected by the customer from load balanc= ing used by the oeprator internall;y to deliver some other service.<= br class=3D"">
Yours,
Joel

On 1/23/14 10:18 PM, Linda = Dunbar wrote:
> Joel,
> Questions inserted bel= ow:
> -----Original Message-= ----
> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of = Joel M. Halpern
> Sent: Thursday, Januar= y 23, 2014 3:17 PM
> To: Cathy Zhang; Paul = Quinn (paulq); Jim Guichard (jguichar)
> Cc: sfc@ietf.org
> Subject: Re: [sfc] WG = adoption of draft-quinn-sfc-problem-statement-02
> In looking at the serv= ices, 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 be= ing delivered to the tenant, to help manage the
> tenants application tr= affic.
> [Linda] do you mean wh= en "Load Balancing" among cluster of servers for
> one tenant application= being offered as a service?
> Isn't this kind of "lo= ad balancing" application specific? Like Oracle
> DB has its own Load Ba= lancer among cluster of servers.
> A different situation = is when load balancing is used internally to the
> service chaining to ma= nage instances of the internal services (where
> cardinality is invisib= le 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, th= e load balancing may well be bundled in with a
> collection of co-locat= ed service instances, with the whole looking
> like a service instanc= e to service chaining and the end user. (There
> appear to be a multipl= icity of ways to deliver this behavior. How
> much we need to specif= y in the architecture remains to be seen.)
> Yours, Joel __________= _____________________________________
> sfc mailing list
> sfc@ietf.org <mailto:sfc@i= etf.org>
> https://www.ietf.org/mailman/listinfo/sfc
___________________________= ____________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc
___________________________= ____________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc
------=_Part_9358_233571001.1390584586632-- From repenno@cisco.com Fri Jan 24 09:36:06 2014 Return-Path: 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 5F7041A0036 for ; Fri, 24 Jan 2014 09:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 lySr38a6dL4E for ; Fri, 24 Jan 2014 09:36:04 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 10E8C1A0006 for ; Fri, 24 Jan 2014 09:36:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5707; q=dns/txt; s=iport; t=1390584963; x=1391794563; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=Ge6wo0yVsC5956kFRNV+a4/uQVO/n9YxXuF0M2YWqQc=; b=QQjQGJJZS5/0vLiMrXUBAVfMTv9h+4XC1ldKLcr1lUkR3WHrWd6g73fo zY2BvZJzv6z0BGH7aLZfl/z8Ebv0p1g3IEjg3bEvMq+k33ke3dSvvO/TA lJbDq1+i9Ni2OuOe6ajZEXV9zU6PqxqTUImcic0/NV5Tm/U935hQIpEBc k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAFOk4lKtJXG8/2dsb2JhbABagkhEgQ6od5M+gQ0WdIIlAQIEVCUSAQgRAwECKDkUCQgCBAENBYdxAxHISBeMdoIFEQeEOAEDmCeSHoMtgio X-IronPort-AV: E=Sophos;i="4.95,713,1384300800"; d="scan'208,217";a="15320141" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-7.cisco.com with ESMTP; 24 Jan 2014 17:35:46 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0OHZk6D010523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Jan 2014 17:35:46 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.37]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Fri, 24 Jan 2014 11:35:46 -0600 From: "Reinaldo Penno (repenno)" To: Nicolas BOUTHORS , "mikebianc@aol.com" , "Ron_Parker@affirmednetworks.com" , "jmh@joelhalpern.com" , "linda.dunbar@huawei.com" , "Cathy.H.Zhang@huawei.com" , "Paul Quinn (paulq)" , "Jim Guichard (jguichar)" Thread-Topic: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 Thread-Index: AQHPGR/oBBXmRpg9rk2thNSnYBnFRZqUFS+G///sdAA= Date: Fri, 24 Jan 2014 17:35:45 +0000 Message-ID: In-Reply-To: <76B41B8FACE1514795D30EC137FF391D3CFDBC@LILAS.jungle.qosmos.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.118.183] Content-Type: multipart/alternative; boundary="_000_CF07E1F582CErepennociscocom_" MIME-Version: 1.0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 17:36:06 -0000 --_000_CF07E1F582CErepennociscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would say yes but not sure in the charter. There was no explicit discussion if a long chain can be broken (always?) in= to chains of one service function each. But that does not imply the revers= e, i.e., if multiple chains can be contracted into one long chain. From: Nicolas BOUTHORS > Date: Friday, January 24, 2014 at 9:17 AM To: "mikebianc@aol.com" >, "Ron_Parker@affirmednetworks.com" >, "jmh@joelhalpern.com" >, "linda.dunbar@huawei.com" >, "Cathy.H.Zhang@huawei.com" <= Cathy.H.Zhang@huawei.com>, "Paul Quinn (pa= ulq)" >, "Jim Guichard (jguichar)" = > Cc: "sfc@ietf.org" > Subject: Re: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 Could this lead to "chaining chains"? --_000_CF07E1F582CErepennociscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <508D5929A01E2744BE9B0CF1E067CD40@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

I would say yes but not sure in the charter. 

There was no explicit discussion if a long chain can be broken (always?) in= to chains of one service function each.  But that does not imply the r= everse, i.e., if multiple chains can be contracted into one long chain.

From: Nicolas BOUTHORS <Nicolas.BOUTHORS@qosmos.com>=
Date: Friday, January 24, 2014 at 9= :17 AM
To: "mikebianc@aol.com" <mikebianc@aol.com>, "Ron_Parker@affirmednetworks.com" <Ron_Parker@affirmednetworks.com>= ;, "jmh@joelhalpern.com"= <jmh@joelhalpern.com>, &q= uot;linda.dunbar@huawei.com&= quot; <linda.dunbar@huawei.co= m>, "Cathy.H.Zhang@huawei.com= " <Cathy.H.Zhang@hu= awei.com>, "Paul Quinn (paulq)" <paulq@cisco.com>, "Jim Guichard (jguichar)" &= lt;jguichar@cisco.com>
Cc: "sfc@ietf.org" <sfc@ietf.= org>
Subject: Re: [sfc] WG adoption of d= raft-quinn-sfc-problem-statement-02

Could this lead to "chaining chains"?  --_000_CF07E1F582CErepennociscocom_-- From mikebianc@aol.com Fri Jan 24 09:37:55 2014 Return-Path: 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 98A681A0036 for ; Fri, 24 Jan 2014 09:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 plWS2bnAu6DP for ; Fri, 24 Jan 2014 09:37:52 -0800 (PST) Received: from omr-m05.mx.aol.com (omr-m05.mx.aol.com [64.12.143.79]) by ietfa.amsl.com (Postfix) with ESMTP id 71D041A0006 for ; Fri, 24 Jan 2014 09:37:52 -0800 (PST) Received: from mtaout-mac02.mx.aol.com (mtaout-mac02.mx.aol.com [172.26.222.206]) by omr-m05.mx.aol.com (Outbound Mail Relay) with ESMTP id 4B0A2701BE60F; Fri, 24 Jan 2014 12:37:51 -0500 (EST) Received: from mgs-aaa01.mail.aol.com (mgs-aaa01.mail.aol.com [149.174.106.43]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-mac02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 2131A380000A7; Fri, 24 Jan 2014 12:37:51 -0500 (EST) Date: Fri, 24 Jan 2014 12:37:51 -0500 From: "mikebianc@aol.com" To: linda.dunbar@huawei.com, jmoisand@juniper.net, Ron_Parker@affirmednetworks.com, jmh@joelhalpern.com, Cathy.H.Zhang@huawei.com, paulq@cisco.com, jguichar@cisco.com Message-ID: <1225256676.2274.1390585071035.JavaMail.tomcat@mgs-aaa01.mail.aol.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C708A3@dfweml701-chm.china.huawei.com> References: <52E186B0.5020809@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C6F32D@dfweml701-chm.china.huawei.com> <52E1DF90.2070605@joelhalpern.com> <184198357.1683.1390576957523.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <4A95BA014132FF49AE685FAB4B9F17F645C708A3@dfweml701-chm.china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2273_409003516.1390585071034" X-Originating-IP: 10.181.180.127, 64.12.75.136 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1390585071; bh=cWh3NopR8UX/1ZKFV9eH0pWV5gC5eRhQB8xIJJ7eR/I=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=ciRubOAvqJhQF5zd2ePvqkBqICdi3Z6qOihDsskCNCt62uUuN8am9Ceu8RAxqtUbC hPhM89J43Ntr2wg6kOSaEb4bdRa7UkoJzzkPa1Y6rJYjWFOcZ/qjv/q1rdkA80LcXk IQKTejvra5KBHE1K7qe1qNhPZPJSvingtpqEkRow= x-aol-sid: 3039ac1adece52e2a4ef0f97 X-AOL-IP: 149.174.106.43 Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 17:37:55 -0000 ------=_Part_2273_409003516.1390585071034 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: linda.dunbar@huawei.com To: Jerome Moisand,mikebianc@aol.com,Ron_Parker@affirmednetworks.com,jmh@joe= lhalpern.com,Cathy Zhang,pau= lq@cisco.com,jguichar@cisco.com cc: sfc@ietf.org Sent: Friday, January 24, 2014 Subject: RE: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 =20 =20 =20 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mikebianc@aol.com =20 To avoid further confusion, should we refer to the selection of a service i= nstance as "service distribution" instead of "load balancing" to clearly differentiate this from the "load balancer" service? =20 [Linda] Do flows go through =E2=80=9CService Distribution Point=E2=80=9D be= fore going to individual instances? If the service chain path identify the individual instances, then the =E2=80=9Cservice distribution=E2=80=9D = is more like =E2=80=9Cmanager=E2=80=9D role, i.e. the data flows don=E2=80= =99t go through the =E2=80=9CService Distribution=E2=80=9D point. =20 Linda =20 Sure, whatever. =C2=A0My point is to use the term "load balance" to refer t= o a service in the chain and not use the term when referring to multiple in= stances of a service in the chain (of which there are a number of implement= ation methods). fwiw, you could comprise a service chain of all load-balancer services and = let each of those distribute flows to the instances, such that the chain it= self appears quite simple (LB1-LB2-LB3), hiding the fact that LB1 is a fwlb= and lb2 is a natlb, etc. =C2=A0But that, of course, is lunacy and still le= aves open the question, "What if we want to balance the balancers?" ------=_Part_2273_409003516.1390585071034 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable






= From: linda.dunbar@huawei.com<linda.dunbar@huawei.com>
T= o: Jerome Moisand<jmoisand@juniper.net>,mikebianc@aol.com<mike= bianc@aol.com>,Ron_Parker@affirmednetworks.com<Ron_Parker@affirmednet= works.com>,jmh@joelhalpern.com<jmh@joelhalpern.com>,Cathy Zhang<= ;Cathy.H.Zhang@huawei.com>,paulq@cisco.com<paulq@cisco.com>,jguich= ar@cisco.com<jguichar@cisco.com>
cc: sfc@ietf.org<sfc@ie= tf.org>
Sent: Friday, January 24, 2014
Subject: RE: = [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

To avoid f= urther 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?

[Linda] Do flows go through =E2=80=9CService Distribution Point=E2=80= =9D before going to individual instances? If the service chain path identif= y the individual instances, then the =E2=80=9Cservice distribution=E2=80=9D = is more like =E2=80=9Cmanager=E2=80=9D role, i.e. the data flows don=E2=80= =99t go through the =E2=80=9CService Distribution=E2=80=9D point.

Linda


Sure, whatever.  My point is to use = the term "load balance" to refer to a service in the chain and not use the = term when referring to multiple instances of a service in the chain (of whi= ch there are a number of implementation methods).

fwiw, you could comprise a se= rvice chain of all load-balancer services and let each of those distribute = flows to the instances, such that the chain itself appears quite simple (LB= 1-LB2-LB3), hiding the fact that LB1 is a fwlb and lb2 is a natlb, etc. &nb= sp;But that, of course, is lunacy and still leaves open the question, "What= if we want to balance the balancers?"
------=_Part_2273_409003516.1390585071034-- From jguichar@cisco.com Fri Jan 24 10:01:11 2014 Return-Path: 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 4B0321A0032 for ; Fri, 24 Jan 2014 10:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 5frxpWg5FFE9 for ; Fri, 24 Jan 2014 10:01:09 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD241A009F for ; Fri, 24 Jan 2014 10:01:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8980; q=dns/txt; s=iport; t=1390586468; x=1391796068; h=from:to:subject:date:message-id:mime-version; bh=EMn77+89wgeQPytZS+c1eR2M3phyKhnPvJ5TUdCMsjc=; b=Y4CIWgOldgOAaZvq0sVinigZnj9AQ1XeNGTUydUovN/iFUVbgcyf0/rf m8kE6Ra3dXrGVUZvI3FdfaqsHiEMjd+ufkik83UdOa0ZsrRywSRuIYuIG 5ME6VRjcQq8AGnIEAnPsfytaoXNEqoBz6SARh0VJCOdU5hooK/4KUmadT 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4HABWq4lKtJXHA/2dsb2JhbABagkhEOFapKYo5iWAWdIIsgQsBgQAnBCcHh2oNnEGrdBeTSwSYJ4EykGyDLYIq X-IronPort-AV: E=Sophos;i="4.95,714,1384300800"; d="scan'208,217";a="15319946" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-1.cisco.com with ESMTP; 24 Jan 2014 18:01:07 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0OI17qi020939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 24 Jan 2014 18:01:07 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.207]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Fri, 24 Jan 2014 12:01:07 -0600 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: Progression of use case documents within the SFC working group Thread-Index: AQHPGS5B+ZYQfqbdGEGHvCjMISf9vw== Date: Fri, 24 Jan 2014 18:01:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.43.183] Content-Type: multipart/alternative; boundary="_000_CF08148E148BCjguicharciscocom_" MIME-Version: 1.0 Subject: [sfc] Progression of use case documents within the SFC working group X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 18:01:11 -0000 --_000_CF08148E148BCjguicharciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Greetings, The documentation and applicability of use cases for the SFC WG was discuss= ed during both the Berlin and Vancouver BOFs. The main purpose of those dis= cussions was to show support for our work and subsequent formation of a wor= king group. As we move forward with our work we would like to solicit opinions of how b= est to approach use cases within the WG. The SFC charter left it open as to= whether we should have a single problem statement that includes use cases = or whether to separate out the use cases. Some background: 1) An important purpose for having use cases is to connect a problem or sol= ution to a real concrete scenario. On the problem side, a use case can high= light requirements for any solution. Hence, having SFC use cases is importa= nt. Lack of use cases could lead to missed requirements. 2) Having just one use case is probably not enough, but having too many qui= ckly leads to diminishing returns. The sweet spot is a relatively small num= ber (3? 4?) that are different enough that they flesh out the (different) k= ey requirements. We know that more use cases aren't helping when they simpl= y reaffirm requirements that have already been made apparent by other use c= ases. 3) Some use cases may be detailed and complicated , i.e., because the scena= rio or technology involved is complicated. Or they may be oriented towards = a particular community. Such use cases may warrant having their own standa= lone document. 4) If we try to put all use cases into a single document, we run the risk t= hat folk will continue to ask that additional scenarios be added, making it= difficult to close out and finish the document. With that in mind, the WG needs to make some choices. We propose: 1) Have the WG develop one use case document that documents a small number = of representative use cases. The document presented by Hongyu Li at the Va= ncouver BOF could serve for this purpose (http://datatracker.ietf.org/doc/d= raft-liu-service-chaining-use-cases). 2) Remove "Section 4. Service Function Chaining Use Cases=94 from draft-qu= inn-sfc-problem-statement. At present, one section is TBD, and the other s= ection "3GPP Gi Interface Service Function Chaining=94 would need significa= nt expansion, and that expansion probably makes more sense in a separate do= cument. If there was a simple use case that could be explained (to an IETF = reader) in 1-2 pages, we could consider putting it here, but we'd need a pr= oposal. (Any takers?) 3) For additional use cases not covered in 1) above, allow for a small numb= er of documents that are applicable to specific environments (e.g. mobilit= y, data center, broadband, and so forth.) These documents would provide mor= e detailed information and applicability of SFC to these specific environme= nts, and would need to go beyond what is covered in the general use case do= cument (1). Note that it is not the intention to have every potential use c= ase documented. Comments? Does the above approach seem reasonable to folks on the list? Any= objections? Jim & Thomas --_000_CF08148E148BCjguicharciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <60B1F91684A42D469C95E15462833C78@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Greetings,

The documentation a= nd applicability of use cases for the SFC WG was discussed during both the = Berlin and Vancouver BOFs. The main purpose of those discussions was to sho= w support for our work and subsequent formation of a working group.

As we move forward = with our work we would like to solicit opinions of how best to approach use= cases within the WG. The SFC charter left it open as to whether we should = have a single problem statement that includes use cases or whether to separate out the use cases.

Some background:

1) An important pur= pose for having use cases is to connect a problem or solution to a real con= crete scenario. On the problem side, a use case can highlight requirements = for any solution. Hence, having SFC use cases is important. Lack of use cases could lead to missed requirement= s.

2) Having just one = use case is probably not enough, but having too many quickly leads to dimin= ishing returns. The sweet spot is a relatively small number (3? 4?) that ar= e different enough that they flesh out the (different) key requirements. We know that more use cases aren't h= elping when they simply reaffirm requirements that have already been made a= pparent by other use cases.

3) Some use cases m= ay be detailed and complicated , i.e., because the scenario or technology i= nvolved is complicated. Or they may be oriented towards a particular commun= ity.  Such use cases may warrant having their own standalone document.

4) If we try to put= all use cases into a single document, we run the risk that folk will conti= nue to ask that additional scenarios be added, making it difficult to close= out and finish the document.

With that in mind, = the WG needs to make some choices. We propose:

2) Remove "Sec= tion 4.  Service Function Chaining Use Cases=94 from draft-quinn-= sfc-problem-statement. At present, one section is TBD,  and the other = section "3GPP Gi Interface Service Function Chaining=94 would need significant expansion, and that expansion probably makes more sense i= n a separate document. If there was a simple use case that could be explain= ed (to an IETF reader) in 1-2 pages, we could consider putting it here, but= we'd need a proposal. (Any takers?)

3) For additional u= se cases not covered in 1) above, allow for a small number of documents tha= t are applicable to specific environments (e.g.  mobility, data c= enter, broadband, and so forth.) These documents would provide more detailed information and applicability of SFC to these = specific environments, and would need to go beyond what is covered in the g= eneral use case document (1). Note that it is not the intention to have eve= ry potential use case documented.

Comments? Does the = above approach seem reasonable to folks on the list? Any objections?

Jim & Thomas --_000_CF08148E148BCjguicharciscocom_-- From mikebianc@aol.com Fri Jan 24 10:10:30 2014 Return-Path: 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 E6F2D1A0046 for ; Fri, 24 Jan 2014 10:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 c4iJhg21wpIm for ; Fri, 24 Jan 2014 10:10:28 -0800 (PST) Received: from omr-m08.mx.aol.com (omr-m08.mx.aol.com [64.12.222.129]) by ietfa.amsl.com (Postfix) with ESMTP id 400CC1A0036 for ; Fri, 24 Jan 2014 10:10:28 -0800 (PST) Received: from mtaout-mac02.mx.aol.com (mtaout-mac02.mx.aol.com [172.26.222.206]) by omr-m08.mx.aol.com (Outbound Mail Relay) with ESMTP id CB0487019910C; Fri, 24 Jan 2014 13:10:26 -0500 (EST) Received: from mgs-aad01.mail.aol.com (mgs-aad01.mail.aol.com [205.188.178.60]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-mac02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id A846B38000E08; Fri, 24 Jan 2014 13:10:26 -0500 (EST) Date: Fri, 24 Jan 2014 13:10:26 -0500 From: "mikebianc@aol.com" To: jguichar@cisco.com, sfc@ietf.org Message-ID: <1932349033.9487.1390587026582.JavaMail.tomcat@mgs-aad01.mail.aol.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9486_686256889.1390587026582" X-Originating-IP: 10.181.180.127, 205.188.91.40 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1390587026; bh=Wf85LTXrgKpujgPkmWMdX76YMfZFF7eUbvbINN/UnvM=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=IH7yqbpbpWUus7t92vZpnJkr/6VepbrAKQmQ4le1TiOTVTp5o/rxSu1toBCL5sCvK N4IUVQj1TwR9utWbJnD691dzv1KP+L4UZmh5EUQAOqC19369kfRXt99p3cdYgN6dCh KQ4AnjbwT9DnMNGs6/p9yJsN8yCroxFkwyQ5ZGjs= x-aol-sid: 3039ac1adece52e2ac92539c X-AOL-IP: 205.188.178.60 Subject: Re: [sfc] Progression of use case documents within the SFC working group X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 18:10:31 -0000 ------=_Part_9486_686256889.1390587026582 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This approach sounds very reasonable to me. From: jguichar@cisco.com To: sfc@ietf.org Sent: Friday, January 24, 2014 Subject: [sfc] Progression of use case documents within the SFC working gro= up Greetings, The documentation and applicability of use cases for the SFC WG was discuss= ed during both the Berlin and Vancouver BOFs. The main purpose of those dis= cussions was to show support for our work and subsequent formation of a working group. As we move forward with our work we would like to solicit opinions of how b= est to approach use cases within the WG. The SFC charter left it open as to= whether we should have a single problem statement that includes use cases or whether to separate out the use cases. Some background: 1) An important purpose for having use cases is to connect a problem or sol= ution to a real concrete scenario. On the problem side, a use case can high= light requirements for any solution. Hence, having SFC use cases is important. Lack of use cases could lead to missed requirement= s. 2) Having just one use case is probably not enough, but having too many qui= ckly leads to diminishing returns. The sweet spot is a relatively small num= ber (3? 4?) that are different enough that they flesh out the (different) key requirements. We know that more use cases aren't h= elping when they simply reaffirm requirements that have already been made a= pparent by other use cases. 3) Some use cases may be detailed and complicated , i.e., because the scena= rio or technology involved is complicated. Or they may be oriented towards = a particular community. Such use cases may warrant having their own standalone document. 4) If we try to put all use cases into a single document, we run the risk t= hat folk will continue to ask that additional scenarios be added, making it= difficult to close out and finish the document. With that in mind, the WG needs to make some choices. We propose: 1) Have the WG develop one use case document that documents a small number = of representative use cases. The document presented by Hongyu Li at the Va= ncouver BOF could serve for this purpose (http://datatracker.ietf.org/doc/d= raft-liu-service-chaining-use-cases). 2) Remove "Section 4. Service Function Chaining Use Cases=E2=80=9D from dr= aft-quinn-sfc-problem-statement. At present, one section is TBD, and the o= ther section "3GPP Gi Interface Service Function Chaining=E2=80=9D would need significant expansion, and that expansion probably makes more sense i= n a separate document. If there was a simple use case that could be explain= ed (to an IETF reader) in 1-2 pages, we could consider putting it here, but= we'd need a proposal. (Any takers?) 3) For additional use cases not covered in 1) above, allow for a small numb= er of documents that are applicable to specific environments (e.g. mobilit= y, data center, broadband, and so forth.) These documents would provide more detailed information and applicability of SFC to these = specific environments, and would need to go beyond what is covered in the g= eneral use case document (1). Note that it is not the intention to have eve= ry potential use case documented. Comments? Does the above approach seem reasonable to folks on the list? Any= objections? Jim & Thomas ------=_Part_9486_686256889.1390587026582 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
This approach s= ounds very reasonable to me.


=


From: jguichar@cisco.com&= lt;jguichar@cisco.com>
To: sfc@ietf.org<sfc@ietf.org>Sent: Friday, January 24, 2014
Subject: [sfc] Progression= of use case documents within the SFC working group

Greetings,

The documentation a= nd applicability of use cases for the SFC WG was discussed during both the = Berlin and Vancouver BOFs. The main purpose of those discussions was to sho= w support for our work and subsequent formation of a working group.

As we move forward = with our work we would like to solicit opinions of how best to approach use= cases within the WG. The SFC charter left it open as to whether we should = have a single problem statement that includes use cases or whether to separate out the use cases.

Some background:

1) An important pur= pose for having use cases is to connect a problem or solution to a real con= crete scenario. On the problem side, a use case can highlight requirements = for any solution. Hence, having SFC use cases is important. Lack of use cases could lead to missed requirement= s.

2) Having just one = use case is probably not enough, but having too many quickly leads to dimin= ishing returns. The sweet spot is a relatively small number (3? 4?) that ar= e different enough that they flesh out the (different) key requirements. We know that more use cases aren't h= elping when they simply reaffirm requirements that have already been made a= pparent by other use cases.

3) Some use cases m= ay be detailed and complicated , i.e., because the scenario or technology i= nvolved is complicated. Or they may be oriented towards a particular commun= ity. Such use cases may warrant having their own standalone document.

4) If we try to put= all use cases into a single document, we run the risk that folk will conti= nue to ask that additional scenarios be added, making it difficult to close= out and finish the document.

With that in mind, = the WG needs to make some choices. We propose:

1) Have the WG deve= lop one use case document that documents a small number of representative u= se cases. The document presented by Hongyu Li at the Vancouver BOF could s= erve for this purpose (http://datatracker.ietf.org/doc/draft-liu-serv= ice-chaining-use-cases).

2) Remove "Section = 4. Service Function Chaining Use Cases=E2=80=9D from draft-quinn-sfc-probl= em-statement. At present, one section is TBD, and the other section "3GPP = Gi Interface Service Function Chaining=E2=80=9D would need significant expansion, and that expansion probably makes more sense i= n a separate document. If there was a simple use case that could be explain= ed (to an IETF reader) in 1-2 pages, we could consider putting it here, but= we'd need a proposal. (Any takers?)

3) For additional u= se cases not covered in 1) above, allow for a small number of documents tha= t are applicable to specific environments (e.g. mobility, data center, bro= adband, and so forth.) These documents would provide more detailed information and applicability of SFC to these = specific environments, and would need to go beyond what is covered in the g= eneral use case document (1). Note that it is not the intention to have eve= ry potential use case documented.

Comments? Does the = above approach seem reasonable to folks on the list? Any objections?

Jim & Thomas ------=_Part_9486_686256889.1390587026582-- From paulq@cisco.com Fri Jan 24 10:59:10 2014 Return-Path: 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 E7D371A0168 for ; Fri, 24 Jan 2014 10:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 geSlUuUDkhM2 for ; Fri, 24 Jan 2014 10:59:09 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id C73C71A015B for ; Fri, 24 Jan 2014 10:59:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1422; q=dns/txt; s=iport; t=1390589948; x=1391799548; h=from:to:cc:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=MFPnLndLZ7CVyGs4lIB85W55KGVMwB27pgCiipdO9TE=; b=QdjXJkDqA44LhlJckEX6I3fLiMKDb+U/Sjon1Rf5ZVVdYVDsd/oCPBOX jw2OJ6sDUVRtS6+O5BVNpSIqqPDazgAivW9l+xr4zC2e0RitXdCqCD+9E ns7iiw4mus4xPpK/d6hYcTkW2QGguoXnVsAcXqI17Md/iHz9E4gKaOdZE s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAJe24lKtJXG+/2dsb2JhbABagww4UAapcZJEgQ0WdIImAQEEOj0CEAIBGiQQMhcECgIEDg4Sh2oIBchBF48MhD8EmCeBMpBsgy2CKg X-IronPort-AV: E=Sophos;i="4.95,714,1384300800"; d="scan'208";a="15338986" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-6.cisco.com with ESMTP; 24 Jan 2014 18:59:08 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0OIx8wN029327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Jan 2014 18:59:08 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.19]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Fri, 24 Jan 2014 12:59:08 -0600 From: "Paul Quinn (paulq)" To: "" Thread-Topic: New Version Notification for draft-quinn-sfc-arch-03.txt Thread-Index: AQHPGTSdMNohIn0vMkCwu7+EZD241Q== Date: Fri, 24 Jan 2014 18:59:07 +0000 Message-ID: References: <20140124184614.9333.22684.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.229] Content-Type: text/plain; charset="us-ascii" Content-ID: <3DF119F8CDAACF4BBE6B6663CB47A019@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Andre Beliveau Subject: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-03.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 18:59:11 -0000 Hi folks, This new version of the draft effectively merges draft-quinn-sfc-arch-02 an= d draft-beliveau-sfc-architecture-00.=20 Thanks Paul Begin forwarded message: >=20 > A new version of I-D, draft-quinn-sfc-arch-03.txt > has been successfully submitted by Paul Quinn and posted to the > IETF repository. >=20 > Name: draft-quinn-sfc-arch > Revision: 03 > Title: Service Function Chaining (SFC) Architecture > Document date: 2014-01-22 > Group: Individual Submission > Pages: 21 > URL: http://www.ietf.org/internet-drafts/draft-quinn-sfc-arch-= 03.txt > Status: https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/ > Htmlized: http://tools.ietf.org/html/draft-quinn-sfc-arch-03 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-quinn-sfc-arch-0= 3 >=20 > Abstract: > This document describes an architecture used for the creation of > Service Function Chains (SFC). It includes architectural concepts, > principles, and components used in the construction of composite > services through deployment of SFCs in a network. This document does > not propose solutions, protocols, or extensions to existing > protocols. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From liushucheng@huawei.com Sun Jan 26 00:10:58 2014 Return-Path: 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 16B461A010F for ; Sun, 26 Jan 2014 00:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 uZYklKDSrGrp for ; Sun, 26 Jan 2014 00:10:56 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B66721A010D for ; Sun, 26 Jan 2014 00:10:55 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCX82291; Sun, 26 Jan 2014 08:10:53 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 26 Jan 2014 08:10:41 +0000 Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 26 Jan 2014 08:10:52 +0000 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.102]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Sun, 26 Jan 2014 16:10:49 +0800 From: "Liushucheng (Will)" To: "sfc@ietf.org" Thread-Topic: WG adoption of draft-quinn-sfc-problem-statement-02 Thread-Index: AQHPFtz0BBXmRpg9rk2thNSnYBnFRZqWrcOA Date: Sun, 26 Jan 2014 08:10:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.78.79] Content-Type: multipart/alternative; boundary="_000_C9B5F12337F6F841B35C404CF0554ACB5FE69F6BSZXEMA509MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 08:10:58 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB5FE69F6BSZXEMA509MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry for being late. I support the adoption and am looking forward to the = upcoming detailed use case work starting from here. Regards, Shucheng (Will) From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Wednesday, January 22, 2014 3:14 AM To: sfc@ietf.org Subject: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02 Thomas and I would like to remind you of the ongoing WG call for adoption o= f draft-quinn-sfc-problem-statement-02. We have received numerous positive = responses to our original email and plan to formally close out the call for= adoption this coming Friday (1/24/14). If folks have any additional commen= ts or concerns please voice them before this Friday. Jim & Thomas SFC chairs. --_000_C9B5F12337F6F841B35C404CF0554ACB5FE69F6BSZXEMA509MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry for = being late. I support the adoption and am looking forward to the upcoming d= etailed use case work starting from here.

 = ;

Regards,<= /p>

Shucheng (Will)<= /span>

 = ;

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, January 22, 2014 3:14 AM
To: sfc@ietf.org
Subject: [sfc] WG adoption of draft-quinn-sfc-problem-statement-02

 

Thomas and I = would like to remind you of the ongoing WG call for adoption of draft-quinn= -sfc-problem-statement-02. We have received numerous positive responses to our original email and plan to formally close out the call fo= r adoption this coming Friday (1/24/14). If folks have any additional comme= nts or concerns please voice them before this Friday.

 

Jim & Tho= mas

SFC chairs.&n= bsp;

--_000_C9B5F12337F6F841B35C404CF0554ACB5FE69F6BSZXEMA509MBSchi_-- From hongyu.li@huawei.com Sun Jan 26 00:35:41 2014 Return-Path: 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 A42381A0115 for ; Sun, 26 Jan 2014 00:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 MCN7gh0fn-nw for ; Sun, 26 Jan 2014 00:35:39 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 87BD31A0114 for ; Sun, 26 Jan 2014 00:35:38 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCX83719; Sun, 26 Jan 2014 08:35:35 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 26 Jan 2014 08:35:11 +0000 Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 26 Jan 2014 08:35:34 +0000 Received: from SZXEMA509-MBX.china.huawei.com ([169.254.1.51]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Sun, 26 Jan 2014 16:31:45 +0800 From: "Hongyu Li (Julio)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: Progression of use case documents within the SFC working group Thread-Index: AQHPGS5B+ZYQfqbdGEGHvCjMISf9v5qWrijA Date: Sun, 26 Jan 2014 08:31:44 +0000 Message-ID: <6EB34CB5D82C4645B826C56144826EA97E9B780F@SZXEMA509-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.114.234] Content-Type: multipart/alternative; boundary="_000_6EB34CB5D82C4645B826C56144826EA97E9B780FSZXEMA509MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [sfc] Progression of use case documents within the SFC working group X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 08:35:42 -0000 --_000_6EB34CB5D82C4645B826C56144826EA97E9B780FSZXEMA509MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnVsbHkgYWdyZWUgb24gdGhpcyBhcHByb2FjaC4gV2UgY2FuIGNvbGxlY3QgYW5kIGxlYWNoIHVz ZSBjYXNlcyBpbiBzaWdodCBpbnRvIGRyYWZ0LWxpdS1zZXJ2aWNlLWNoYWluaW5nLXVzZS1jYXNl cywgYW5kIGxlYXZlIG90aGVyIG5ldyB1c2UgY2FzZXMgZm9yIGxhdGVyIGRyYWZ0cy4NCg0KSG9u Z3l1DQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgSmltIEd1aWNoYXJkIChqZ3VpY2hhcikNClNlbnQ6IFNhdHVyZGF5LCBKYW51YXJ5IDI1LCAy MDE0IDI6MDEgQU0NClRvOiBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFtzZmNdIFByb2dyZXNzaW9u IG9mIHVzZSBjYXNlIGRvY3VtZW50cyB3aXRoaW4gdGhlIFNGQyB3b3JraW5nIGdyb3VwDQoNCkdy ZWV0aW5ncywNCg0KVGhlIGRvY3VtZW50YXRpb24gYW5kIGFwcGxpY2FiaWxpdHkgb2YgdXNlIGNh c2VzIGZvciB0aGUgU0ZDIFdHIHdhcyBkaXNjdXNzZWQgZHVyaW5nIGJvdGggdGhlIEJlcmxpbiBh bmQgVmFuY291dmVyIEJPRnMuIFRoZSBtYWluIHB1cnBvc2Ugb2YgdGhvc2UgZGlzY3Vzc2lvbnMg d2FzIHRvIHNob3cgc3VwcG9ydCBmb3Igb3VyIHdvcmsgYW5kIHN1YnNlcXVlbnQgZm9ybWF0aW9u IG9mIGEgd29ya2luZyBncm91cC4NCg0KQXMgd2UgbW92ZSBmb3J3YXJkIHdpdGggb3VyIHdvcmsg d2Ugd291bGQgbGlrZSB0byBzb2xpY2l0IG9waW5pb25zIG9mIGhvdyBiZXN0IHRvIGFwcHJvYWNo IHVzZSBjYXNlcyB3aXRoaW4gdGhlIFdHLiBUaGUgU0ZDIGNoYXJ0ZXIgbGVmdCBpdCBvcGVuIGFz IHRvIHdoZXRoZXIgd2Ugc2hvdWxkIGhhdmUgYSBzaW5nbGUgcHJvYmxlbSBzdGF0ZW1lbnQgdGhh dCBpbmNsdWRlcyB1c2UgY2FzZXMgb3Igd2hldGhlciB0byBzZXBhcmF0ZSBvdXQgdGhlIHVzZSBj YXNlcy4NCg0KU29tZSBiYWNrZ3JvdW5kOg0KDQoxKSBBbiBpbXBvcnRhbnQgcHVycG9zZSBmb3Ig aGF2aW5nIHVzZSBjYXNlcyBpcyB0byBjb25uZWN0IGEgcHJvYmxlbSBvciBzb2x1dGlvbiB0byBh IHJlYWwgY29uY3JldGUgc2NlbmFyaW8uIE9uIHRoZSBwcm9ibGVtIHNpZGUsIGEgdXNlIGNhc2Ug Y2FuIGhpZ2hsaWdodCByZXF1aXJlbWVudHMgZm9yIGFueSBzb2x1dGlvbi4gSGVuY2UsIGhhdmlu ZyBTRkMgdXNlIGNhc2VzIGlzIGltcG9ydGFudC4gTGFjayBvZiB1c2UgY2FzZXMgY291bGQgbGVh ZCB0byBtaXNzZWQgcmVxdWlyZW1lbnRzLg0KDQoyKSBIYXZpbmcganVzdCBvbmUgdXNlIGNhc2Ug aXMgcHJvYmFibHkgbm90IGVub3VnaCwgYnV0IGhhdmluZyB0b28gbWFueSBxdWlja2x5IGxlYWRz IHRvIGRpbWluaXNoaW5nIHJldHVybnMuIFRoZSBzd2VldCBzcG90IGlzIGEgcmVsYXRpdmVseSBz bWFsbCBudW1iZXIgKDM/IDQ/KSB0aGF0IGFyZSBkaWZmZXJlbnQgZW5vdWdoIHRoYXQgdGhleSBm bGVzaCBvdXQgdGhlIChkaWZmZXJlbnQpIGtleSByZXF1aXJlbWVudHMuIFdlIGtub3cgdGhhdCBt b3JlIHVzZSBjYXNlcyBhcmVuJ3QgaGVscGluZyB3aGVuIHRoZXkgc2ltcGx5IHJlYWZmaXJtIHJl cXVpcmVtZW50cyB0aGF0IGhhdmUgYWxyZWFkeSBiZWVuIG1hZGUgYXBwYXJlbnQgYnkgb3RoZXIg dXNlIGNhc2VzLg0KDQozKSBTb21lIHVzZSBjYXNlcyBtYXkgYmUgZGV0YWlsZWQgYW5kIGNvbXBs aWNhdGVkICwgaS5lLiwgYmVjYXVzZSB0aGUgc2NlbmFyaW8gb3IgdGVjaG5vbG9neSBpbnZvbHZl ZCBpcyBjb21wbGljYXRlZC4gT3IgdGhleSBtYXkgYmUgb3JpZW50ZWQgdG93YXJkcyBhIHBhcnRp Y3VsYXIgY29tbXVuaXR5LiAgU3VjaCB1c2UgY2FzZXMgbWF5IHdhcnJhbnQgaGF2aW5nIHRoZWly IG93biBzdGFuZGFsb25lIGRvY3VtZW50Lg0KDQo0KSBJZiB3ZSB0cnkgdG8gcHV0IGFsbCB1c2Ug Y2FzZXMgaW50byBhIHNpbmdsZSBkb2N1bWVudCwgd2UgcnVuIHRoZSByaXNrIHRoYXQgZm9sayB3 aWxsIGNvbnRpbnVlIHRvIGFzayB0aGF0IGFkZGl0aW9uYWwgc2NlbmFyaW9zIGJlIGFkZGVkLCBt YWtpbmcgaXQgZGlmZmljdWx0IHRvIGNsb3NlIG91dCBhbmQgZmluaXNoIHRoZSBkb2N1bWVudC4N Cg0KV2l0aCB0aGF0IGluIG1pbmQsIHRoZSBXRyBuZWVkcyB0byBtYWtlIHNvbWUgY2hvaWNlcy4g V2UgcHJvcG9zZToNCg0KMSkgSGF2ZSB0aGUgV0cgZGV2ZWxvcCBvbmUgdXNlIGNhc2UgZG9jdW1l bnQgdGhhdCBkb2N1bWVudHMgYSBzbWFsbCBudW1iZXIgb2YgcmVwcmVzZW50YXRpdmUgdXNlIGNh c2VzLiAgVGhlIGRvY3VtZW50IHByZXNlbnRlZCBieSBIb25neXUgTGkgYXQgdGhlIFZhbmNvdXZl ciBCT0YgY291bGQgc2VydmUgZm9yIHRoaXMgcHVycG9zZSAoaHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1saXUtc2VydmljZS1jaGFpbmluZy11c2UtY2FzZXMpLg0KDQoyKSBS ZW1vdmUgIlNlY3Rpb24gNC4gIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgVXNlIENhc2Vz4oCd IGZyb20gZHJhZnQtcXVpbm4tc2ZjLXByb2JsZW0tc3RhdGVtZW50LiBBdCBwcmVzZW50LCBvbmUg c2VjdGlvbiBpcyBUQkQsICBhbmQgdGhlIG90aGVyIHNlY3Rpb24gIjNHUFAgR2kgSW50ZXJmYWNl IFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmfigJ0gd291bGQgbmVlZCBzaWduaWZpY2FudCBleHBh bnNpb24sIGFuZCB0aGF0IGV4cGFuc2lvbiBwcm9iYWJseSBtYWtlcyBtb3JlIHNlbnNlIGluIGEg c2VwYXJhdGUgZG9jdW1lbnQuIElmIHRoZXJlIHdhcyBhIHNpbXBsZSB1c2UgY2FzZSB0aGF0IGNv dWxkIGJlIGV4cGxhaW5lZCAodG8gYW4gSUVURiByZWFkZXIpIGluIDEtMiBwYWdlcywgd2UgY291 bGQgY29uc2lkZXIgcHV0dGluZyBpdCBoZXJlLCBidXQgd2UnZCBuZWVkIGEgcHJvcG9zYWwuIChB bnkgdGFrZXJzPykNCg0KMykgRm9yIGFkZGl0aW9uYWwgdXNlIGNhc2VzIG5vdCBjb3ZlcmVkIGlu IDEpIGFib3ZlLCBhbGxvdyBmb3IgYSBzbWFsbCBudW1iZXIgb2YgZG9jdW1lbnRzIHRoYXQgYXJl IGFwcGxpY2FibGUgdG8gc3BlY2lmaWMgZW52aXJvbm1lbnRzIChlLmcuICBtb2JpbGl0eSwgZGF0 YSBjZW50ZXIsIGJyb2FkYmFuZCwgYW5kIHNvIGZvcnRoLikgVGhlc2UgZG9jdW1lbnRzIHdvdWxk IHByb3ZpZGUgbW9yZSBkZXRhaWxlZCBpbmZvcm1hdGlvbiBhbmQgYXBwbGljYWJpbGl0eSBvZiBT RkMgdG8gdGhlc2Ugc3BlY2lmaWMgZW52aXJvbm1lbnRzLCBhbmQgd291bGQgbmVlZCB0byBnbyBi ZXlvbmQgd2hhdCBpcyBjb3ZlcmVkIGluIHRoZSBnZW5lcmFsIHVzZSBjYXNlIGRvY3VtZW50ICgx KS4gTm90ZSB0aGF0IGl0IGlzIG5vdCB0aGUgaW50ZW50aW9uIHRvIGhhdmUgZXZlcnkgcG90ZW50 aWFsIHVzZSBjYXNlIGRvY3VtZW50ZWQuDQoNCkNvbW1lbnRzPyBEb2VzIHRoZSBhYm92ZSBhcHBy b2FjaCBzZWVtIHJlYXNvbmFibGUgdG8gZm9sa3Mgb24gdGhlIGxpc3Q/IEFueSBvYmplY3Rpb25z Pw0KDQpKaW0gJiBUaG9tYXMNCg== --_000_6EB34CB5D82C4645B826C56144826EA97E9B780FSZXEMA509MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5GdWxseSBhZ3JlZSBvbiB0aGlzIGFwcHJv YWNoLiBXZSBjYW4gY29sbGVjdCBhbmQgbGVhY2ggdXNlIGNhc2VzIGluIHNpZ2h0IGludG8gZHJh ZnQtbGl1LXNlcnZpY2UtY2hhaW5pbmctdXNlLWNhc2VzLCBhbmQgbGVhdmUgb3RoZXIgbmV3IHVz ZSBjYXNlcw0KIGZvciBsYXRlciBkcmFmdHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkhvbmd5dTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5KaW0gR3VpY2hhcmQgKGpndWljaGFyKTxicj4NCjxiPlNlbnQ6PC9iPiBT YXR1cmRheSwgSmFudWFyeSAyNSwgMjAxNCAyOjAxIEFNPGJyPg0KPGI+VG86PC9iPiBzZmNAaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3NmY10gUHJvZ3Jlc3Npb24gb2YgdXNlIGNhc2Ug ZG9jdW1lbnRzIHdpdGhpbiB0aGUgU0ZDIHdvcmtpbmcgZ3JvdXA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5HcmVldGluZ3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+VGhlIGRvY3VtZW50YXRpb24gYW5kIGFwcGxpY2FiaWxpdHkgb2Yg dXNlIGNhc2VzIGZvciB0aGUgU0ZDIFdHIHdhcyBkaXNjdXNzZWQgZHVyaW5nIGJvdGggdGhlIEJl cmxpbiBhbmQgVmFuY291dmVyIEJPRnMuIFRoZSBtYWluIHB1cnBvc2Ugb2YgdGhvc2UNCiBkaXNj dXNzaW9ucyB3YXMgdG8gc2hvdyBzdXBwb3J0IGZvciBvdXIgd29yayBhbmQgc3Vic2VxdWVudCBm b3JtYXRpb24gb2YgYSB3b3JraW5nIGdyb3VwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkFzIHdlIG1vdmUgZm9yd2FyZCB3aXRo IG91ciB3b3JrIHdlIHdvdWxkIGxpa2UgdG8gc29saWNpdCBvcGluaW9ucyBvZiBob3cgYmVzdCB0 byBhcHByb2FjaCB1c2UgY2FzZXMgd2l0aGluIHRoZSBXRy4gVGhlIFNGQyBjaGFydGVyIGxlZnQg aXQgb3Blbg0KIGFzIHRvIHdoZXRoZXIgd2Ugc2hvdWxkIGhhdmUgYSBzaW5nbGUgcHJvYmxlbSBz dGF0ZW1lbnQgdGhhdCBpbmNsdWRlcyB1c2UgY2FzZXMgb3Igd2hldGhlciB0byBzZXBhcmF0ZSBv dXQgdGhlIHVzZSBjYXNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox My41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Tb21lIGJhY2tncm91bmQ6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+MSkgQW4gaW1wb3J0 YW50IHB1cnBvc2UgZm9yIGhhdmluZyB1c2UgY2FzZXMgaXMgdG8gY29ubmVjdCBhIHByb2JsZW0g b3Igc29sdXRpb24gdG8gYSByZWFsIGNvbmNyZXRlIHNjZW5hcmlvLiBPbiB0aGUgcHJvYmxlbSBz aWRlLCBhIHVzZSBjYXNlIGNhbg0KIGhpZ2hsaWdodCByZXF1aXJlbWVudHMgZm9yIGFueSBzb2x1 dGlvbi4gSGVuY2UsIGhhdmluZyBTRkMgdXNlIGNhc2VzIGlzIGltcG9ydGFudC4gTGFjayBvZiB1 c2UgY2FzZXMgY291bGQgbGVhZCB0byBtaXNzZWQgcmVxdWlyZW1lbnRzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjIpIEhhdmlu ZyBqdXN0IG9uZSB1c2UgY2FzZSBpcyBwcm9iYWJseSBub3QgZW5vdWdoLCBidXQgaGF2aW5nIHRv byBtYW55IHF1aWNrbHkgbGVhZHMgdG8gZGltaW5pc2hpbmcgcmV0dXJucy4gVGhlIHN3ZWV0IHNw b3QgaXMgYSByZWxhdGl2ZWx5IHNtYWxsDQogbnVtYmVyICgzPyA0PykgdGhhdCBhcmUgZGlmZmVy ZW50IGVub3VnaCB0aGF0IHRoZXkgZmxlc2ggb3V0IHRoZSAoZGlmZmVyZW50KSBrZXkgcmVxdWly ZW1lbnRzLiBXZSBrbm93IHRoYXQgbW9yZSB1c2UgY2FzZXMgYXJlbid0IGhlbHBpbmcgd2hlbiB0 aGV5IHNpbXBseSByZWFmZmlybSByZXF1aXJlbWVudHMgdGhhdCBoYXZlIGFscmVhZHkgYmVlbiBt YWRlIGFwcGFyZW50IGJ5IG90aGVyIHVzZSBjYXNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4zKSBTb21lIHVzZSBjYXNlcyBt YXkgYmUgZGV0YWlsZWQgYW5kIGNvbXBsaWNhdGVkICwgaS5lLiwgYmVjYXVzZSB0aGUgc2NlbmFy aW8gb3IgdGVjaG5vbG9neSBpbnZvbHZlZCBpcyBjb21wbGljYXRlZC4gT3IgdGhleSBtYXkgYmUg b3JpZW50ZWQgdG93YXJkcw0KIGEgcGFydGljdWxhciBjb21tdW5pdHkuJm5ic3A7Jm5ic3A7U3Vj aCB1c2UgY2FzZXMgbWF5IHdhcnJhbnQgaGF2aW5nIHRoZWlyIG93biBzdGFuZGFsb25lIGRvY3Vt ZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjQpIElmIHdlIHRyeSB0byBwdXQgYWxsIHVzZSBjYXNlcyBpbnRvIGEgc2luZ2xl IGRvY3VtZW50LCB3ZSBydW4gdGhlIHJpc2sgdGhhdCBmb2xrIHdpbGwgY29udGludWUgdG8gYXNr IHRoYXQgYWRkaXRpb25hbCBzY2VuYXJpb3MgYmUgYWRkZWQsIG1ha2luZw0KIGl0IGRpZmZpY3Vs dCB0byBjbG9zZSBvdXQgYW5kIGZpbmlzaCB0aGUgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+V2l0aCB0aGF0IGlu IG1pbmQsIHRoZSBXRyBuZWVkcyB0byBtYWtlIHNvbWUgY2hvaWNlcy4gV2UgcHJvcG9zZTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij4xKSBIYXZlIHRoZSBXRyBkZXZlbG9wIG9uZSB1c2UgY2FzZSBkb2N1bWVudCB0aGF0IGRvY3Vt ZW50cyBhIHNtYWxsIG51bWJlciBvZiByZXByZXNlbnRhdGl2ZSB1c2UgY2FzZXMuJm5ic3A7Jm5i c3A7VGhlIGRvY3VtZW50IHByZXNlbnRlZCBieSBIb25neXUgTGkgYXQgdGhlDQogVmFuY291dmVy IEJPRiBjb3VsZCBzZXJ2ZSBmb3IgdGhpcyBwdXJwb3NlICg8YSBocmVmPSJodHRwOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpdS1zZXJ2aWNlLWNoYWluaW5nLXVzZS1jYXNlcyI+ aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1saXUtc2VydmljZS1jaGFpbmlu Zy11c2UtY2FzZXM8L2E+KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox My41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4yKSBSZW1vdmUgJnF1b3Q7U2VjdGlvbiA0LiZuYnNwOyZu YnNwO1NlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgVXNlIENhc2Vz4oCdIGZyb20gZHJhZnQtcXVp bm4tc2ZjLXByb2JsZW0tc3RhdGVtZW50LiBBdCBwcmVzZW50LCBvbmUgc2VjdGlvbiBpcyBUQkQs ICZuYnNwO2FuZCB0aGUgb3RoZXINCiBzZWN0aW9uICZxdW90OzNHUFAgR2kgSW50ZXJmYWNlIFNl cnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmfigJ0gd291bGQgbmVlZCBzaWduaWZpY2FudCBleHBhbnNp b24sIGFuZCB0aGF0IGV4cGFuc2lvbiBwcm9iYWJseSBtYWtlcyBtb3JlIHNlbnNlIGluIGEgc2Vw YXJhdGUgZG9jdW1lbnQuIElmIHRoZXJlIHdhcyBhIHNpbXBsZSB1c2UgY2FzZSB0aGF0IGNvdWxk IGJlIGV4cGxhaW5lZCAodG8gYW4gSUVURiByZWFkZXIpIGluIDEtMiBwYWdlcywgd2UgY291bGQg Y29uc2lkZXINCiBwdXR0aW5nIGl0IGhlcmUsIGJ1dCB3ZSdkIG5lZWQgYSBwcm9wb3NhbC4gKEFu eSB0YWtlcnM/KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEz LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjMpIEZvciBhZGRpdGlvbmFsIHVzZSBjYXNlcyBub3QgY292ZXJlZCBp biAxKSBhYm92ZSwgYWxsb3cgZm9yIGEgc21hbGwgbnVtYmVyIG9mIGRvY3VtZW50cyB0aGF0IGFy ZSBhcHBsaWNhYmxlIHRvIHNwZWNpZmljIGVudmlyb25tZW50cyAoZS5nLiZuYnNwOyZuYnNwO21v YmlsaXR5LA0KIGRhdGEgY2VudGVyLCBicm9hZGJhbmQsIGFuZCBzbyBmb3J0aC4pIFRoZXNlIGRv Y3VtZW50cyB3b3VsZCBwcm92aWRlIG1vcmUgZGV0YWlsZWQgaW5mb3JtYXRpb24gYW5kIGFwcGxp Y2FiaWxpdHkgb2YgU0ZDIHRvIHRoZXNlIHNwZWNpZmljIGVudmlyb25tZW50cywgYW5kIHdvdWxk IG5lZWQgdG8gZ28gYmV5b25kIHdoYXQgaXMgY292ZXJlZCBpbiB0aGUgZ2VuZXJhbCB1c2UgY2Fz ZSBkb2N1bWVudCAoMSkuIE5vdGUgdGhhdCBpdCBpcyBub3QgdGhlDQogaW50ZW50aW9uIHRvIGhh dmUgZXZlcnkgcG90ZW50aWFsIHVzZSBjYXNlIGRvY3VtZW50ZWQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Q29tbWVudHM/IERv ZXMgdGhlIGFib3ZlIGFwcHJvYWNoIHNlZW0gcmVhc29uYWJsZSB0byBmb2xrcyBvbiB0aGUgbGlz dD8gQW55IG9iamVjdGlvbnM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SmltICZhbXA7IFRob21hczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6EB34CB5D82C4645B826C56144826EA97E9B780FSZXEMA509MBXchi_-- From liushucheng@huawei.com Sun Jan 26 01:07:14 2014 Return-Path: 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 B510B1A0119 for ; Sun, 26 Jan 2014 01:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 AIVim9wtuZny for ; Sun, 26 Jan 2014 01:07:07 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B725F1A0118 for ; Sun, 26 Jan 2014 01:07:06 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAK78801; Sun, 26 Jan 2014 09:07:04 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 26 Jan 2014 09:06:51 +0000 Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 26 Jan 2014 09:07:02 +0000 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.102]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Sun, 26 Jan 2014 17:06:58 +0800 From: "Liushucheng (Will)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: Progression of use case documents within the SFC working group Thread-Index: AQHPGS5B+ZYQfqbdGEGHvCjMISf9v5qWuFrg Date: Sun, 26 Jan 2014 09:06:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.78.79] Content-Type: multipart/alternative; boundary="_000_C9B5F12337F6F841B35C404CF0554ACB5FE69FA5SZXEMA509MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [sfc] Progression of use case documents within the SFC working group X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 09:07:15 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB5FE69FA5SZXEMA509MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support and hope that we can receive more interests and comments for the= use case draft. We will modify it accordingly. Regards, Shucheng (Will) From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Saturday, January 25, 2014 2:01 AM To: sfc@ietf.org Subject: [sfc] Progression of use case documents within the SFC working gro= up Greetings, The documentation and applicability of use cases for the SFC WG was discuss= ed during both the Berlin and Vancouver BOFs. The main purpose of those dis= cussions was to show support for our work and subsequent formation of a wor= king group. As we move forward with our work we would like to solicit opinions of how b= est to approach use cases within the WG. The SFC charter left it open as to= whether we should have a single problem statement that includes use cases = or whether to separate out the use cases. Some background: 1) An important purpose for having use cases is to connect a problem or sol= ution to a real concrete scenario. On the problem side, a use case can high= light requirements for any solution. Hence, having SFC use cases is importa= nt. Lack of use cases could lead to missed requirements. 2) Having just one use case is probably not enough, but having too many qui= ckly leads to diminishing returns. The sweet spot is a relatively small num= ber (3? 4?) that are different enough that they flesh out the (different) k= ey requirements. We know that more use cases aren't helping when they simpl= y reaffirm requirements that have already been made apparent by other use c= ases. 3) Some use cases may be detailed and complicated , i.e., because the scena= rio or technology involved is complicated. Or they may be oriented towards = a particular community. Such use cases may warrant having their own standa= lone document. 4) If we try to put all use cases into a single document, we run the risk t= hat folk will continue to ask that additional scenarios be added, making it= difficult to close out and finish the document. With that in mind, the WG needs to make some choices. We propose: 1) Have the WG develop one use case document that documents a small number = of representative use cases. The document presented by Hongyu Li at the Va= ncouver BOF could serve for this purpose (http://datatracker.ietf.org/doc/d= raft-liu-service-chaining-use-cases). 2) Remove "Section 4. Service Function Chaining Use Cases" from draft-quin= n-sfc-problem-statement. At present, one section is TBD, and the other sec= tion "3GPP Gi Interface Service Function Chaining" would need significant e= xpansion, and that expansion probably makes more sense in a separate docume= nt. If there was a simple use case that could be explained (to an IETF read= er) in 1-2 pages, we could consider putting it here, but we'd need a propos= al. (Any takers?) 3) For additional use cases not covered in 1) above, allow for a small numb= er of documents that are applicable to specific environments (e.g. mobilit= y, data center, broadband, and so forth.) These documents would provide mor= e detailed information and applicability of SFC to these specific environme= nts, and would need to go beyond what is covered in the general use case do= cument (1). Note that it is not the intention to have every potential use c= ase documented. Comments? Does the above approach seem reasonable to folks on the list? Any= objections? Jim & Thomas --_000_C9B5F12337F6F841B35C404CF0554ACB5FE69FA5SZXEMA509MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support = and hope that we can receive more interests and  comments for the use = case draft. We will modify it accordingly.

 = ;

Regards,<= /p>

Shucheng (Will)<= /span>

 = ;

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Saturday, January 25, 2014 2:01 AM
To: sfc@ietf.org
Subject: [sfc] Progression of use case documents within the SFC work= ing group

 

Greetings,

 <= /o:p>

The document= ation and applicability of use cases for the SFC WG was discussed during bo= th the Berlin and Vancouver BOFs. The main purpose of those discussions was to show support for our work and subsequent formation of a= working group.

 <= /o:p>

As we move f= orward with our work we would like to solicit opinions of how best to appro= ach use cases within the WG. The SFC charter left it open as to whether we should have a single problem statement that includes use = cases or whether to separate out the use cases.

 <= /o:p>

Some backgro= und:

 <= /o:p>

1) An import= ant purpose for having use cases is to connect a problem or solution to a r= eal concrete scenario. On the problem side, a use case can highlight requirements for any solution. Hence, having SFC use cases is im= portant. Lack of use cases could lead to missed requirements.

 <= /o:p>

2) Having ju= st one use case is probably not enough, but having too many quickly leads t= o diminishing returns. The sweet spot is a relatively small number (3? 4?) that are different enough that they flesh out the (differen= t) key requirements. We know that more use cases aren't helping when they s= imply reaffirm requirements that have already been made apparent by other u= se cases.

 <= /o:p>

3) Some use = cases may be detailed and complicated , i.e., because the scenario or techn= ology involved is complicated. Or they may be oriented towards a particular community.  Such use cases may warrant having their= own standalone document.

 <= /o:p>

4) If we try= to put all use cases into a single document, we run the risk that folk wil= l continue to ask that additional scenarios be added, making it difficult to close out and finish the document.

 <= /o:p>

With that in= mind, the WG needs to make some choices. We propose:

 <= /o:p>

1) Have the = WG develop one use case document that documents a small number of represent= ative use cases.  The document presented by Hongyu Li at the Vancouver BOF could serve for this purpose (http://datatracker.ietf.= org/doc/draft-liu-service-chaining-use-cases).

 <= /o:p>

2) Remove &q= uot;Section 4.  Service Function Chaining Use Cases” from d= raft-quinn-sfc-problem-statement. At present, one section is TBD,  and= the other section "3GPP Gi Interface Service Function Chaining” would nee= d significant expansion, and that expansion probably makes more sense in a = separate document. If there was a simple use case that could be explained (= to an IETF reader) in 1-2 pages, we could consider putting it here, but we'd need a proposal. (Any takers?)=

 <= /o:p>

3) For addit= ional use cases not covered in 1) above, allow for a small number of docume= nts that are applicable to specific environments (e.g.  mobility, data center, broadband, and so forth.) These documents would provide more = detailed information and applicability of SFC to these specific environment= s, and would need to go beyond what is covered in the general use case docu= ment (1). Note that it is not the intention to have every potential use case documented.

 <= /o:p>

Comments? Do= es the above approach seem reasonable to folks on the list? Any objections?=

 <= /o:p>

Jim & Th= omas

--_000_C9B5F12337F6F841B35C404CF0554ACB5FE69FA5SZXEMA509MBSchi_-- From zehn.cao@gmail.com Sun Jan 26 05:11:10 2014 Return-Path: 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 34E861A0146 for ; Sun, 26 Jan 2014 05:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 oNeUmxzYymDv for ; Sun, 26 Jan 2014 05:11:08 -0800 (PST) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 365B81A0141 for ; Sun, 26 Jan 2014 05:11:08 -0800 (PST) Received: by mail-qc0-f178.google.com with SMTP id m20so6582903qcx.23 for ; Sun, 26 Jan 2014 05:11:06 -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=dGlrguAkrHgDNQHIz2qdAm2oSrTylyqb7NfNlgs4hs4=; b=Bq5FIB3uXVkLyR5j2md7E9p5sO2sHRP6YZu9Jtzofruke1qzdOz8MkvLK7nnrHBlpY ijM8gZWWqTygNLblFo2R2R72NJzPVbKejwwxWPCbPD4nyPxufq53hylmTIbau4cjn6Ek 2clfu0C9MsjsBrOImzuk8Bpgav/kQzDFqIOLNICI+cyzMiCV+8xEwmiTWjamH4nW4PX3 BM53npNeL+NcDL8riJrOkkZIRdKbjCJzfdlkkYgY/p4+7+9Q4Ppdrrmu/X+lsFVlk2fg 9v2bbjCLvyu3IDGu+gwbaQxXXK+7Ce2oEcZR2SofDGt7OJRS2UMwu2WCaf4YcL2pF3FG 3C+w== MIME-Version: 1.0 X-Received: by 10.224.161.75 with SMTP id q11mr35359844qax.69.1390741866245; Sun, 26 Jan 2014 05:11:06 -0800 (PST) Received: by 10.96.58.101 with HTTP; Sun, 26 Jan 2014 05:11:06 -0800 (PST) In-Reply-To: References: Date: Sun, 26 Jan 2014 21:11:06 +0800 Message-ID: From: "Cao,Zhen" To: "Jim Guichard (jguichar)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "sfc@ietf.org" Subject: Re: [sfc] Progression of use case documents within the SFC working group X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 13:11:10 -0000 Thanks for framing out the way forward. > 1) Have the WG develop one use case document that documents a small number > of representative use cases. The document presented by Hongyu Li at the > Vancouver BOF could serve for this purpose > (http://datatracker.ietf.org/doc/draft-liu-service-chaining-use-cases). Better to refer to http://tools.ietf.org/html/draft-liu-sfc-use-cases-00, some minor difference between the two. -cz From cpignata@cisco.com Sun Jan 26 06:58:26 2014 Return-Path: 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 461C81A0144 for ; Sun, 26 Jan 2014 06:58:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 QJePm5EiS_iv for ; Sun, 26 Jan 2014 06:58:24 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6671A0141 for ; Sun, 26 Jan 2014 06:58:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4029; q=dns/txt; s=iport; t=1390748302; x=1391957902; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=O91G980y8rtFELWsKlrKn7GlKhyosQfeu0OvNwVsdkc=; b=RJuu9m992aQKB7CnxolOfNwih/xRSLb68evTTXaCOaAn1e4pcZVK3Gje uDiJEtcNTWatDYbM/hqXc+/LWO64q8CEs4lBjD0h4xRSaQKPQtwdrxTnN ItYuqVJXNlkgC4M+AM3dXcZF7FnZ4mMseu+csQoQWJ3Lr8aA4RbKKJyt9 8=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4HAFch5VKtJV2Y/2dsb2JhbABagkhEOEoMtAWIU4EDFnSCJQEBAQMBbgsFCwIBCARCMiUCBA4FDodvCA3HYheOKxEBUAeDJIEUBJA9gTKGOIEykGyDLYFxOQ X-IronPort-AV: E=Sophos;i="4.95,724,1384300800"; d="asc'?scan'208,217";a="15620589" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP; 26 Jan 2014 14:58:21 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0QEwLvn004894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Jan 2014 14:58:21 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.76]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Sun, 26 Jan 2014 08:58:21 -0600 From: "Carlos Pignataro (cpignata)" To: "Jim Guichard (jguichar)" Thread-Topic: IPR check for draft-quinn-sfc-problem-statement Thread-Index: AQHPFtu2NSEh36Zfh0G0Wjova3ew6JqXhP6A Date: Sun, 26 Jan 2014 14:58:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.229.159] Content-Type: multipart/signed; boundary="Apple-Mail=_021D233B-3616-4100-974F-DB682AD6FF5F"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Thomas Narten , "sfc@ietf.org" Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 14:58:26 -0000 --Apple-Mail=_021D233B-3616-4100-974F-DB682AD6FF5F Content-Type: multipart/alternative; boundary="Apple-Mail=_F1FCA621-90DF-489B-80DE-B3364B390D5E" --Apple-Mail=_F1FCA621-90DF-489B-80DE-B3364B390D5E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Chairs, I am not aware of relevant IPR applicable to = draft-quinn-sfc-problem-statement-02.txt. Thanks, -- Carlos. On Jan 21, 2014, at 2:05 PM, Jim Guichard (jguichar) = wrote: > This email serves as a poll for knowledge of any IPR that applies to = draft [1], to ensure that IPR has been disclosed in compliance with IETF = IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).=20 >=20 > If you are listed as a document author or contributor please respond = to this email whether or not you are aware of any relevant IPR. The = draft will not be adopted until a response has been received from each = author and major contributor.=20 >=20 > If you are on the SFC WG mailing list but are not listed as an author = or contributor, then please explicitly respond only if you are aware of = any IPR that has not yet been disclosed in conformance with IETF rules.=20= >=20 > Thank you, >=20 > Jim & Thomas > SFC chairs >=20 > [1] http://tools.ietf.org/id/draft-quinn-sfc-problem-statement-02.txt --Apple-Mail=_F1FCA621-90DF-489B-80DE-B3364B390D5E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Chairs,

I am not aware of relevant IPR applicable to draft-quinn-sfc-problem-statement-02.txt.

Thanks,

-- Carlos.

On Jan 21, 2014, at 2:05 PM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:

This email serves as a poll for knowledge of any IPR that applies to draft [1], to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). 

If you are listed as a document author or contributor please respond to this email whether or not you are aware of any relevant IPR. The draft will not be adopted until a response has been received from each author and major contributor. 

If you are on the SFC WG mailing list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. 

Thank you,

Jim & Thomas
SFC chairs


--Apple-Mail=_F1FCA621-90DF-489B-80DE-B3364B390D5E-- --Apple-Mail=_021D233B-3616-4100-974F-DB682AD6FF5F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlLlIpEACgkQtfDPGTp3USzeewCeK6fv7w6mcFMNx99u2IVdfore L18AnAzuekGWRN1fcTdPrH9COi0ws6/O =DCmV -----END PGP SIGNATURE----- --Apple-Mail=_021D233B-3616-4100-974F-DB682AD6FF5F-- From cpignata@cisco.com Sun Jan 26 07:00:35 2014 Return-Path: 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 D34D01A0144 for ; Sun, 26 Jan 2014 07:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 ykPmbNacB-gp for ; Sun, 26 Jan 2014 07:00:33 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id D9E431A0141 for ; Sun, 26 Jan 2014 07:00:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34459; q=dns/txt; s=iport; t=1390748431; x=1391958031; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eCaxPPFcKcy0uKdr4IDsd7PPSCPW1lzEMXOULjCALbA=; b=hMMuQPbruCqklAtyCnHjf7a2RK26fdfq8J8KXAMpbSwBITqovqzogeY3 aOO6o3MCmg/vfTL19GC7FkVDl01EHTxb8vmvvelPtcmwbGL1RhGA+b4OZ 8dH6PuCr2vMRL2JXfdgAoUemte1GGqHtxMhLKUXCQ/xASyGlAM9uPtcYh 8=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtAHAMAi5VKtJXG9/2dsb2JhbABagkhEOFa0BYhTgQMWdIIlAQEBAwEBAQFrAwgFCwIBCA4DAwEBAQEgAQYHJwsUCQgCBA4FCQWHbwgNx2IXjisRAT4BDQQGAYQ4BJA9gTKGOIEykGyDLYFxOQ X-IronPort-AV: E=Sophos;i="4.95,724,1384300800"; d="asc'?scan'208,217";a="299769579" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 26 Jan 2014 15:00:30 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0QF0U06028640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Jan 2014 15:00:30 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.76]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Sun, 26 Jan 2014 09:00:29 -0600 From: "Carlos Pignataro (cpignata)" To: Chris Frederick Thread-Topic: [sfc] IPR check for draft-quinn-sfc-problem-statement Thread-Index: AQHPFtu2NSEh36Zfh0G0Wjova3ew6JqP/DAA//+Ae4CAACuAgIAAih0A//+b94CAAINqgP//fHUAADAazoAAxtQhAA== Date: Sun, 26 Jan 2014 15:00:28 +0000 Message-ID: <68BA82B4-DA2E-441B-A2FA-9138711940EA@cisco.com> References: <1E714095C88C9D408749A723A59CF6ED1C06E441@SJEXCHMB12.corp.ad.broadcom.com> <8F9A3BC8F79F244DB44EC1569235CB4F79FCC918@ORD1EXD04.RACKSPACE.CORP> <64BC961C-E325-40C4-BFFF-0F4F395FF68F@cisco.com> <802F0FD88084CC4D82A0663874219D1A1887DF44@wtl-exchp-2.sandvine.com> In-Reply-To: <802F0FD88084CC4D82A0663874219D1A1887DF44@wtl-exchp-2.sandvine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.229.159] Content-Type: multipart/signed; boundary="Apple-Mail=_6F63ADCE-7589-42FD-872B-CE1DF63B806A"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Thomas Narten , "sfc@ietf.org" , "Jim Guichard \(jguichar\)" , "Michael Smith \(michsmit\)" , Brad McConnell , "Paul Quinn \(paulq\)" Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 15:00:35 -0000 --Apple-Mail=_6F63ADCE-7589-42FD-872B-CE1DF63B806A Content-Type: multipart/alternative; boundary="Apple-Mail=_E5D8A8D3-BC3C-4AFC-8D80-BE98F32FD1E3" --Apple-Mail=_E5D8A8D3-BC3C-4AFC-8D80-BE98F32FD1E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Chris, Just to be clear -- when you say "This is not related to SFC = specifically", are you acknowledging that you know of no IPR with = subject matter related to draft-quinn-sfc-problem-statement-02.txt? Also, if there is any IPR to be disclosed, the actual disclosure should = be done at http://www.ietf.org/ipr/file-disclosure.html and not on the = WG mailing list. Thanks, -- Carlos. On Jan 22, 2014, at 11:07 AM, Chris Frederick = wrote: > Hello, > Sandvine has intellectual property related to the granular steering of = traffic flows, specifically where the session has been established. This = technique enables steering on the basis of application, content, etc, = vs. just the port that would be seen in the initial SYN packet. > This is outlined here: = http://www.google.com/patents/WO2004086714A1?cl=3Den > This is not related to SFC specifically but I bring it to your = attention as this technique can be used to select flows that would then = be redirected through a service function chain or path; Sandvine uses = this mechanism in our own SFC implementation for example. Best regards, > =20 > Chris Frederick > Director, Technology Partnerships > cfrederick@sandvine.com >=20 > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Michael Smith = (michsmit) > Sent: Tuesday, January 21, 2014 8:10 PM > To: Paul Quinn (paulq); Brad McConnell > Cc: Thomas Narten; Jim Guichard (jguichar); sfc@ietf.org > Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement > =20 > I'm not aware of any either. > Michael > =20 > From: "Paul Quinn (paulq)" > Date: Tuesday, January 21, 2014 5:00 PM > To: Brad McConnell > Cc: Thomas Narten , "Jim Guichard (jguichar)" = , "sfc@ietf.org" > Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement > =20 > Me neither. > =20 > Paul > =20 > =20 > On Jan 21, 2014, at 6:11 PM, Brad McConnell = wrote: >=20 >=20 > I'm not aware of any. >=20 > Thank you, >=20 > Brad McConnell >=20 > From: sfc [sfc-bounces@ietf.org] on behalf of Rajeev Manur = [rmanur@broadcom.com] > Sent: Tuesday, January 21, 2014 5:08 PM > To: Jim Guichard (jguichar) > Cc: Thomas Narten; sfc@ietf.org > Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement >=20 > =20 > +1 > =20 > Thanks! > --Rajeev > =20 > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Surendra Kumar = (smkumar) > Sent: Tuesday, January 21, 2014 2:54 PM > To: Jim Guichard (jguichar) > Cc: Thomas Narten; sfc@ietf.org > Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement > =20 > +1 > =20 > Surendra. > =20 > From: "Ken Gray (kegray)" > Date: Tuesday, January 21, 2014 12:18 PM > To: Thomas Nadeau , "Jim Guichard (jguichar)" = > Cc: Thomas Narten , "sfc@ietf.org" > Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement > =20 > Ditto > =20 > From: Thomas Nadeau > Date: Tuesday, January 21, 2014 2:54 PM > To: "Jim Guichard (jguichar)" > Cc: Thomas Narten , "sfc@ietf.org" > Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement > =20 > =20 > None from my end. > =20 > On Jan 21, 2014:2:05 PM, at 2:05 PM, Jim Guichard (jguichar) = wrote: > =20 >=20 > This email serves as a poll for knowledge of any IPR that applies to = draft [1], to ensure that IPR has been disclosed in compliance with IETF = IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).=20 > =20 > If you are listed as a document author or contributor please respond = to this email whether or not you are aware of any relevant IPR. The = draft will not be adopted until a response has been received from each = author and major contributor.=20 > =20 > If you are on the SFC WG mailing list but are not listed as an author = or contributor, then please explicitly respond only if you are aware of = any IPR that has not yet been disclosed in conformance with IETF rules.=20= > =20 > Thank you, > =20 > Jim & Thomas > SFC chairs > =20 > [1] http://tools.ietf.org/id/draft-quinn-sfc-problem-statement-02.txt > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > =20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > =20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail=_E5D8A8D3-BC3C-4AFC-8D80-BE98F32FD1E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Chris,

Just to be clear -- when = you say "This is not related to SFC specifically", are you acknowledging = that you know of no IPR with subject matter related = to draft-quinn-sfc-problem-statement-02.txt?

Also, if there is any IPR to be disclosed, the actual disclosure should = be done at http://www.ietf.org/= ipr/file-disclosure.html and not on the WG mailing = list.

Thanks,

-- = Carlos.

On Jan 22, 2014, at 11:07 AM, Chris = Frederick <cfrederick@sandvine.com> = wrote:

Hello,
Sandvine has intellectual property = related to the granular steering of traffic flows, specifically where = the session has been established. This technique enables steering on the = basis of application, content, etc, vs. just the port that would be seen = in the initial SYN packet.
This = is not related to SFC specifically but I bring it to your attention as = this technique can be used to select flows that would then be redirected = through a service function chain or path; Sandvine uses this mechanism = in our own SFC implementation for example. Best = regards,
 
Chris Frederick
Director, Technology = Partnerships
cfrederick@sandvine.com

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Michael Smith = (michsmit)
Sent: Tuesday, January 21, 2014 = 8:10 PM
To: Paul Quinn (paulq); Brad = McConnell
Cc: Thomas Narten; Jim Guichard = (jguichar); sfc@ietf.org
Subject: Re: [sfc] IPR check for = draft-quinn-sfc-problem-statement
 
I'm not aware of any = either.
Michael
 
From: "Paul Quinn = (paulq)" <paulq@cisco.com>
Date: Tuesday, January 21, = 2014 5:00 PM
To: Brad McConnell <bmcconne@rackspace.com>
Cc: Thomas Narten <narten@us.ibm.com>, "Jim Guichard = (jguichar)" <jguichar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] IPR check for = draft-quinn-sfc-problem-statement
 
Me neither.
 
Paul
 
 
On Jan = 21, 2014, at 6:11 PM, Brad McConnell <bmcconne@rackspace.com> = wrote:


I'm not aware of any.

Thank = you,

Brad McConnell

From: sfc [sfc-bounces@ietf.org] on behalf of Rajeev Manur [rmanur@broadcom.com]
Sent: Tuesday, January 21, 2014 = 5:08 PM
To: Jim Guichard = (jguichar)
Cc: Thomas Narten; sfc@ietf.org
Subject: Re: [sfc] IPR check for = draft-quinn-sfc-problem-statement

 
+1
 
Thanks!
--Rajeev
 
From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Surendra Kumar = (smkumar)
Sent: Tuesday, January 21, 2014 = 2:54 PM
To: Jim Guichard = (jguichar)
Cc: Thomas Narten; sfc@ietf.org
Subject: Re: [sfc] IPR check for = draft-quinn-sfc-problem-statement
 
+1
 
Surendra.
 
From: "Ken Gray = (kegray)" <kegray@cisco.com>
Date: Tuesday, January 21, = 2014 12:18 PM
To: Thomas Nadeau <tnadeau@lucidvision.com>, "Jim Guichard = (jguichar)" <jguichar@cisco.com>
Cc: Thomas Narten <narten@us.ibm.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] IPR check for = draft-quinn-sfc-problem-statement
 
Ditto
 
From: Thomas = Nadeau <tnadeau@lucidvision.com>
Date: Tuesday, January 21, = 2014 2:54 PM
To: "Jim Guichard = (jguichar)" <jguichar@cisco.com>
Cc: Thomas Narten <narten@us.ibm.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] IPR check for = draft-quinn-sfc-problem-statement
 
 
None from my end.
 
On Jan 21, 2014:2:05 PM, at 2:05 PM, Jim Guichard = (jguichar) <jguichar@cisco.com> wrote:

 

This email serves as a poll for knowledge of any = IPR that applies to draft [1], to ensure that IPR has been disclosed in = compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for = more details). 
 
If you are listed as a document author or contributor = please respond to this email whether or not you are aware of any = relevant IPR. The draft will not be adopted until a response has been = received from each author and major contributor. 
 
If you are on the SFC WG mailing list but are not listed as = an author or contributor, then please explicitly respond only if you are = aware of any IPR that has not yet been disclosed in conformance with = IETF rules. 
 
Thank you,
 
Jim & Thomas
SFC chairs
 
_______________________________________________
sfc = mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc
 
_______________________________________________
sfc = mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc
 
________________________= _______________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

= --Apple-Mail=_E5D8A8D3-BC3C-4AFC-8D80-BE98F32FD1E3-- --Apple-Mail=_6F63ADCE-7589-42FD-872B-CE1DF63B806A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlLlIxAACgkQtfDPGTp3USyQgACgz8sU4hseJTC5+CzxLiF2F6aj 9zEAoMHviq6U0SRuRkDLgba82gZpz/Wb =9yLA -----END PGP SIGNATURE----- --Apple-Mail=_6F63ADCE-7589-42FD-872B-CE1DF63B806A-- From cpignata@cisco.com Sun Jan 26 07:05:24 2014 Return-Path: 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 479891A0145 for ; Sun, 26 Jan 2014 07:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 cN-lrJYGzCYZ for ; Sun, 26 Jan 2014 07:05:22 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B08771A0146 for ; Sun, 26 Jan 2014 07:05:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10745; q=dns/txt; s=iport; t=1390748720; x=1391958320; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=I9vu8O0+Aw1PKV/3MsiDRRDywablYhLONFysU/lIxDk=; b=jb0BOBG7SNVU99pv3uiXkPsgtXpP/i5dyhslbhFbVEQX0dFvkrlhaXAv nEkq8oKVyaoU8YaJ8QX8jQdZrENmrNObDFrINy69C328QMitJCPj6qdbs i2dyGnviTwaNWXDSdPfN3mGITk31q0lQGD5ymT9v0xCcwLVQhucr/N9Uz o=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMIALAj5VKtJV2c/2dsb2JhbABagkhEOEoMqUiKPYhTgQMWdIIlAQEBAwEBAQFrCwULAgEIRicLJQIEDgUOBgeHYggNx2IXjw0HgySBFASQPYEyhjiBMpBsgy2CKg X-IronPort-AV: E=Sophos;i="4.95,724,1384300800"; d="asc'?scan'208,217";a="299783538" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 26 Jan 2014 15:05:19 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0QF5J1w004449 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 26 Jan 2014 15:05:19 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.76]) by xhc-rcd-x04.cisco.com ([::1]) with mapi id 14.03.0123.003; Sun, 26 Jan 2014 09:05:18 -0600 From: "Carlos Pignataro (cpignata)" To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] Progression of use case documents within the SFC working group Thread-Index: AQHPGS5B+ZYQfqbdGEGHvCjMISf9v5qXgkuA Date: Sun, 26 Jan 2014 15:05:17 +0000 Message-ID: <0DF60534-3D06-4116-8364-FCA42CF27608@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.229.159] Content-Type: multipart/signed; boundary="Apple-Mail=_4C6D08A4-E457-4BB3-9339-BE36020D30D5"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "sfc@ietf.org" Subject: Re: [sfc] Progression of use case documents within the SFC working group X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 15:05:24 -0000 --Apple-Mail=_4C6D08A4-E457-4BB3-9339-BE36020D30D5 Content-Type: multipart/alternative; boundary="Apple-Mail=_89C6AF08-81ED-4312-8CE2-0343C7C7FFBB" --Apple-Mail=_89C6AF08-81ED-4312-8CE2-0343C7C7FFBB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Jim, Thomas, I support this approach. Thanks, -- Carlos. On Jan 24, 2014, at 1:01 PM, Jim Guichard (jguichar) = wrote: > Greetings, >=20 > The documentation and applicability of use cases for the SFC WG was = discussed during both the Berlin and Vancouver BOFs. The main purpose of = those discussions was to show support for our work and subsequent = formation of a working group. >=20 > As we move forward with our work we would like to solicit opinions of = how best to approach use cases within the WG. The SFC charter left it = open as to whether we should have a single problem statement that = includes use cases or whether to separate out the use cases. >=20 > Some background: >=20 > 1) An important purpose for having use cases is to connect a problem = or solution to a real concrete scenario. On the problem side, a use case = can highlight requirements for any solution. Hence, having SFC use cases = is important. Lack of use cases could lead to missed requirements. >=20 > 2) Having just one use case is probably not enough, but having too = many quickly leads to diminishing returns. The sweet spot is a = relatively small number (3? 4?) that are different enough that they = flesh out the (different) key requirements. We know that more use cases = aren't helping when they simply reaffirm requirements that have already = been made apparent by other use cases. >=20 > 3) Some use cases may be detailed and complicated , i.e., because the = scenario or technology involved is complicated. Or they may be oriented = towards a particular community. Such use cases may warrant having their = own standalone document. >=20 > 4) If we try to put all use cases into a single document, we run the = risk that folk will continue to ask that additional scenarios be added, = making it difficult to close out and finish the document. >=20 > With that in mind, the WG needs to make some choices. We propose: >=20 > 1) Have the WG develop one use case document that documents a small = number of representative use cases. The document presented by Hongyu Li = at the Vancouver BOF could serve for this purpose = (http://datatracker.ietf.org/doc/draft-liu-service-chaining-use-cases). >=20 > 2) Remove "Section 4. Service Function Chaining Use Cases=94 from = draft-quinn-sfc-problem-statement. At present, one section is TBD, and = the other section "3GPP Gi Interface Service Function Chaining=94 would = need significant expansion, and that expansion probably makes more sense = in a separate document. If there was a simple use case that could be = explained (to an IETF reader) in 1-2 pages, we could consider putting it = here, but we'd need a proposal. (Any takers?) >=20 > 3) For additional use cases not covered in 1) above, allow for a small = number of documents that are applicable to specific environments (e.g. = mobility, data center, broadband, and so forth.) These documents would = provide more detailed information and applicability of SFC to these = specific environments, and would need to go beyond what is covered in = the general use case document (1). Note that it is not the intention to = have every potential use case documented. >=20 > Comments? Does the above approach seem reasonable to folks on the = list? Any objections? >=20 > Jim & Thomas > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail=_89C6AF08-81ED-4312-8CE2-0343C7C7FFBB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Jim, = Thomas,

I support this = approach.

Thanks,

-- = Carlos.


On Jan 24, = 2014, at 1:01 PM, Jim Guichard (jguichar) <jguichar@cisco.com> = wrote:

Greetings,

The documentation = and applicability of use cases for the SFC WG was discussed during both = the Berlin and Vancouver BOFs. The main purpose of those discussions was = to show support for our work and subsequent formation of a working group.

As we move forward = with our work we would like to solicit opinions of how best to approach = use cases within the WG. The SFC charter left it open as to whether we = should have a single problem statement that includes use cases or whether to separate out the use cases.

Some = background:

1) An important = purpose for having use cases is to connect a problem or solution to a = real concrete scenario. On the problem side, a use case can highlight = requirements for any solution. Hence, having SFC use cases is important. Lack of use cases could lead to missed = requirements.

2) Having just one = use case is probably not enough, but having too many quickly leads to = diminishing returns. The sweet spot is a relatively small number (3? 4?) = that are different enough that they flesh out the (different) key requirements. We know that more use cases = aren't helping when they simply reaffirm requirements that have already = been made apparent by other use cases.

3) Some use cases = may be detailed and complicated , i.e., because the scenario or = technology involved is complicated. Or they may be oriented towards a = particular community.  Such use cases may warrant having their own standalone document.

4) If we try to = put all use cases into a single document, we run the risk that folk will = continue to ask that additional scenarios be added, making it difficult = to close out and finish the document.

With that in mind, = the WG needs to make some choices. We propose:

1) Have the WG = develop one use case document that documents a small number of = representative use cases.  The document presented by Hongyu Li = at the Vancouver BOF could serve for this purpose (http://datatracker.ietf.org/doc/draft-liu-service-chaining-use-cases).

2) Remove "Section = 4.  Service Function Chaining Use Cases=94 from = draft-quinn-sfc-problem-statement. At present, one section is TBD, =  and the other section "3GPP Gi Interface Service Function = Chaining=94 would need significant expansion, and that expansion probably makes more = sense in a separate document. If there was a simple use case that could = be explained (to an IETF reader) in 1-2 pages, we could consider putting = it here, but we'd need a proposal. (Any takers?)

3) For additional = use cases not covered in 1) above, allow for a small number of documents = that are applicable to specific environments (e.g.  mobility, = data center, broadband, and so forth.) These documents would provide more detailed information and applicability of SFC to = these specific environments, and would need to go beyond what is covered = in the general use case document (1). Note that it is not the intention = to have every potential use case documented.

Comments? Does the = above approach seem reasonable to folks on the list? Any = objections?

Jim & = Thomas
_______________________________________________
sfc mailing = list
sfc@ietf.org
https://www.ietf.org/mail= man/listinfo/sfc

= --Apple-Mail=_89C6AF08-81ED-4312-8CE2-0343C7C7FFBB-- --Apple-Mail=_4C6D08A4-E457-4BB3-9339-BE36020D30D5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlLlJDMACgkQtfDPGTp3USzu0wCfUsZT150Nr/LDJ3eKTRjTP2fS iAEAoKt6t3zuKHcmhSiNL6/6CrL8tnd8 =s0yS -----END PGP SIGNATURE----- --Apple-Mail=_4C6D08A4-E457-4BB3-9339-BE36020D30D5-- From Ron_Parker@affirmednetworks.com Sun Jan 26 07:07:24 2014 Return-Path: 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 126521A0147 for ; Sun, 26 Jan 2014 07:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 nsPDiWrt0axL for ; Sun, 26 Jan 2014 07:07:19 -0800 (PST) Received: from hub021-ca-1.exch021.serverdata.net (hub021-ca-1.exch021.serverdata.net [64.78.22.168]) by ietfa.amsl.com (Postfix) with ESMTP id 717201A0146 for ; Sun, 26 Jan 2014 07:07:19 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-1.exch021.domain.local ([10.254.4.30]) with mapi id 14.03.0158.001; Sun, 26 Jan 2014 07:07:17 -0800 From: Ron Parker To: "Carlos Pignataro (cpignata)" , "Jim Guichard (jguichar)" Thread-Topic: [sfc] Progression of use case documents within the SFC working group Thread-Index: AQHPGS5B+ZYQfqbdGEGHvCjMISf9v5qXgkuA//+byYA= Date: Sun, 26 Jan 2014 15:07:17 +0000 Message-ID: References: <0DF60534-3D06-4116-8364-FCA42CF27608@cisco.com> In-Reply-To: <0DF60534-3D06-4116-8364-FCA42CF27608@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.20.29.62] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A799112MBX021W3CA2exch_" MIME-Version: 1.0 Cc: "sfc@ietf.org" Subject: Re: [sfc] Progression of use case documents within the SFC working group X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 15:07:24 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A799112MBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jim, I am in favor of this approach, too. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpig= nata) Sent: Sunday, January 26, 2014 10:05 AM To: Jim Guichard (jguichar) Cc: sfc@ietf.org Subject: Re: [sfc] Progression of use case documents within the SFC working= group Jim, Thomas, I support this approach. Thanks, -- Carlos. On Jan 24, 2014, at 1:01 PM, Jim Guichard (jguichar) > wrote: Greetings, The documentation and applicability of use cases for the SFC WG was discuss= ed during both the Berlin and Vancouver BOFs. The main purpose of those dis= cussions was to show support for our work and subsequent formation of a wor= king group. As we move forward with our work we would like to solicit opinions of how b= est to approach use cases within the WG. The SFC charter left it open as to= whether we should have a single problem statement that includes use cases = or whether to separate out the use cases. Some background: 1) An important purpose for having use cases is to connect a problem or sol= ution to a real concrete scenario. On the problem side, a use case can high= light requirements for any solution. Hence, having SFC use cases is importa= nt. Lack of use cases could lead to missed requirements. 2) Having just one use case is probably not enough, but having too many qui= ckly leads to diminishing returns. The sweet spot is a relatively small num= ber (3? 4?) that are different enough that they flesh out the (different) k= ey requirements. We know that more use cases aren't helping when they simpl= y reaffirm requirements that have already been made apparent by other use c= ases. 3) Some use cases may be detailed and complicated , i.e., because the scena= rio or technology involved is complicated. Or they may be oriented towards = a particular community. Such use cases may warrant having their own standa= lone document. 4) If we try to put all use cases into a single document, we run the risk t= hat folk will continue to ask that additional scenarios be added, making it= difficult to close out and finish the document. With that in mind, the WG needs to make some choices. We propose: 1) Have the WG develop one use case document that documents a small number = of representative use cases. The document presented by Hongyu Li at the Va= ncouver BOF could serve for this purpose (http://datatracker.ietf.org/doc/d= raft-liu-service-chaining-use-cases). 2) Remove "Section 4. Service Function Chaining Use Cases" from draft-quin= n-sfc-problem-statement. At present, one section is TBD, and the other sec= tion "3GPP Gi Interface Service Function Chaining" would need significant e= xpansion, and that expansion probably makes more sense in a separate docume= nt. If there was a simple use case that could be explained (to an IETF read= er) in 1-2 pages, we could consider putting it here, but we'd need a propos= al. (Any takers?) 3) For additional use cases not covered in 1) above, allow for a small numb= er of documents that are applicable to specific environments (e.g. mobilit= y, data center, broadband, and so forth.) These documents would provide mor= e detailed information and applicability of SFC to these specific environme= nts, and would need to go beyond what is covered in the general use case do= cument (1). Note that it is not the intention to have every potential use c= ase documented. Comments? Does the above approach seem reasonable to folks on the list? Any= objections? Jim & Thomas _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A799112MBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jim,

 <= /p>

I am in favor of this app= roach, too.

 <= /p>

   Ron

 <= /p>

 <= /p>

From: sfc [m= ailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpignata)
Sent: Sunday, January 26, 2014 10:05 AM
To: Jim Guichard (jguichar)
Cc: sfc@ietf.org
Subject: Re: [sfc] Progression of use case documents within the SFC = working group

 

Jim, Thomas,

 

I support this approach.

 

Thanks,

 

-- Carlos.

 

 

On Jan 24, 2014, at 1:01 PM, Jim Guichard (jguichar)= <jguichar@cisco.com> wrote= :



Greetings,

 

The documentation and applicability of u= se cases for the SFC WG was discussed during both the Berlin and Vancouver = BOFs. The main purpose of those discussions was to show support for our work and subsequent formation of a working group.

 

As we move forward with our work we woul= d like to solicit opinions of how best to approach use cases within the WG.= The SFC charter left it open as to whether we should have a single problem statement that includes use cases or whether to separate = out the use cases.

 

Some background:

 

1) An important purpose for having use c= ases is to connect a problem or solution to a real concrete scenario. On th= e problem side, a use case can highlight requirements for any solution. Hence, having SFC use cases is important. Lack of use cases = could lead to missed requirements.

 

2) Having just one use case is probably = not enough, but having too many quickly leads to diminishing returns. The s= weet spot is a relatively small number (3? 4?) that are different enough that they flesh out the (different) key requirements. We = know that more use cases aren't helping when they simply reaffirm requireme= nts that have already been made apparent by other use cases.

 

3) Some use cases may be detailed and co= mplicated , i.e., because the scenario or technology involved is complicate= d. Or they may be oriented towards a particular community.  Such use cases may warrant having their own standalone document.

 

4) If we try to put all use cases into a= single document, we run the risk that folk will continue to ask that addit= ional scenarios be added, making it difficult to close out and finish the document.

 

With that in mind, the WG needs to make = some choices. We propose:

 

1) Have the WG develop one use case docu= ment that documents a small number of representative use cases.  = The document presented by Hongyu Li at the Vancouver BOF could serve for this purpose (http://datatracker.ietf.org/doc/draft-liu-service-= chaining-use-cases).

 

2) Remove "Section 4.  Se= rvice Function Chaining Use Cases” from draft-quinn-sfc-problem-state= ment. At present, one section is TBD,  and the other section "3GP= P Gi Interface Service Function Chaining” would need significant expansion, and tha= t expansion probably makes more sense in a separate document. If there was = a simple use case that could be explained (to an IETF reader) in 1-2 pages,= we could consider putting it here, but we'd need a proposal. (Any takers?)

 

3) For additional use cases not covered = in 1) above, allow for a small number of documents that are applicable to s= pecific environments (e.g.  mobility, data center, broadband, and so forth.) These documents would provide more detailed information and= applicability of SFC to these specific environments, and would need to go = beyond what is covered in the general use case document (1). Note that it i= s not the intention to have every potential use case documented.

 

Comments? Does the above approach seem r= easonable to folks on the list? Any objections?

 

Jim & Thomas

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

 

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A799112MBX021W3CA2exch_-- From zhuangyuxin@huawei.com Sun Jan 26 17:06:34 2014 Return-Path: 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 5D7741A00C0 for ; Sun, 26 Jan 2014 17:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 ILYkdu9fgdy8 for ; Sun, 26 Jan 2014 17:06:32 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 307981A00BD for ; Sun, 26 Jan 2014 17:06:32 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCY26203; Mon, 27 Jan 2014 01:06:28 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 27 Jan 2014 01:06:13 +0000 Received: from SZXEMA404-HUB.china.huawei.com (10.82.72.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 27 Jan 2014 01:06:26 +0000 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.128]) by SZXEMA404-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0158.001; Mon, 27 Jan 2014 09:06:21 +0800 From: Zhuangyuxin To: "sfc@ietf.org" Thread-Topic: Services eligible for chaining Thread-Index: Ac8aTJ6FwniRxzcWRuaQFnPfr+bu1gAr0QHA Date: Mon, 27 Jan 2014 01:06:21 +0000 Message-ID: <9C2DE4B8FE85984BA1B0581235F6B2ED0F633EAB@SZXEMA502-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.75.59] Content-Type: multipart/alternative; boundary="_000_9C2DE4B8FE85984BA1B0581235F6B2ED0F633EABSZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [sfc] Services eligible for chaining X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 01:06:34 -0000 --_000_9C2DE4B8FE85984BA1B0581235F6B2ED0F633EABSZXEMA502MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Folks, For SFC, do you have any concrete service candidates which are eligible for= chaining? How about load balancer and NAT, which usually cross subnets and= change packet header? Are they suitable for the chain we are discussing he= re? Thanks, Yuxin --_000_9C2DE4B8FE85984BA1B0581235F6B2ED0F633EABSZXEMA502MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, Folks,=

 

For SFC, do you have any concre= te service candidates which are eligible for chaining? How about load balan= cer and NAT, which usually cross subnets and change packet header? Are they= suitable for the chain we are discussing here?

 

Thanks,

Yuxin

--_000_9C2DE4B8FE85984BA1B0581235F6B2ED0F633EABSZXEMA502MBSchi_-- From Ron_Parker@affirmednetworks.com Sun Jan 26 17:29:28 2014 Return-Path: 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 19D431A016C for ; Sun, 26 Jan 2014 17:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 zU1Nge0SUKkl for ; Sun, 26 Jan 2014 17:29:26 -0800 (PST) Received: from hub021-ca-2.exch021.serverdata.net (hub021-ca-2.exch021.serverdata.net [64.78.22.169]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC5C1A015C for ; Sun, 26 Jan 2014 17:29:26 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0158.001; Sun, 26 Jan 2014 17:29:24 -0800 From: Ron Parker To: Zhuangyuxin , "sfc@ietf.org" Thread-Topic: Services eligible for chaining Thread-Index: Ac8aTJ6FwniRxzcWRuaQFnPfr+bu1gAr0QHAAADQNHA= Date: Mon, 27 Jan 2014 01:29:23 +0000 Message-ID: References: <9C2DE4B8FE85984BA1B0581235F6B2ED0F633EAB@SZXEMA502-MBS.china.huawei.com> In-Reply-To: <9C2DE4B8FE85984BA1B0581235F6B2ED0F633EAB@SZXEMA502-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.20.29.62] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A7992B5MBX021W3CA2exch_" MIME-Version: 1.0 Subject: Re: [sfc] Services eligible for chaining X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 01:29:28 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A7992B5MBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yuxin, Both load balancer and NAT are definitely candidates for SFC service functi= ons. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Zhuangyuxin Sent: Sunday, January 26, 2014 8:06 PM To: sfc@ietf.org Subject: [sfc] Services eligible for chaining Hello, Folks, For SFC, do you have any concrete service candidates which are eligible for= chaining? How about load balancer and NAT, which usually cross subnets and= change packet header? Are they suitable for the chain we are discussing he= re? Thanks, Yuxin --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A7992B5MBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yuxin= ,

=  

Both = load balancer and NAT are definitely candidates for SFC service functions.<= o:p>

=  

 = ;  Ron

=  

=  

From: = sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Zhuangyuxin
Sent: Sunday, January 26, 2014 8:06 PM
To: sfc@ietf.org
Subject: [sfc] Services eligible for chaining

 =

Hello, Fo= lks,

&nbs= p;

For SFC, = do you have any concrete service candidates which are eligible for chaining= ? How about load balancer and NAT, which usually cross subnets and change p= acket header? Are they suitable for the chain we are discussing here?

&nbs= p;

Thanks,

Yuxin

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A7992B5MBX021W3CA2exch_-- From haibin.song@huawei.com Sun Jan 26 17:49:32 2014 Return-Path: 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 0BA361A0172 for ; Sun, 26 Jan 2014 17:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 c_ld2KkI9YEN for ; Sun, 26 Jan 2014 17:49:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 916CB1A015C for ; Sun, 26 Jan 2014 17:49:29 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCY28089; Mon, 27 Jan 2014 01:49:26 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 27 Jan 2014 01:49:10 +0000 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 27 Jan 2014 01:49:23 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Mon, 27 Jan 2014 09:49:13 +0800 From: "Songhaibin (A)" To: Ron Parker , Zhuangyuxin , "sfc@ietf.org" Thread-Topic: Services eligible for chaining Thread-Index: Ac8aTJ6FwniRxzcWRuaQFnPfr+bu1gAr0QHAAADQNHAAAK730A== Date: Mon, 27 Jan 2014 01:49:12 +0000 Message-ID: References: <9C2DE4B8FE85984BA1B0581235F6B2ED0F633EAB@SZXEMA502-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.70] Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F24829478nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [sfc] Services eligible for chaining X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 01:49:32 -0000 --_000_E33E01DFD5BEA24B9F3F18671078951F24829478nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I guess it also implies that the original packet as the payload can be chan= ged by the service functions. Best Regards! -Haibin From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Monday, January 27, 2014 9:29 AM To: Zhuangyuxin; sfc@ietf.org Subject: Re: [sfc] Services eligible for chaining Yuxin, Both load balancer and NAT are definitely candidates for SFC service functi= ons. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Zhuangyuxin Sent: Sunday, January 26, 2014 8:06 PM To: sfc@ietf.org Subject: [sfc] Services eligible for chaining Hello, Folks, For SFC, do you have any concrete service candidates which are eligible for= chaining? How about load balancer and NAT, which usually cross subnets and= change packet header? Are they suitable for the chain we are discussing he= re? Thanks, Yuxin --_000_E33E01DFD5BEA24B9F3F18671078951F24829478nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I guess= it also implies that the original packet as the payload can be changed by = the service functions.

&n= bsp;

Best Re= gards!

-Haibin=

&n= bsp;

From: sfc [mailto:= sfc-bounces@ietf.org] On Behalf Of Ron Parker
Sent: Monday, January 27, 2014 9:29 AM
To: Zhuangyuxin; sfc@ietf.org
Subject: Re: [sfc] Services eligible for chaining<= /p>

 

Yuxin,

 

Both load balancer and NAT are definitely candidates for SFC serv= ice functions.

 

   Ron

 

 

From: sfc [= mailto:sfc-bounces@ietf.org] On Behalf Of Zhuangyuxin
Sent: Sunday, January 26, 2014 8:06 PM
To: sfc@ietf.org
Subject: [sfc] Services eligible for chaining

 

Hello, Folks,=

 

For SFC, do you have any concre= te service candidates which are eligible for chaining? How about load balan= cer and NAT, which usually cross subnets and change packet header? Are they= suitable for the chain we are discussing here?

 

Thanks,

Yuxin

--_000_E33E01DFD5BEA24B9F3F18671078951F24829478nkgeml501mbschi_-- From zhuangyuxin@huawei.com Sun Jan 26 18:31:57 2014 Return-Path: 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 3D3C71A0177 for ; Sun, 26 Jan 2014 18:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.215 X-Spam-Level: * X-Spam-Status: No, score=1.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 MboM4yuliLvS for ; Sun, 26 Jan 2014 18:31:55 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 758381A00D4 for ; Sun, 26 Jan 2014 18:31:54 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCY30170; Mon, 27 Jan 2014 02:31:51 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 27 Jan 2014 02:31:35 +0000 Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 27 Jan 2014 02:31:48 +0000 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.128]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Mon, 27 Jan 2014 10:31:45 +0800 From: Zhuangyuxin To: Ron Parker , "sfc@ietf.org" Thread-Topic: Services eligible for chaining Thread-Index: Ac8aTJ6FwniRxzcWRuaQFnPfr+bu1gAr0QHAAADQNHAAABcD4A== Date: Mon, 27 Jan 2014 02:31:44 +0000 Message-ID: <9C2DE4B8FE85984BA1B0581235F6B2ED0F633F22@SZXEMA502-MBS.china.huawei.com> References: <9C2DE4B8FE85984BA1B0581235F6B2ED0F633EAB@SZXEMA502-MBS.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.75.59] Content-Type: multipart/alternative; boundary="_000_9C2DE4B8FE85984BA1B0581235F6B2ED0F633F22SZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [sfc] =?gb2312?b?tPC4tDogU2VydmljZXMgZWxpZ2libGUgZm9yIGNoYWluaW5n?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 02:31:57 -0000 --_000_9C2DE4B8FE85984BA1B0581235F6B2ED0F633F22SZXEMA502MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIFJvbiwNCg0KVGhhbmtzIGZvciB0aGUgcmVwbHkuDQoNCldoZW4gd2UgY29uc2lkZXIgaW5z ZXJ0aW5nIExCL05BVCBpbiB0aGUgY2hhaW4sIEkgaGF2ZSBzb21lIGZ1cnRoZXIgcXVlc3Rpb25z IGhlcmUuDQoNCi0gICAgICAgIExldKGvcyB0YWtlIGEgY2hhaW4gd2l0aCBOQVQgc2VydmljZSBm dW5jdGlvbiBhcyBhbiBleGFtcGxlLCB1c2VyIGlzIHVzaW5nIHRoaXMgY2hhaW4gdG8gcHJvY2Vz cyB0cmFmZmljIHByb2R1Y2VkIGJ5IFZNMSBhY2Nlc3NpbmcgSW50ZXJuZXQuIEkgYXNzdW1lIHRo ZSB0b3BvbG9neSBpcyBsaWtlIHRoaXM6DQogICAgICAgICBWTTEgIC0tLSAoY2hhaW4gaW5jbHVk aW5nIE5BVCkgLS0tIFJvdXRlciAtLS0gSW50ZXJuZXQNCiAgICAgICAgIFdoZW4gdHJhZmZpYyBm cm9tIEludGVybmV0IGFycml2ZXMgYXQgdGhlIHJvdXRlciwgaXRzIGRlc3RJUCBwb2ludHMgYXQg TkFULiBIb3cgZG9lcyB0aGUgcm91dGVyIGRlY2lkZSB0aGUgbmV4dCBob3A/DQotICAgICAgICBB cyB0aGUgcGFja2V0IGlzIGRpcmVjdGx5IGFkZHJlc3NlZCB0byB0aGUgTkFULCBkb2VzIGl0IGNv bmZsaWN0IHdpdGggdGhlIKGudHJhbnNwYXJlbnQgbWlkYm94oa8gY29uY2VwdCBpbiBkcmFmdC1w YXJrZXItc2ZjLWNoYWluLXRvLXBhdGgtMDA/DQotICAgICAgICBJcyBpdCBwb3NzaWJsZSBmb3Ig dGhlIFJvdXRlciB0byBzZW5kIG91dCBBUlAgdG8gcXVlcnkgZm9yIHRoZSBJUCBhZGRyZXNzIG9u IE5BVD8gSG93IGRvZXMgTkFUIHJlYWN0IHRvIEFSUCByZXF1ZXN0IGVzcGVjaWFsbHkgd2hlbiBO QVQgaXMgU0ZDLWF3YXJlPw0KDQpUaGFua3MsDQpZdXhpbg0KDQq3orz+yMs6IFJvbiBQYXJrZXIg W21haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tXQ0Kt6LLzcqxvOQ6IDIwMTTE 6jHUwjI3yNUgOToyOQ0KytW8/sjLOiBaaHVhbmd5dXhpbjsgc2ZjQGlldGYub3JnDQrW98ziOiBS RTogU2VydmljZXMgZWxpZ2libGUgZm9yIGNoYWluaW5nDQoNCll1eGluLA0KDQpCb3RoIGxvYWQg YmFsYW5jZXIgYW5kIE5BVCBhcmUgZGVmaW5pdGVseSBjYW5kaWRhdGVzIGZvciBTRkMgc2Vydmlj ZSBmdW5jdGlvbnMuDQoNCiAgIFJvbg0KDQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWmh1YW5neXV4aW4NClNlbnQ6IFN1bmRheSwgSmFudWFy eSAyNiwgMjAxNCA4OjA2IFBNDQpUbzogc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBbc2ZjXSBTZXJ2aWNlcyBlbGlnaWJsZSBmb3IgY2hhaW5pbmcNCg0KSGVsbG8s IEZvbGtzLA0KDQpGb3IgU0ZDLCBkbyB5b3UgaGF2ZSBhbnkgY29uY3JldGUgc2VydmljZSBjYW5k aWRhdGVzIHdoaWNoIGFyZSBlbGlnaWJsZSBmb3IgY2hhaW5pbmc/IEhvdyBhYm91dCBsb2FkIGJh bGFuY2VyIGFuZCBOQVQsIHdoaWNoIHVzdWFsbHkgY3Jvc3Mgc3VibmV0cyBhbmQgY2hhbmdlIHBh Y2tldCBoZWFkZXI/IEFyZSB0aGV5IHN1aXRhYmxlIGZvciB0aGUgY2hhaW4gd2UgYXJlIGRpc2N1 c3NpbmcgaGVyZT8NCg0KVGhhbmtzLA0KWXV4aW4NCg== --_000_9C2DE4B8FE85984BA1B0581235F6B2ED0F633F22SZXEMA502MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Ron= ,

&n= bsp;

Thanks = for the reply.

&n= bsp;

When we= consider inserting LB/NAT in the chain, I have some further questions here= .

&n= bsp;

- =        Let=A1=AFs take a chain with NAT servi= ce function as an example, user is using this chain to process traffic prod= uced by VM1 accessing Internet. I assume the topology is like this:

 &= nbsp;       VM1  --- (chain including NA= T) --- Router --- Internet

   &nb= sp;     When traffic from Internet arrives at the route= r, its destIP points at NAT. How does the router decide the next hop?<= /o:p>

-   &n= bsp;    As the packet is directly addressed to the NAT, does= it conflict with the =A1=AEtransparent midbox=A1=AF concept in draft-parke= r-sfc-chain-to-path-00?

-   &n= bsp;    Is it possible for the Router to send out ARP to que= ry for the IP address on NAT? How does NAT react to ARP request especially = when NAT is SFC-aware?

&n= bsp;

Thanks,=

Yuxin

&n= bsp;

=B7=A2=BC=FE=C8=CB: Ron Parker [mailto:Ron_Parker@affirmednetwo= rks.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C227=C8=D5 9:29
=CA=D5=BC=FE=C8=CB: Zhuangyuxin; sfc@ietf.org
=D6=F7=CC=E2: RE: Services eligible for chaining

 

Yuxin,

 

Both load balancer and NAT are definitely candidates for SFC serv= ice functions.

 

   Ron

 

 

From: sfc [= mailto:sfc-bounces@ietf.org] On Behalf Of Zhuangyuxin
Sent: Sunday, January 26, 2014 8:06 PM
To: sfc@ietf.org
Subject: [sfc] Services eligible for chaining

 

Hello, Folks,=

 

For SFC, do you have any concre= te service candidates which are eligible for chaining? How about load balan= cer and NAT, which usually cross subnets and change packet header? Are they= suitable for the chain we are discussing here?

 

Thanks,

Yuxin

--_000_9C2DE4B8FE85984BA1B0581235F6B2ED0F633F22SZXEMA502MBSchi_-- From melinda.shore@gmail.com Sun Jan 26 18:57:02 2014 Return-Path: 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 724FB1A0185 for ; Sun, 26 Jan 2014 18:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no 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 PRgLbMU0aLI8 for ; Sun, 26 Jan 2014 18:57:01 -0800 (PST) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 665A71A00D4 for ; Sun, 26 Jan 2014 18:57:01 -0800 (PST) Received: by mail-pd0-f176.google.com with SMTP id w10so5186039pde.35 for ; Sun, 26 Jan 2014 18:56:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=AaR89eb/3ZKXTjkDiLsXWP6ATAcXv+BZ0WEOyzlFZp0=; b=eN5p9rfho+eC2gsTGeakkTKZFh/PjrQqk92Z8BaYmopKXwzS7dFO8SH5ncVhQ8lgnB +N2gapNhtsKFnMuOGZ5SGYF4cnXnEzU8z1q3srA/jmQ5ZI+m6WJmXI1crsKWBHqF2SF0 oqhzmejPzh0zWmZ5yXw+B3kfuiN5raS2+Sb01Fa3wuAFo0wVTU3UXWqS/feTJPJpS/sn wJQSiHMmGopu+Ft+1Z4CXWXRzP5CnhU/ygiIiTaN6P8QSqkbW2zBGayHK/hqqL5PhyRT CWLN1vAnr38ouw/EznhBnpUZEl+PwL94jUl7Wk9I3ovK3BtwvDyDKuFKZZD6MKppYf8f U2KQ== X-Received: by 10.66.121.234 with SMTP id ln10mr27647453pab.20.1390791419538; Sun, 26 Jan 2014 18:56:59 -0800 (PST) Received: from spandex.local (216-67-22-153-rb3.fai.dsl.dynamic.acsalaska.net. [216.67.22.153]) by mx.google.com with ESMTPSA id vf7sm26844867pbc.5.2014.01.26.18.56.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 Jan 2014 18:56:58 -0800 (PST) Message-ID: <52E5CAF7.80603@gmail.com> Date: Sun, 26 Jan 2014 17:56:55 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: sfc@ietf.org References: <9C2DE4B8FE85984BA1B0581235F6B2ED0F633EAB@SZXEMA502-MBS.china.huawei.com> <9C2DE4B8FE85984BA1B0581235F6B2ED0F633F22@SZXEMA502-MBS.china.huawei.com> In-Reply-To: <9C2DE4B8FE85984BA1B0581235F6B2ED0F633F22@SZXEMA502-MBS.china.huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [sfc] =?utf-8?b?562U5aSNOiBTZXJ2aWNlcyBlbGlnaWJsZSBmb3IgY2hhaW5p?= =?utf-8?q?ng?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 02:57:02 -0000 On 1/26/14 5:31 PM, Zhuangyuxin wrote: > When traffic from Internet arrives at the router, its destIP > points at NAT. How does the router decide the next hop? > > - As the packet is directly addressed to the NAT, does it > conflict with the ‘transparent midbox’ concept in > draft-parker-sfc-chain-to-path-00? > > - Is it possible for the Router to send out ARP to query for the > IP address on NAT? How does NAT react to ARP request especially when NAT > is SFC-aware? When I first read this I thought "Well, yes, and NAT is particularly sensitive to network topology (device ordering)." But, I think this needn't actually create a particularly difficult problem here, since the original packet is going to be encapsulated by the SFC transport." However, there can be the usual problems with service ordering that you find within a single box - for example, you need to be attentive to which addresses you're putting into your firewalling rules, etc. But that's going to be true, regardless whether the services are decomposed into different boxes or co-resident within the same box. Similarly, the NAT-from-the-outside problem exists whether or not you're using SFC. If there's interest I can contribute a draft on middlebox considerations. Melinda From mohamed.boucadair@orange.com Sun Jan 26 22:50:52 2014 Return-Path: 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 A94B81A01C9 for ; Sun, 26 Jan 2014 22:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 Hz40EtUXZG1y for ; Sun, 26 Jan 2014 22:50:49 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 11E0C1A00FD for ; Sun, 26 Jan 2014 22:50:48 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 4394422C5AA; Mon, 27 Jan 2014 07:50:46 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 15B7735C045; Mon, 27 Jan 2014 07:50:46 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Mon, 27 Jan 2014 07:50:45 +0100 From: To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Date: Mon, 27 Jan 2014 07:50:44 +0100 Thread-Topic: Progression of use case documents within the SFC working group Thread-Index: AQHPGS5B+ZYQfqbdGEGHvCjMISf9v5qYJNjA Message-ID: <94C682931C08B048B7A8645303FDC9F36F473607AF@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36F473607AFPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.26.232114 Subject: Re: [sfc] Progression of use case documents within the SFC working group X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 06:50:52 -0000 --_000_94C682931C08B048B7A8645303FDC9F36F473607AFPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jim, all, I support the adoption of draft-liu-service-chaining-use-cases as a place t= o record some the use cases already discussed in this list. As I'm the author of the "3GPP Gi Interface Service Function Chaining" sect= ion of the PS document, I'm fine to remove that text from the PS and merge = it with the text of draft-liu-service-chaining-use-cases. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard (jguichar= ) Envoy=E9 : vendredi 24 janvier 2014 19:01 =C0 : sfc@ietf.org Objet : [sfc] Progression of use case documents within the SFC working grou= p Greetings, The documentation and applicability of use cases for the SFC WG was discuss= ed during both the Berlin and Vancouver BOFs. The main purpose of those dis= cussions was to show support for our work and subsequent formation of a wor= king group. As we move forward with our work we would like to solicit opinions of how b= est to approach use cases within the WG. The SFC charter left it open as to= whether we should have a single problem statement that includes use cases = or whether to separate out the use cases. Some background: 1) An important purpose for having use cases is to connect a problem or sol= ution to a real concrete scenario. On the problem side, a use case can high= light requirements for any solution. Hence, having SFC use cases is importa= nt. Lack of use cases could lead to missed requirements. 2) Having just one use case is probably not enough, but having too many qui= ckly leads to diminishing returns. The sweet spot is a relatively small num= ber (3? 4?) that are different enough that they flesh out the (different) k= ey requirements. We know that more use cases aren't helping when they simpl= y reaffirm requirements that have already been made apparent by other use c= ases. 3) Some use cases may be detailed and complicated , i.e., because the scena= rio or technology involved is complicated. Or they may be oriented towards = a particular community. Such use cases may warrant having their own standa= lone document. 4) If we try to put all use cases into a single document, we run the risk t= hat folk will continue to ask that additional scenarios be added, making it= difficult to close out and finish the document. With that in mind, the WG needs to make some choices. We propose: 1) Have the WG develop one use case document that documents a small number = of representative use cases. The document presented by Hongyu Li at the Va= ncouver BOF could serve for this purpose (http://datatracker.ietf.org/doc/d= raft-liu-service-chaining-use-cases). 2) Remove "Section 4. Service Function Chaining Use Cases" from draft-quin= n-sfc-problem-statement. At present, one section is TBD, and the other sec= tion "3GPP Gi Interface Service Function Chaining" would need significant e= xpansion, and that expansion probably makes more sense in a separate docume= nt. If there was a simple use case that could be explained (to an IETF read= er) in 1-2 pages, we could consider putting it here, but we'd need a propos= al. (Any takers?) 3) For additional use cases not covered in 1) above, allow for a small numb= er of documents that are applicable to specific environments (e.g. mobilit= y, data center, broadband, and so forth.) These documents would provide mor= e detailed information and applicability of SFC to these specific environme= nts, and would need to go beyond what is covered in the general use case do= cument (1). Note that it is not the intention to have every potential use c= ase documented. Comments? Does the above approach seem reasonable to folks on the list? Any= objections? Jim & Thomas --_000_94C682931C08B048B7A8645303FDC9F36F473607AFPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jim, all,<= /o:p>

 

I support the adoption of draft-liu-service-chaining-use-cases as a = place to record some the use cases already discussed in this list.

 

As I’m the author of the "3GPP Gi Interface Service Functio= n Chaining” section of the PS document, I’m fine to remove that= text from the PS and merge it with the text of draft-liu-service-chaining-= use-cases.

 =

Cheers,

Med<= o:p>

 

=

De : sfc [mailto:= sfc-bounces@ietf.org] De la part de Jim Guichard (jguichar)
En= voy=E9 : vendredi 24 janvier 2014 19:01
=C0 : sfc@i= etf.org
Objet : [sfc] Progression of use case documents with= in the SFC working group

 

Greetings,

 <= /p>

The documentation and applicability= of use cases for the SFC WG was discussed during both the Berlin and Vanco= uver BOFs. The main purpose of those discussions was to show support for ou= r work and subsequent formation of a working group.

 

<= p class=3DMsoNormal>As we move forward with our work we would like to = solicit opinions of how best to approach use cases within the WG. The SFC c= harter left it open as to whether we should have a single problem statement= that includes use cases or whether to separate out the use cases.

 <= /p>

Some background:<= /p>

 

<= div>

1) An important purpose for having use cases = is to connect a problem or solution to a real concrete scenario. On the pro= blem side, a use case can highlight requirements for any solution. Hence, h= aving SFC use cases is important. Lack of use cases could lead to missed re= quirements.

=  

2) Having just = one use case is probably not enough, but having too many quickly leads to d= iminishing returns. The sweet spot is a relatively small number (3? 4?) tha= t are different enough that they flesh out the (different) key requirements= . We know that more use cases aren't helping when they simply reaffirm requ= irements that have already been made apparent by other use cases.

 

3) Some use cases may be detailed an= d complicated , i.e., because the scenario or technology involved is compli= cated. Or they may be oriented towards a particular community.  S= uch use cases may warrant having their own standalone document.<= /span>

 

=

4) If we try to put all use cases into= a single document, we run the risk that folk will continue to ask that add= itional scenarios be added, making it difficult to close out and finish the= document.

&= nbsp;

With that in min= d, the WG needs to make some choices. We propose:

 

1) Have the WG develop one use case document that do= cuments a small number of representative use cases.  The document= presented by Hongyu Li at the Vancouver BOF could serve for this purpose (= http://datatracker.ietf.org/doc/draft-liu-service-chaining-use-cases<= /a>).

= --_000_94C682931C08B048B7A8645303FDC9F36F473607AFPUEXCB1Bnante_-- From prvs=0976c44aa=Nicolas.BOUTHORS@qosmos.com Mon Jan 27 01:22:41 2014 Return-Path: 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 C3BFD1A016A for ; Mon, 27 Jan 2014 01:22:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.593 X-Spam-Level: X-Spam-Status: No, score=0.593 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 5TSuodQWw557 for ; Mon, 27 Jan 2014 01:22:40 -0800 (PST) Received: from smtp-ft4.fr.colt.net (smtp-ft4.fr.colt.net [213.41.78.208]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0B61A0163 for ; Mon, 27 Jan 2014 01:22:39 -0800 (PST) Received: from smtp-ex5.fr.colt.net (smtp-ex5.fr.colt.net [213.41.78.121]) by smtp-ft4.fr.colt.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s0R9MaTp029642 for ; Mon, 27 Jan 2014 10:22:36 +0100 Received: from mx1.qosmos.com ([195.68.92.43] helo=mx3.qosmos.com) by smtp-ex5.fr.colt.net with esmtp (Exim) (envelope-from ) id 1W7iOo-0000oy-1a for ; Mon, 27 Jan 2014 10:22:34 +0100 X-IronPort-AV: E=Sophos;i="4.95,728,1384297200"; d="jpg'145?scan'145,208,217,145";a="814610" Received: from unknown (HELO mailbox.jungle.qosmos.com) ([10.12.1.3]) by mx3.qosmos.com with ESMTP; 27 Jan 2014 10:22:32 +0100 Received: from LILAS.jungle.qosmos.com ([fe80::5524:2c18:b2c3:74d4]) by CAROUBIER.jungle.qosmos.com ([169.254.1.72]) with mapi id 14.01.0438.000; Mon, 27 Jan 2014 10:22:31 +0100 From: Nicolas BOUTHORS To: "sfc@ietf.org" Thread-Topic: Note on GI deployment scenario draft-liu-sfc-use-cases-00 Thread-Index: AQHPG0E50IKowRRhXEC5c6zdZjgHZQ== Date: Mon, 27 Jan 2014 09:22:31 +0000 Message-ID: <76B41B8FACE1514795D30EC137FF391D3D08E0@LILAS.jungle.qosmos.com> Accept-Language: en-US, fr-FR Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.13.0.22] Content-Type: multipart/related; boundary="_004_76B41B8FACE1514795D30EC137FF391D3D08E0LILASjungleqosmos_"; type="multipart/alternative" MIME-Version: 1.0 X-ACL-Warn: 1/1 recipients OK. Subject: [sfc] Note on GI deployment scenario draft-liu-sfc-use-cases-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 09:22:42 -0000 --_004_76B41B8FACE1514795D30EC137FF391D3D08E0LILASjungleqosmos_ Content-Type: multipart/alternative; boundary="_000_76B41B8FACE1514795D30EC137FF391D3D08E0LILASjungleqosmos_" --_000_76B41B8FACE1514795D30EC137FF391D3D08E0LILASjungleqosmos_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, On Gi deployments the GGSN connects to a Radius Function at PDP Context Set= up Time. In most case this is used to perform and MSISDN to IP address mapping, which is then use= d by the Gi service infrastructure to decide how to handle the IP flows for that particular subscriber. This information cannot be derived by the DPI located after the GGSN. (It c= ould if the DPI were to be located on the other side of the GGSN, the Gn in= terface). It is clear that we should update the diagram to show the Radius traffic go= through the DPI so that the DPI can extract the information and add it to = the metadata which will be collected later as the subscriber traffic goes t= hrough. Something like: Chain 0: GGSN send Radius traffic to Radius server via the DPI so that the = DPI can establish the IP/MSISDN correlation [cid:235d1f6b-4d5d-4879-ba8f-ac940522e34f] Nicolas --_000_76B41B8FACE1514795D30EC137FF391D3D08E0LILASjungleqosmos_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,

On Gi deployments the GGSN connects to a Radius Function at PDP Context Set= up Time. In most case
this is used to perform and MSISDN to IP address mapping, which is the= n used by the Gi service infrastructure
to decide how to handle the IP flows for that particular subscriber.

This information cannot be derived by the DPI located after the GGSN. = (It could if the DPI were to be located on the other side of the GGSN, the = Gn interface).

It is clear that we should update the diagram to show the Radius traff= ic go through the DPI so that the DPI can extract the information and add i= t to the metadata which will be collected later as the subscriber traffic g= oes through. 

Something like:

Chain 0: GGSN send Radius traffic to Radius server via the DPI so that= the DPI can establish the IP/MSISDN correlation

 






Nicolas

--_000_76B41B8FACE1514795D30EC137FF391D3D08E0LILASjungleqosmos_-- --_004_76B41B8FACE1514795D30EC137FF391D3D08E0LILASjungleqosmos_ Content-Type: image/jpeg; name="Capture.JPG" Content-Description: Capture.JPG Content-Disposition: inline; filename="Capture.JPG"; size=34434; creation-date="Mon, 27 Jan 2014 09:20:42 GMT"; modification-date="Mon, 27 Jan 2014 09:20:42 GMT" Content-ID: <235d1f6b-4d5d-4879-ba8f-ac940522e34f> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/4RDSRXhpZgAATU0AKgAAAAgABAE7AAIAAAAEZGNoAIdpAAQA AAABAAAISpydAAEAAAAIAAAQwuocAAcAAAgMAAAAPgAAAAAc6gAAAAgAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFkAMAAgAAABQAABCY kAQAAgAAABQAABCskpEAAgAAAAM0OAAAkpIAAgAAAAM0OAAA6hwABwAACAwAAAiMAAAAABzqAAAA CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAMjAxNDowMToyNyAxMDoyMjowOQAyMDE0OjAxOjI3IDEwOjIyOjA5AAAAZABjAGgAAAD/4QsW aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49J++7vycgaWQ9J1c1 TTBNcENlaGlIenJlU3pOVGN6a2M5ZCc/Pg0KPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczpt ZXRhLyI+PHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJk Zi1zeW50YXgtbnMjIj48cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0idXVpZDpmYWY1YmRkNS1i YTNkLTExZGEtYWQzMS1kMzNkNzUxODJmMWIiIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcvZGMv ZWxlbWVudHMvMS4xLyIvPjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSJ1dWlkOmZhZjViZGQ1 LWJhM2QtMTFkYS1hZDMxLWQzM2Q3NTE4MmYxYiIgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUu Y29tL3hhcC8xLjAvIj48eG1wOkNyZWF0ZURhdGU+MjAxNC0wMS0yN1QxMDoyMjowOS40NzU8L3ht cDpDcmVhdGVEYXRlPjwvcmRmOkRlc2NyaXB0aW9uPjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0 PSJ1dWlkOmZhZjViZGQ1LWJhM2QtMTFkYS1hZDMxLWQzM2Q3NTE4MmYxYiIgeG1sbnM6ZGM9Imh0 dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIj48ZGM6Y3JlYXRvcj48cmRmOlNlcSB4bWxu czpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPjxyZGY6 bGk+ZGNoPC9yZGY6bGk+PC9yZGY6U2VxPg0KCQkJPC9kYzpjcmVhdG9yPjwvcmRmOkRlc2NyaXB0 aW9uPjwvcmRmOlJERj48L3g6eG1wbWV0YT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgPD94cGFja2V0IGVuZD0ndyc/Pv/bAEMABwUFBgUEBwYF BggHBwgKEQsKCQkKFQ8QDBEYFRoZGBUYFxseJyEbHSUdFxgiLiIlKCkrLCsaIC8zLyoyJyorKv/b AEMBBwgICgkKFAsLFCocGBwqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKv/AABEIARoCPAMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUG BwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR 8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5 eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj 5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQAC AQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXx FxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqS k5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T1 9vf4+fr/2gAMAwEAAhEDEQA/APn6iiiv0k5AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAop0aeZIqblXcQNzHAHua6TxN4Gv/AAtHYtqNzaBrxEZU E6MRnOT8jN8o+X5jjO7jODjmqYqhSqxozklKV7Lq7b29ASbTfY5mium8TeBr/wALR2Lajc2ga8RG VBOjEZzk/IzfKPl+Y4zu4zg4PE3ga/8AC0di2o3NoGvERlQToxGc5PyM3yj5fmOM7uM4OMKeZ4Kr yclRPnvy+dt7enUpwkr3WxzNFdN4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHB4m8DX /haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHBTzPBVeTkqJ89+Xztvb06g4SV7rY5mium8TeBr /wALR2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg4PE3ga/8AC0di2o3NoGvERlQToxGc5PyM3yj5 fmOM7uM4OCnmeCq8nJUT578vnbe3p1Bwkr3WxzNFdN4m8DX/AIWjsW1G5tA14iMqCdGIznJ+Rm+U fL8xxndxnBweJvA1/wCFo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcFPM8FV5OSonz35fO29vT qDhJXutjmaK6bxN4Gv8AwtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODg8TeBr/AMLR2Lajc2ga 8RGVBOjEZzk/IzfKPl+Y4zu4zg4KeZ4KryclRPnvy+dt7enUHCSvdbHM0V03ibwNf+Fo7FtRubQN eIjKgnRiM5yfkZvlHy/McZ3cZwcHibwNf+Fo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcFPM8F V5OSonz35fO29vTqDhJXutjmaK6bxN4Gv/C0di2o3NoGvERlQToxGc5PyM3yj5fmOM7uM4ODxN4G v/C0di2o3NoGvERlQToxGc5PyM3yj5fmOM7uM4OCnmeCq8nJUT578vnbe3p1Bwkr3WxzNFdN4m8D X/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHB4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vz HGd3GcHBTzPBVeTkqJ89+Xztvb06g4SV7rY5mium8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8o+X5 jjO7jODg8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODgp5ngqvJyVE+e/L523t6dQcJK 91sczRXTeJvA1/4WjsW1G5tA14iMqCdGIznJ+Rm+UfL8xxndxnBweJvA1/4WjsW1G5tA14iMqCdG IznJ+Rm+UfL8xxndxnBwU8zwVXk5KifPfl87b29OoOEle62OZorpvE3ga/8AC0di2o3NoGvERlQT oxGc5PyM3yj5fmOM7uM4ODxN4Gv/AAtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODgp5ngqvJyV E+e/L523t6dQcJK91sczRXTeJvA1/wCFo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcHibwNf8A haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHBTzPBVeTkqJ89+Xztvb06g4SV7rY5mium8TeBr/ AMLR2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg4PE3ga/wDC0di2o3NoGvERlQToxGc5PyM3yj5f mOM7uM4OCnmeCq8nJUT578vnbe3p1Bwkr3WxzNFdN4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8v zHGd3GcHB4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHBTzPBVeTkqJ89+Xztvb06g4S V7rY5mium8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODg8TeBr/wtHYtqNzaBrxEZUE6 MRnOT8jN8o+X5jjO7jODgp5ngqvJyVE+e/L523t6dQcJK91sczRXTeJvA1/4WjsW1G5tA14iMqCd GIznJ+Rm+UfL8xxndxnBweJvA1/4WjsW1G5tA14iMqCdGIznJ+Rm+UfL8xxndxnBwU8zwVXk5Kif Pfl87b29OoOEle62OZorpvE3ga/8LR2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg4b4p8EX/AISt 7OXUZ7YtdRq6xJOjtyCTgKzZUfL8xxncMZwcFLMsHWdNU6ifPfl87b29OockuxzdFFFegSFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAVPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelRRp5kipuVdxA3McAe5rovFPgi/8JW9n LqM9sWuo1dYknR25BJwFZsqPl+Y4zuGM4OOWpiMPCtClUkueV+VdXbe36jSbvYwri+u7wYu7qace Y0uJZC3ztjc3Pc7Rk98D0ouL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKK3VOCtZbCJ7i+u7wYu 7qaceY0uJZC3ztjc3Pc7Rk98D0ouL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKFTgrWWwE9xfX d4MXd1NOPMaXEshb52xubnudoye+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUFFCpwVrLYC e4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qFFDSKr MEBIBZs4X3OOa1fEOkWukXFqLC/a/t7m3E6TNB5WfnZeFJJxlMgnBwRkA8Vk5UYVI07au9tPv1tZ fqPV3KFxfXd4MXd1NOPMaXEshb52xubnudoye+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ74HpU FFaqnBWsthE9xfXd4MXd1NOPMaXEshb52xubnudoye+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ 74HpUFFCpwVrLYCe4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3P c7Rk98D0qCrd7p0thFZyTMjC8txcR7SeFLMuDx1yp/SptTi4xsk9bfrYNWR3F9d3gxd3U048xpcS yFvnbG5ue52jJ74HpRcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelQUVSpwVrLYCe4vru8GLu6mnH mNLiWQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qCihU4K1lsBPcX13eDF3 dTTjzGlxLIW+dsbm57naMnvgelFxfXd4MXd1NOPMaXEshb52xubnudoye+B6VBRQqcFay2AnuL67 vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSi4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KkvdOlsIrOSZ kYXluLiPaTwpZlweOuVP6VUqYKnJKUErLb9Q1J7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0ouL6 7vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKpU4K1lsBPcX13eDF3dTTjzGlxLIW+dsbm57naMnvge lFxfXd4MXd1NOPMaXEshb52xubnudoye+B6VBRQqcFay2AnuL67vBi7uppx5jS4lkLfO2Nzc9ztG T3wPSi4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KgooVOCtZbAT3F9d3gxd3U048xpcSyFvnbG5u e52jJ74HpRcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelQUUKnBWstgJ7i+u7wYu7qaceY0uJZC3z tjc3Pc7Rk98D0ouL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKFTgrWWwE9xfXd4MXd1NOPMaXE shb52xubnudoye+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUUaeZIqblXcQNzHAHua6LxT4 Iv8Awlb2cuoz2xa6jV1iSdHbkEnAVmyo+X5jjO4Yzg4551sNSqwoyaUpX5V1dt7fqNJu9jm6KKK6 xBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFT3F9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUUaeZIqblXcQNzHAHua6LxT4 Iv8Awlb2cuoz2xa6jV1iSdHbkEnAVmyo+X5jjO4Yzg45amIw8K0KVSS55X5V1dt7fqNJu9jm6KKK 6hBRVu906Wwis5JmRheW4uI9pPClmXB465U/pVSpjOM1zRegBRRRVAOjKCVDMrNGGG5VbaSO4Bwc H3wa29f1jSNUsrGLTtMvbSWziECvPfpMrRhnblREnzZfrnGB071hUVhOhCdSNSV7x21a/BOz+YJ2 CiiitwCiinwxrLcRxvKkKuwVpZASqAn7x2gnA68An2NJuyuAtvcTWlxHcWsskM0TB45Y2KsjDkEE cg+9b+reOtf1a3sIptX1LFpGmd97I3mSq7MsvXhhkAHkjaOaztY0C/0OSP7YiPBPuNvdwOJIbgA4 JRxw2MjI6jOCAeKtaX4b+2a7o1he3XkR6sqtHLDH5rJuZkUFSVydy+vQ59q82s8DUjHFVEpWTadr 6Le1r39ClzJtIiu/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIou/FniO/WJb7X9UuRDKs0Qmv ZH2SL91xk8MOxHIrTu/CVjYaK+o3t/fQIXt3t0exjJnt5txWQYmOG2xyHYfQDPORB4m8M2nh+8tR DqUt3ZysY5pDaiOSCRQpkjKbyCyh1/iAJJHbNc9Ktlk5xhTir629x9Em7O1tn8ynz2uynd+LPEd+ sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWn4h8J WGkrqy6dqtzeTaRdLb3Sz2QgUkllyjCR88r0IU457Gue03T5tV1S2sLXb51zKsSbzhQScZJ7CtqH 9n1aXtqcFyx/u2tpfZpNaO4pc8XZsvXfizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkUXPi7xJe iIXniDVbgQyiaLzb2RvLcdHGTwwycEc1raf4a8M6pqVtZWPie6aae6W2CvpO0vu4Dp+9IK5x94qe enaodR8J22neHp9SkvLtHzA9pDNaIouIZt5RyyyttOI5CVwcYHPPGEa+WKcafIlLSydNr4nbS8V1 3/Edp9/xK+u+NNa1/T7SzvtSv5YIYRHLHNePIszhmbzCDxnDAc5+71rAq3e6dLYRWckzIwvLcXEe 0nhSzLg8dcqf0qpXp4WlQo0lHDpKPkQ23a4UUUV0iCiiigAooooAKKKKACiird7p0thFZyTMjC8t xcR7SeFLMuDx1yp/Spc4pqLerAqVPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelRRp5kipuVdxA3 McAe5rovFPgi/wDCVvZy6jPbFrqNXWJJ0duQScBWbKj5fmOM7hjODjnqYjDwrQpVJLnlflXV23t+ o0m72ObooorqEFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAVPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelRRp5kipuVdxA 3McAe5rovFPgi/8ACVvZy6jPbFrqNXWJJ0duQScBWbKj5fmOM7hjODjlqYjDwrQpVJLnlflXV23t +o0m72ObqS3uJrS4juLWWSGaJg8csbFWRhyCCOQfeo6K6WlJWYjo9W8da/q1vYRTavqWLSNM772R vMlV2ZZevDDIAPJG0c1Tu/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIqHVtJ/suPT287zfttm t1jZt2bmYbepz93rx1rOrgw+EwXs4ulTjbW2n3lOUur6fga934s8R36xLfa/qlyIZVmiE17I+yRf uuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZFFbLB4ZWtTjptotBc0u5r3fizx HfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkUXfizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkVkUU LB4ZWtTjptotA5pdzXu/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIou/FniO/WJb7X9UuRDKs 0QmvZH2SL91xk8MOxHIrIooWDwytanHTbRaBzS7mvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4Yd iORRd+J9Z1ZYoNf1jVNSsllWR7ea9ds49N24BsEgHBxnoelZFFCweGjblppW2skrenb5BzS7m9ee KrkRxWnh9ZNFsIXEiQ207b5JAQRLLJwXcYGDgKuPlVcnNyf4ha5d3WjyXl/f3MWnNE7wT3rutw8c pcOwPfkDPJ4rlat3unS2EVnJMyMLy3FxHtJ4Usy4PHXKn9K55ZfgrxjKCvra++u+u7fne4cz1t2/ A62f4iQagsMOq6N59rBqgvY4YrkR4iVSI7fJQ/Ku4845BPTORBqnji11zS7yz1bS5ZfOvhdxSwSW 1u6cENvMduPMZgTljjnbxwc8dRWUclwEJKUadmttXprfTXS/W260ehXtJdzpvGfjKfxZqDTCTU4r ZpGl+x3eom5iick/6sbFCAA4AwfrWHpeoS6Tq1rqFuFaW2lWVVccMQc4Psaq0V20cHQoUFhqcbQt a3l+ZMpOTuztIfHkOm6fBY6Ja6pDaR3sN19lu9V8+FRHIZNqII025bBJOenrzUOs/EC71XTfssNu bKSLUvtlrPDNhreNVIjiXAH3NxIYY6niuRorkjk+BjP2ip63vdtvXzu9fmV7ST/r+u50ereOtf1a 3sIptX1LFpGmd97I3mSq7MsvXhhkAHkjaOap3fizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkVT vdOlsIrOSZkYXluLiPaTwpZlweOuVP6VUrajgsFGC9lTjZXtovmLml36fga934s8R36xLfa/qlyI ZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZFFarB4ZWtTjpto tBc0u5r3fizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkUXfizxHfrEt9r+qXIhlWaITXsj7JF+6 4yeGHYjkVkUULB4ZWtTjptotA5pdzXu/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIou/FniO/ WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIrIooWDwytanHTbRaBzS7mvd+LPEd+sS32v6pciGVZohNe yPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWRRQsHhla1OOm2i0Dml3Ne 58XeJL0RC88QarcCGUTRebeyN5bjo4yeGGTgjmrGu+NNa1/T7SzvtSv5YIYRHLHNePIszhmbzCDx nDAc5+71rArR1bSf7Lj09vO837bZrdY2bdm5mG3qc/d68daxeFwUKsP3cVJX5dPvGpS116fgZ1T3 F9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUUaeZIqblXcQNzHAHua6LxT4Iv/AAlb2cuoz2xa6jV1 iSdHbkEnAVmyo+X5jjO4Yzg42qYjDwrQpVJLnlflXV23t+okm72ObooorqEFFFFABRRWpe6ZDYeH 7C4naT7dfM0qRZG1LcHarEYzlmD456KDzuGM51IwlGL3k7L7r/oCVzLp8M0ttcRz28jxTRMHjkjY qyMDkEEdCD3rRvdMhsPD9hcTtJ9uvmaVIsjaluDtViMZyzB8c9FB53DGXShUhWi2tVqvu0YNWNe7 8WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecii78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Eci siislg8MrWpx020Wg+aXc17vxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKLvxZ4jv1iW+1/VL kQyrNEJr2R9ki/dcZPDDsRyKyKKFg8MrWpx020Wgc0u5r3fizxHfrEt9r+qXIhlWaITXsj7JF+64 yeGHYjkVHqPibXtYthbatreo30AYOIrm7kkUMMgHDEjPJ596zKKccJhoNONOKttotPQOaXcKKltj ALuE3iyNbiRfNWIgOUz8wUkEA4zjIrQ1TTING8TNaXTST2KSq6yQsA01u2GV1JGAWQgjI4zyKuVa MZ8nW1/W2/6feK2lzKorQ13S/wCx9auLNZPNhUh4Jh0liYBo3H+8pU/jWfV06kakFOOz1Q2rOwUU UVYgooooAKKKKACiird7p0thFZyTMjC8txcR7SeFLMuDx1yp/Spc4pqLerAqUUUVQBRRRQAUVbvd OlsIrOSZkYXluLiPaTwpZlweOuVP6VUqYzjNc0XoAUUUVQBRRVu906Wwis5JmRheW4uI9pPClmXB 465U/pUucU1FvVgVKnuL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKbim02tgCiird7p0thFZyT MjC8txcR7SeFLMuDx1yp/Sk5xTUW9WBe8Q39tfQ6MtrJ5httNjgl+Uja4dyRz14I5HFY1aOraT/Z cent53m/bbNbrGzbs3Mw29Tn7vXjrWdWGFVNUYqk7xG76ei/IKKt3unS2EVnJMyMLy3FxHtJ4Usy 4PHXKn9KqVvGcZrmi9BBRRRVAFFFFABRRRQBJb3E1pcR3FrLJDNEweOWNirIw5BBHIPvW/q3jrX9 Wt7CKbV9SxaRpnfeyN5kquzLL14YZAB5I2jmucormq4WhWnGpUgm47NrYabWxr3fizxHfrEt9r+q XIhlWaITXsj7JF+64yeGHYjkUXfizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkVTvdOlsIrOSZk YXluLiPaTwpZlweOuVP6VUqKeFwjSlCnGy20XzHzS7mvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ 4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWRVu906Wwis5JmRheW4uI9pPClmXB46 5U/pR9VwkHGPs4p620XzsHNJ9S5d+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRc+LvEl6Ihe eINVuBDKJovNvZG8tx0cZPDDJwRzWRRVLBYVWtTjptohc0u5v67401rX9PtLO+1K/lghhEcsc148 izOGZvMIPGcMBzn7vWsCiiroYelh4ezoxUV2QNt7hRRVu906Wwis5JmRheW4uI9pPClmXB465U/p WrnFNRb1YipRRRVAFFFFABRRRQAVs+Ib+2vodGW1k8w22mxwS/KRtcO5I568Ecjis2xsptRvobO1 8vzpm2IJJVjUn3ZiAPxNaV74U1bT7G8u7pLVYbG4FtPsvoHZZT/CFVyWPXoD91v7pxx1qmHVeHtJ pSWyutb6bb+nmNX1t/XX9DGqe4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KijTzJFTcq7iBuY4A9 zXReKfBF/wCErezl1Ge2LXUausSTo7cgk4Cs2VHy/McZ3DGcHFVMRh4VoUqklzyvyrq7b2/UEm72 ObooorqEFFFFAEtsIDdwi8aRbcyL5rRKC4TPzFQSATjOMmtDVNTg1nxM13dLJBYvKqLHCoLQ264V UUE4JVAAMnnHJqPVtJ/suPT287zfttmt1jZt2bmYbepz93rx1rOrmjGnXtWi+jSf5/kvuHqlbuaG u6p/bGtXF4sflQsQkEI6RRKAsaD/AHVCj8Kz6KK2pwjTgoR2WiBu7uFFFFWIKKKKACiiigArUvdT hv8Aw/YW86yfbrFmiSTA2vbk7lUnOcqxfHHRgONozl0VnOnGcoye8Xdfdb9QTsal7qcN/wCH7C3n WT7dYs0SSYG17cncqk5zlWL446MBxtGcuitHVtJ/suPT287zfttmt1jZt2bmYbepz93rx1rOHs6D VJdbtfm/zHqzOoooroEFFFFABRRRQBJb3E1pcR3FrLJDNEweOWNirIw5BBHIPvW/q3jrX9Wt7CKb V9SxaRpnfeyN5kquzLL14YZAB5I2jmucrak8NTHUNFsrWZZZtWgjlTeNixl3ZcE5PA25z+lcOJp4 R1I1K8VzK9m1sktRxbV7DLvxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKLvxZ4jv1iW+1/VLk QyrNEJr2R9ki/dcZPDDsRyKujw9ot/JFa6Br8t3fy3KW8cFzYGBZNxx5iuHYbR/tbT7dcQ3ek+Hv s5OleIpJ7gTrEIrqwMCuCceYHDsNo/2tp6cdcckZ5fdJUrNf9O5K1/8At3RPu7J69mU+bq/xILvx Z4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKLnxd4kvRELzxBqtwIZRNF5t7I3luOjjJ4YZOCOa3 9T8B2Wl6hZWl3qOqW8t1fC1UXOjGISL0M0TGTbIgYoOoOGBxVLWPCNto2k6jcTajNJcWl3FbxRpa r5U6SBnSQSeZkAojEjaSDgepGNHFZTUcFTitdvcfV2093a+je3cbU9blXXfGmta/p9pZ32pX8sEM IjljmvHkWZwzN5hB4zhgOc/d61gVbvdOlsIrOSZkYXluLiPaTwpZlweOuVP6VUr1sLSoUaSjh0lH yIbbtcKKKfDGstxHG8qQq7BWlkBKoCfvHaCcDrwCfY10N2VxC29xNaXEdxayyQzRMHjljYqyMOQQ RyD71v6t461/Vrewim1fUsWkaZ33sjeZKrsyy9eGGQAeSNo5rO1jQL/Q5I/tiI8E+4293A4khuAD glHHDYyMjqM4IB4qa50SKzu9HjuLp/K1G3jnd0hBaIM7KQFLDcRtz1GfavOqfUazhWmlJ2dna+29 v6/Ed3G/p+Al34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+ yRfuuMnhh2I5FaWseFNNsZNRFhq9zdjSLryNQWWxWJ0TzPL8yMCVg43cYJU/MvqSH674S03S31NL PV7u5bSbtba882wWIYLMu6MiVtxyp4O3I+hxywr5W3FRgvL3GrXt/d0vzLe17o0caivf8zKufF3i S9EQvPEGq3AhlE0Xm3sjeW46OMnhhk4I5qxrvjTWtf0+0s77Ur+WCGERyxzXjyLM4Zm8wg8ZwwHO fu9aPEeiaVo9rYPp+p3l5LewLcqk9ikKrGSw5Ilf5sr0xjB69qo6tpP9lx6e3neb9ts1usbNuzcz Db1Ofu9eOtbUYZfVdOpTgr68vu29dGlYm809+n4FjxDf219Doy2snmG202OCX5SNrh3JHPXgjkcV lW9xNaXEdxayyQzRMHjljYqyMOQQRyD71an0t7V9P+0zwxR30SzLIdxWNC7JlsAnjaTwDx0yeKk1 jQL/AEOSP7YiPBPuNvdwOJIbgA4JRxw2MjI6jOCAeK6aMsPCEaCle97X69/XzJ1av5I0dW8da/q1 vYRTavqWLSNM772RvMlV2ZZevDDIAPJG0c1Tu/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIps Ph29uNQ0qzhMTS6oivB8xwoZ2T5jjjBUk9eK0l8J22qgr4U1T+05o5lhljuYVtM7jhHRnkIZS3y/ NsbLL8vPHF/wl4ZKPLFJa35dFd9Xa0bu61auVeTW/T8DPu/FniO/WJb7X9UuRDKs0QmvZH2SL91x k8MOxHIou/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIqW+8Ha1ppUXsNvHmcW7kXsDCCQ5wsu HPlHg/f2/dPoaZrnha/8P3ptr2fT5HExhzb6hDL8w7lQ25B7sBWlOWVylGNPkb1tbl+dv1G/aK97 jbvxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKLvxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDs RyKsXHhDUE1yw0i1Ec15fQLJEpuYNjkkjCSLIyMPlwOQSeMdMt1LwXrmk232i/toY4t6puW8hfqS A3yufl3AqW+6GBUnIIpRnlV4Ri6d3rFe7ez7Lz/EXv67kN34s8R36xLfa/qlyIZVmiE17I+yRfuu Mnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FJq3h650rULOybEk11Cki7ZInRixIG 143ZWXI65H0FT6j4L1zS7eGa5t7d0nufskf2a9huGabum2N2ORxnjjI9RVReWLktyK/w/Cr97f8A AD39SG78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecii58XeJL0RC88QarcCGUTRebeyN5bjo4y eGGTgjmlv/C2q6asT3SWpjlm+z+bDewzRxyf3XdHKxnqfmI4BPY4fq3g/W9DtTcanaxxRgK3y3UT sUb7sgVWJKHoHA2k8ZzRF5W3BR9nrfl+HXvb9bB7/mSa7401rX9PtLO+1K/lghhEcsc148izOGZv MIPGcMBzn7vWsCrd7p0thFZyTMjC8txcR7SeFLMuDx1yp/Sq8May3EcbypCrsFaWQEqgJ+8doJwO vAJ9jXXh6dChStQilHXZfeS23a4tvcTWlxHcWsskM0TB45Y2KsjDkEEcg+9b+reOtf1a3sIptX1L FpGmd97I3mSq7MsvXhhkAHkjaOaztY0C/wBDkj+2IjwT7jb3cDiSG4AOCUccNjIyOozggHirEvhq b7fo1nazLLNq0Ecqbl2CMu7LgnJ4G3Of0rnqPA1nCvPllo7PfRb6jXMm0uwy78WeI79Ylvtf1S5E MqzRCa9kfZIv3XGTww7Ecii78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecipr3SdBFpIdJ8QTX l2kgjW3l08w+dkgbkbew29T8209Pl5OK+oeGdU01YWmhhmSeUwxvZ3MVypk4+TMTMA3I+U81FP8A s98qUIxetk48r87KST9bDfP3HXfizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkUXfizxHfrEt9r +qXIhlWaITXsj7JF+64yeGHYjkVfXwLqlvJFJqqpBZfaktbia2nhuXt5GOArRrJkN1+VsHg+lQa3 4M1fRLzyJoFmD3RtY/JljkcyfwqyIxMbEchWwevoazp1cplNQpuF9bW5fnZ7eqWvV7h79m3f+v6Z XufF3iS9EQvPEGq3AhlE0Xm3sjeW46OMnhhk4I5qxrvjTWtf0+0s77Ur+WCGERyxzXjyLM4Zm8wg 8ZwwHOfu9aq6r4a1PRrdbi9jgaEyGIy213FcKj4zsYxswVsZIDYJwcdDVW906Wwis5JmRheW4uI9 pPClmXB465U/pW1Ojl83CpSjF2vytW+drCvNN37fgVKKKK9MkKKKKACiiigArc8QeJ5det7SJ4Fg 8vMtwytk3NwwAeZvchV49cnvWHVu906Wwis5JmRheW4uI9pPClmXB465U/pXPUp0ZVYTmveV7fdq NN7IqVPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelQUVu4ptNrYQUUUUwCinwxrLcRxvKkKuwVpZ ASqAn7x2gnA68An2NX9Y0C/0OSP7YiPBPuNvdwOJIbgA4JRxw2MjI6jOCAeKylWpxmqbdm9l39O4 WZP4hv7a+h0ZbWTzDbabHBL8pG1w7kjnrwRyOKxqt3unS2EVnJMyMLy3FxHtJ4Usy4PHXKn9KqVO HhCFJRpu6B9PRfkFFOjCGVBMzLGWG5lXcQO5AyMn2yK6TVfDFhBJpdvoup3N7d6nGksSXdrFaoqM WAy5mYBsr0OBz17VNXFUqM1Co7Xv0dtN7u1l82hpNnM0Vt6j4P1nSZIkv4baIyT/AGYkXsDCKX+5 IQ5ER/39vQ+ho1nwlqWiaiLKdrK5nac26JZXsU7M+cY2Ixdcn+8BURx2Fm4qNSLvdrVa23t6DcZL dGJRWxf+FtV01YnuktTHLN9n82G9hmjjk/uu6OVjPU/MRwCexxaufAfiGzkiS6tbeJpmQRhr6D5g /wBx/v8A+rJ4D/dJ4znik8wwaSbqx1vb3lrbe2vTqLll2Odorb1LwhrekyRpeWiGSSf7MI7e4inZ Zv8AnmyxsxR/9lsHg+hpt74U1bT/ACTcJaGOWb7OJor+CWOOT+67q5WM9T85HAJ7HFRx2Fkk41Yu +2q1tvbXoDjJboxqK2Nf8MX3hu6eC/msJWSVoj9lvopjkeqqxZf+BAVj1tRrU68FUpSUovqgaadm FbPiG/tr6HRltZPMNtpscEvykbXDuSOevBHI4rGrR1bSf7Lj09vO837bZrdY2bdm5mG3qc/d68da zqKm60HJ+9rb9QV9bdv1RnUUUV0iCiiigAooooAK6S+1+ODUPDl9prrLNpllCrq6kASJI7FT0yME dPWubq3e6dLYRWckzIwvLcXEe0nhSzLg8dcqf0rlrUqVScfaeat3utfwBdbdv1R1Efj5dM0yOx8P 2+pW9ul1HcC3vdU+0QKEcvtWMRptBY5Jyc49eajfxnYxaKuj2dhqn9lPdRTT2N3q5liMauXaNAsa bNxPLcnv15rkKK5P7HwV78mt7/FLfvvq10e66F+0kdXD4p0iwWCDTNHvorNdQivpoZtSWQs0YYIq HyRs++ckhiQB6U3UPGsk+kPYWFvNabNRS9tLk3O6a3CiT93uVVyA8rMCACCT1zxy1FWsrwnNzuN3 5uT++7d/n002Fzv+v68zo9W8da/q1vYRTavqWLSNM772RvMlV2ZZevDDIAPJG0c1Tu/FniO/WJb7 X9UuRDKs0QmvZH2SL91xk8MOxHIqne6dLYRWckzIwvLcXEe0nhSzLg8dcqf0qpV0cFgowXsqcbK9 tF8w5pd+n4Gvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+J9Z1ZYoNf1jVNSsllWR7ea9 ds49N24BsEgHBxnoelZFPhjWW4jjeVIVdgrSyAlUBP3jtBOB14BPsa0+qYaCTVNK21lqvS2v3C5p dzX1TxE91ZDTNJt/7L0kcm0jlZjO39+ZuPMbgdgo/hVcnM2qarYzXPh+Rd9zHZWMUdxGhMbblkdi oYqQDgjnBHPeqOsaBf6HJH9sRHgn3G3u4HEkNwAcEo44bGRkdRnBAPFQXunS2EVnJMyMLy3FxHtJ 4Usy4PHXKn9K56dHCTjB03o72s977tvdvzvcHfVPt+Ghvav4q0y+k1NrHSbu1OsXQmvzLfrKWTzD IY48RLsBYg5O77q++U8X+MpPFeqCaRtVWyaYzNY3Op+ekZJPEXyAIMHA4OP0rl6KqnlmEpzjUjHW N7NtvdJPd9klfdW0KdSTvfqb/iPW9K1i1sE0/TLyzlsoFt1ee+SZWjBY8gRJ82W65xgdO9N1rV0k fQptLupEnsdPijaSPcjRSq7ng8cjIORWFVu906Wwis5JmRheW4uI9pPClmXB465U/pVRwmHpckF0 vZNt3vvvd/iLmbfy/DT/AIBsat411XXbewtNXv8AUrmzgjRLiF752+0EOzF/mBAbDYBIbGB16VFe eKrkRxWnh9ZNFsIXEiQ207b5JAQRLLJwXcYGDgKuPlVcnNLVtJ/suPT287zfttmt1jZt2bmYbepz 93rx1rOqKGDwTpxdKC5Vey6ettr+drg5S69jqrn4i+IrmXS5H1O+k+wKhaO4u3ljnkV2beyk4PDB ec8DrVjR/EWi2+s2Uen2X9i2st9FcX1xc3DXOI43DiNAse5VyOhDsSFy2Ac8xe6dLYRWckzIwvLc XEe0nhSzLg8dcqf0qpWf9l4KpS5aceVNNe7p36bNp6q6dmDk2tex1fibWdGEmqWnh6CQi/uFlmuz dtLG6gl9savDG6jcwzu3H5cZPU1Na13SNXujdf2JNDc3NwJ72U324t/eWIbAIwSSfmEhHy4PBzz9 FbUsvoU1G17rrzSu7pJ3112XkraWHKo5O52a+MNCi1jRNQg0HURJo4jWNX1VCJFQswBxbjncwyfQ YxzkQS+LdLn0lNOl0e88lbZbXK6goYok7Sqc+TjOHKnjng4HSuTorJZRg007PS1vel0ba+13bFzv 9P6+46PXdd0TVYdPW20i/t2sokt8y6ikgeJSxIwIVwx3fezgelXNW8Z2E95YXuiaRcafc6dPFJaL LfCaG3jjJPloixpwzEMzMWYkdckk8hRVrK8LaKs7Rva8pPffd638w5mdZr/jGLXoI4bhvEUkIuFl kgu9dNxFtGchFaLKtg4DEtjuDVPXdfsb/UodR0Wzv9MvYvLAlbUFkx5aKqldsSFW+UHOTz6Vz9FV Ry3C0eX2cWrXW8ra73V7O9utwc5Pc6PVvHWv6tb2EU2r6li0jTO+9kbzJVdmWXrwwyADyRtHNU7v xPrOrLFBr+sapqVksqyPbzXrtnHpu3ANgkA4OM9D0qne6dLYRWckzIwvLcXEe0nhSzLg8dcqf0qp To4PBxgvZQSSvay272e6Dml36fgbWqeInurIaZpNv/Zekjk2kcrMZ2/vzNx5jcDsFH8Krk5s3+vp BfeHb7SpFkn02yhVg6HaJFkdtpBxkYI6cc1zlW73TpbCKzkmZGF5bi4j2k8KWZcHjrlT+lH1PDRc YW76d7rW99W/Nu4ru79P1Rrf214ftbqG50zw24kS5jnZb6+M8YVWyY1UInynod+/gfUnX1X4i/br OzWODVJbuyv0voLnU9V+1bXX+Hb5agLwOFx368AcPRWc8pwlScZzi247Nyk/zf4MfPJbHRDWfDkF 3FPZeHrqMrcJM/manvKKpzsjxEAoJxy4c4AxzkmyfGFrb+fNpum3MF42rJqcEsl4rrGyEkKVEalh 8zc5Hb0OefvdOlsIrOSZkYXluLiPaTwpZlweOuVP6VUoWX4SquZ3kvOUn+bDmf8AXp/kzrde8cTa rDH9lu/EUM0dws8f2vXWuYomGcFFMasCM8NuJAz1zmqOu+NNa1/T7SzvtSv5YIYRHLHNePIszhmb zCDxnDAc5+71rAq3e6dLYRWckzIwvLcXEe0nhSzLg8dcqf0op5fgaDgowV1flvq/PV3Y+eTe/T8C pRRRXpkBRRRQAUUUUASW9xNaXEdxayyQzRMHjljYqyMOQQRyD71v6t461/Vrewim1fUsWkaZ33sj eZKrsyy9eGGQAeSNo5rno4zLKkalQzsFBZgo59SeAPc1ra1o1lp1vHJp+sW+o7X8m4VAEMcoGTsB JMkZ5AkAHIOQMru4a9PCzrw9rFOettL2+drLyvv0HG6vYS78WeI79Ylvtf1S5EMqzRCa9kfZIv3X GTww7Ecii78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7EcisqNPMkVNyruIG5jgD3NdF4p8EX/hK 3s5dRnti11GrrEk6O3IJOArNlR8vzHGdwxnBxnKGX0asKMoxUpX5VZX87afeNOcr2KV34s8R36xL fa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZFFdCweG VrU46baLQXNLua934n1nVlig1/WNU1KyWVZHt5r12zj03bgGwSAcHGeh6VPeeKrkRxWnh9ZNFsIX EiQ207b5JAQRLLJwXcYGDgKuPlVcnODRU/UcNp7istl09bbX87XDmZv67401rX9PtLO+1K/lghhE csc148izOGZvMIPGcMBzn7vWsCtHVtJ/suPT287zfttmt1jZt2bmYbepz93rx1rOqsJTw9Oilhkl HyVgbbtcdGUEqGZWaMMNyq20kdwDg4Pvg109/wCJdEurvR5oNG1CL+zFji2vqSP5saMzAcQDDZbr yMDp3rlqKK2EpV5KVS91dbtb6PZoV7X8zotT8Q6de6XqVrBpl1DLeagL1ZHvVdY+GG0qIhu++3OR 2445kv8AxXaSavDrOl6S1rqwvEvZbiW7Mq+YpzhECrtUtkkMXPQAjnPM0Vl/Z+G7Pr9qXW1766rR aPQpzb3/AK/q51mv+MYtegjhuG8RSQi4WWSC7103EW0ZyEVosq2DgMS2O4NQ6j4h0W816z1ODSL+ FoXi82N9RRxIsaqqhSIRtPyjJO7vxXM0VFPK8JTiowi0kmviltLfr/XQJTctzqz4wtbfz5tN025g vG1ZNTglkvFdY2QkhSojUsPmbnI7ehy3xL4w/wCEgsPs/m6+f3wl8q/1s3cC8HhUMYIIzwSxIGeu c1y1FEcrwkasaqj7y2d2/wA2P2kv6/rzN3xBrmm6y8tzbaO9tf3U3nXNxJdmUbsciNAqhVJJJDbz 0wRznCoorsoUIUKap072Xdt/m2yW29wrZ8Q39tfQ6MtrJ5httNjgl+Uja4dyRz14I5HFY1aOraT/ AGXHp7ed5v22zW6xs27NzMNvU5+71461FRU3Wg5P3tbfqCvrbt+qM6iiiukQUUUUAFFFFAElvcTW lxHcWsskM0TB45Y2KsjDkEEcg+9b+reOtf1a3sIptX1LFpGmd97I3mSq7MsvXhhkAHkjaOa5yiua rhaFacalSCbjs2thptbGvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pci GVZohNeyPskX7rjJ4YdiORWRRSWDwytanHTbRaBzS7mvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ 4YdiORRc+LvEl6IheeINVuBDKJovNvZG8tx0cZPDDJwRzWRRQsFhVa1OOm2iDml3Oj1bx1r+rW9h FNq+pYtI0zvvZG8yVXZll68MMgA8kbRzVO78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecisiio p4DCU0lCnFW20XUfNLua934s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34n1nVlig1/WNU1K yWVZHt5r12zj03bgGwSAcHGeh6VkUVaweGjblppW2skrenb5C5pdzevPFVyI4rTw+smi2ELiRIba dt8kgIIllk4LuMDBwFXHyquTmXVvHWv6tb2EU2r6li0jTO+9kbzJVdmWXrwwyADyRtHNc5Wpe6ZD YeH7C4naT7dfM0qRZG1LcHarEYzlmD456KDzuGOeWDwVOcL005Xdr6u9rttvV+bf5jTlrYfd+LPE d+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWVGn mSKm5V3EDcxwB7mui8U+CL/wlb2cuoz2xa6jV1iSdHbkEnAVmyo+X5jjO4Yzg4JQy+jVhRlGKlK/ KrK/nbT7wTnK9ilc+LvEl6IheeINVuBDKJovNvZG8tx0cZPDDJwRzVjXfGmta/p9pZ32pX8sEMIj ljmvHkWZwzN5hB4zhgOc/d61gUVssDhVKM1TinHbRaBzS7mz4hv7a+h0ZbWTzDbabHBL8pG1w7kj nrwRyOKyre4mtLiO4tZZIZomDxyxsVZGHIII5B96u6tpP9lx6e3neb9ts1usbNuzczDb1Ofu9eOt Z1Vho0vYKMNY+YnfT0X5HR6t461/Vrewim1fUsWkaZ33sjeZKrsyy9eGGQAeSNo5qnd+LPEd+sS3 2v6pciGVZohNeyPskX7rjJ4YdiORWRRUU8BhKaShTirbaLqPml3Ne78WeI79Ylvtf1S5EMqzRCa9 kfZIv3XGTww7Ecii78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7EcisiirWDwytanHTbRaC5pdzX u/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIou/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxH IrIooWDwytanHTbRaBzS7mvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6p ciGVZohNeyPskX7rjJ4YdiORWRRQsHhla1OOm2i0Dml3Ne78WeI79Ylvtf1S5EMqzRCa9kfZIv3X GTww7Ecii58XeJL0RC88QarcCGUTRebeyN5bjo4yeGGTgjmsiihYLCq1qcdNtEHNLub+u+NNa1/T 7SzvtSv5YIYRHLHNePIszhmbzCDxnDAc5+71rAooq6GHpYeHs6MVFdkDbe5Jb3E1pcR3FrLJDNEw eOWNirIw5BBHIPvW/q3jrX9Wt7CKbV9SxaRpnfeyN5kquzLL14YZAB5I2jmucoqauFoVpxqVIJuO za2BNrY17vxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKLnxd4kvRELzxBqtwIZRNF5t7I3luO jjJ4YZOCOayKKSwWFVrU46baIOaXc6PVvHWv6tb2EU2r6li0jTO+9kbzJVdmWXrwwyADyRtHNU7v xZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKj1LRxpx0zddKVv7VLkuyECLczLg4ySBtzkD8Ks6 voum2ulRaho+rSX0LXL2zCe18hiyqrbkG5tyYYcnBGRlRkVxUqeXw9nGnTWt+X3dPPW2nzauVeT6 9PwIrnxd4kvRELzxBqtwIZRNF5t7I3luOjjJ4YZOCOasa7401rX9PtLO+1K/lghhEcsc148izOGZ vMIPGcMBzn7vWsCiutYHCqUZqnFOO2i0FzS7hRRRXYSFFFFABRRRQAUUVo6tpP8AZcent53m/bbN brGzbs3Mw29Tn7vXjrUSqRjJQb1e3yDczqnuL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoo08yRU 3Ku4gbmOAPc10XinwRf+Erezl1Ge2LXUausSTo7cgk4Cs2VHy/McZ3DGcHGFTEYeFaFKpJc8r8q6 u29v1Gk3exzdFFFdQgooooA2fEN/bX0OjLayeYbbTY4JflI2uHckc9eCORxWNUtsYBdwm8WRrcSL 5qxEBymfmCkggHGcZFaGqaZBo3iZrS6aSexSVXWSFgGmt2wyupIwCyEEZHGeRXJT5MOlQjd2Ta89 dfzX3j1av2sZVFaGu6X/AGPrVxZrJ5sKkPBMOksTANG4/wB5Sp/Gs+uinUjUgpx2eqBqzsFFFFWI KKKKACiiigAoorUvdMhsPD9hcTtJ9uvmaVIsjaluDtViMZyzB8c9FB53DGc6kYSjF7ydl91/0BK5 l1s+Ib+2vodGW1k8w22mxwS/KRtcO5I568Ecjior3TIbDw/YXE7Sfbr5mlSLI2pbg7VYjGcswfHP RQedwxl1jFU68o1l9m6/R/kPVfMKKKK6hBRRRQAUUUUAFFFFABRRRQAUUUUAFFS2ltJe3kNrAAZZ 5FjQE4yxOB/OtnWdAsrHT5brS9Skvltbv7HdeZa+SFkIYqU+ZtynY/JCngZUZrnniKVOpGnJ6vyf 4vZX6XtfoCTZg0UUV0AS2wgN3CLxpFtzIvmtEoLhM/MVBIBOM4yat67qn9sa1cXix+VCxCQQjpFE oCxoP91Qo/CpL3TIbDw/YXE7Sfbr5mlSLI2pbg7VYjGcswfHPRQedwxl1zU/Z1Z+2j0uvx1+9r8B 6pWCp7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qKNPMkVNyruIG5jgD3NdF4p8EX/hK3s5dRnti 11GrrEk6O3IJOArNlR8vzHGdwxnBwqmIw8K0KVSS55X5V1dt7fqCTd7HN0UUV1CNnxDf219Doy2s nmG202OCX5SNrh3JHPXgjkcVjVo6tpP9lx6e3neb9ts1usbNuzczDb1Ofu9eOtZ1c2FVNUYqk7xG 76ei/IKKKK6RBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRU9jZTajfQ2dr5fnTNsQSSrGpPuzEA fiamUowi5SdkgNnVdT065uNAZka8gs7GKK6hVjEWKyOWTcRxkEcgHrS+KvEVhr7QGwsLuwSDKxW7 3iSQQxnnZGixJt56kkk9SSear3vhTVtPsby7uktVhsbgW0+y+gdllP8ACFVyWPXoD91v7pxjV52H w+Em4VaUuZwuk1K6V9Xona+va9rFNyWj9Pu0CiiivTJCiiigAooooAKKKKACtnxDf219Doy2snmG 202OCX5SNrh3JHPXgjkcVjVo6tpP9lx6e3neb9ts1usbNuzczDb1Ofu9eOtc1RU3Wg5P3tbfqNX1 t2/VGdU9xfXd4MXd1NOPMaXEshb52xubnudoye+B6VFGnmSKm5V3EDcxwB7mui8U+CL/AMJW9nLq M9sWuo1dYknR25BJwFZsqPl+Y4zuGM4OFUxGHhWhSqSXPK/Kurtvb9QSbvY5uiiiuoQUUUUAFal7 qcN/4fsLedZPt1izRJJgbXtydyqTnOVYvjjowHG0Zy6KznTjOUZPeLuvut+oJ2NS91OG/wDD9hbz rJ9usWaJJMDa9uTuVSc5yrF8cdGA42jOXRRRTpxpR5Y7Xb+93Bu4UUUVoAUUUUAFFFFAEtsIDdwi 8aRbcyL5rRKC4TPzFQSATjOMmtDVNTg1nxM13dLJBYvKqLHCoLQ264VUUE4JVAAMnnHJrKorGVGM p8/W1vS+/wCn3BfSxoa7qn9sa1cXix+VCxCQQjpFEoCxoP8AdUKPwrPooq6cI04KEdloht3dwooo qxBRRRQAUUUUAFFFFABRRVu906Wwis5JmRheW4uI9pPClmXB465U/pUucU1FvVgVKKKKoCW1uZLO 7huYDtlhdZEOM4YHI/UVta14gsr6xltdK02axS6u/tlz510JtzgMFCYRNqje/ByeRzxWBRXPPD0q lSNSS1Xm/wAVs7dL3t0Gm0FS2wgN3CLxpFtzIvmtEoLhM/MVBIBOM4yaioreSumiTQ13VP7Y1q4v Fj8qFiEghHSKJQFjQf7qhR+FZ9W73TpbCKzkmZGF5bi4j2k8KWZcHjrlT+lVKzoqmqajT+FaL5aF Ntu4VPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelRRp5kipuVdxA3McAe5rovFPgi/8ACVvZy6jP bFrqNXWJJ0duQScBWbKj5fmOM7hjODjKpiMPCtClUkueV+VdXbe36gk3exzdFFFdQjZ8Q39tfQ6M trJ5httNjgl+Uja4dyRz14I5HFY1aOraT/Zcent53m/bbNbrGzbs3Mw29Tn7vXjrWdXNhVTVGKpO 8Ru+novyCiiiukQUUU6NQ8qIzrGrMAXbOF9zgE4+gNDdlcBtFdH4g8LRaPo9rqNtd3U0NxIUQ3di bbzxtBEsOWJkj/2iFIyvHPHOVhh8RSxNP2lJ3Xo1to9HZjaa3CiiitxBRRRQAUUVbvdOlsIrOSZk YXluLiPaTwpZlweOuVP6VLnFNRb1YFSiiiqAKKKKANzxB4nl163tIngWDy8y3DK2Tc3DAB5m9yFX j1ye9YdFW73TpbCKzkmZGF5bi4j2k8KWZcHjrlT+lc9KnRw0Y0aastbL8WO7bKlFFFdAgoq3e6dL YRWckzIwvLcXEe0nhSzLg8dcqf0qpUxnGa5ovQAoooqgCiird7p0thFZyTMjC8txcR7SeFLMuDx1 yp/Spc4pqLerAqVs+Ib+2vodGW1k8w22mxwS/KRtcO5I568EcjisatHVtJ/suPT287zfttmt1jZt 2bmYbepz93rx1rCoqbrQcn72tv1Gr627fqjOqe4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KijTz JFTcq7iBuY4A9zXReKfBF/4St7OXUZ7YtdRq6xJOjtyCTgKzZUfL8xxncMZwcKpiMPCtClUkueV+ VdXbe36gk3exzdFFFdQgooooAKKKKACnwzS21xHPbyPFNEweOSNirIwOQQR0IPemUUmk1Zga934s 8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZF FcyweGVrU46baLQfNLua934s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyI ZVmiE17I+yRfuuMnhh2I5FZFFCweGVrU46baLQOaXc17vxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZP DDsRyKj1HxNr2sWwttW1vUb6AMHEVzdySKGGQDhiRnk8+9ZlFOOEw0GnGnFW20WnoHNLuFFFFdIg ooooAKKKKACiiigAooooAKKKKAJLe4mtLiO4tZZIZomDxyxsVZGHIII5B9639W8da/q1vYRTavqW LSNM772RvMlV2ZZevDDIAPJG0c1zlakWildQ0mG9n8qHUlSRZIU8xo0Zyn3SVycqeM/jXFiaWFcl VrxTcb2bV3tqCbV7dh934s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZV miE17I+yRfuuMnhh2I5FX9e8K2unQSS6TqFxeiDUG0+YXFmLc+aAcFCHcMvBzyCPlyPmqhe+FtWs Wtg8EVx9qm8iJrK5iug0vH7vMTMA3I+U8muWjLLJxi4qK3tdKL87JpP10NHzq9wu/FniO/WJb7X9 UuRDKs0QmvZH2SL91xk8MOxHIou/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIq7f+DLvTPDja leTRCUX6WYSGeGaLLIzcypIQrDZyrAYDKc81Vv8Awxd2WrWGmqY3uL2FJEJuIPLYsSBtlWRkK5HU kfQUqVTK529nyaXtounxW8tdXsJ86vcZd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRc+LvE l6IheeINVuBDKJovNvZG8tx0cZPDDJwRzUU+galb2f2mSFDGLk2hWOZHdZRn5SiksM7TgkYOOM1P qnhPV9G0831/Dbi3WcWzvDeQzbJcE7GCOSrYU8EDpWqjlqlGK5L6pL3d+qX62D3/ADJtd8aa1r+n 2lnfalfywQwiOWOa8eRZnDM3mEHjOGA5z93rWBVu906Wwis5JmRheW4uI9pPClmXB465U/pVSurC 0qFGko4dJR8iW27XCp7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qKNPMkVNyruIG5jgD3NdF4p8 EX/hK3s5dRnti11GrrEk6O3IJOArNlR8vzHGdwxnBwqmIw8K0KVSS55X5V1dt7fqCTd7HN0UUV1C NnxDf219Doy2snmG202OCX5SNrh3JHPXgjkcVjVbvdOlsIrOSZkYXluLiPaTwpZlweOuVP6VUrDD whCko03dA+novyCiiitwCnxOscyO8ayqrAmNydrj0OCDg+xB96ZRSaurAb2qa5p02inS9E0u4sbe S6F1L9pvftB3BSqqmEQKuGbOQxPy5PFYNFFZUaEKEeWHrq2397bY22wooorYQUUU+GNZbiON5UhV 2CtLICVQE/eO0E4HXgE+xpN2VwFt7ia0uI7i1lkhmiYPHLGxVkYcggjkH3rf1bx1r+rW9hFNq+pY tI0zvvZG8yVXZll68MMgA8kbRzWdrGgX+hyR/bER4J9xt7uBxJDcAHBKOOGxkZHUZwQDxTovD95N f6VZxNEZdVRHg+YgKGdkG4kccqSevFefUWBrcuInyytez0enUa5otpf0h934s8R36xLfa/qlyIZV miE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FS32l+H0s3fSfEE11d LMIhBcWHkCQH+NX3sAv+9tPI464ra5okuhXFtBcMGea3WfcskUiHJI+V43dWXjrkH2FRSWAnKMYw Setk48r87JpO2u5T5+5Jd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciG VZohNeyPskX7rjJ4YdiORWXEI2mQTsyRFhvZF3Mq55IBIyfbI+tegXXw102x1q202+1jVbWW8nMN o8+joFuSHVcpicnHzAgsACM4JPFZYqpluClGNWCTabVoN6Le1k/V+WoLnkm0cnc+LvEl6IheeINV uBDKJovNvZG8tx0cZPDDJwRzVjXfGmta/p9pZ32pX8sEMIjljmvHkWZwzN5hB4zhgOc/d61Y1Hwn bad4en1KS8u0fMD2kM1oii4hm3lHLLK204jkJXBxgc88Yd7p0thFZyTMjC8txcR7SeFLMuDx1yp/ SroQy6tKM6UY3i3b3ba2u7aLo9/1Buae/T8LlSpLe4mtLiO4tZZIZomDxyxsVZGHIII5B96SGNZb iON5UhV2CtLICVQE/eO0E4HXgE+xq/rGgX+hyR/bER4J9xt7uBxJDcAHBKOOGxkZHUZwQDxXoTqU uZUptXl0fXv6+ZFjR1bx1r+rW9hFNq+pYtI0zvvZG8yVXZll68MMgA8kbRzVO78WeI79Ylvtf1S5 EMqzRCa9kfZIv3XGTww7Ecip18Owpq2h2lzeukerQxSmSOAMYd7soG0sN2COuR1q9qXg+x0iwvZ7 7VLnfa30NuBDZK6SxShmWVWMo/gRjtx97CkjkjyIzyqi4U4wXlaLe7t277/K/Qv32t+35afgZV34 s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5Fa es+E9N0fWLGGTW5Dp07GO4uns8PbSqFLxmJXbJUOnRupPpmotf8AD+iaTpsM1nrl1cXU8MVxFbz6 cIg0b553LK4BGOQfXgmqpVstm6apw+L4f3b72evLp53tbqO09dfxKNz4u8SXoiF54g1W4EMomi82 9kby3HRxk8MMnBHNWNd8aa1r+n2lnfalfywQwiOWOa8eRZnDM3mEHjOGA5z93rWBVu906Wwis5Jm RheW4uI9pPClmXB465U/pXb9TwcakH7OKavy6L52J5pa69PwKlbPiG/tr6HRltZPMNtpscEvykbX DuSOevBHI4rGq3e6dLYRWckzIwvLcXEe0nhSzLg8dcqf0repCDqwlJ6q9v1JXW3b9UVKnuL67vBi 7uppx5jS4lkLfO2Nzc9ztGT3wPSoo08yRU3Ku4gbmOAPc10XinwRf+Erezl1Ge2LXUausSTo7cgk 4Cs2VHy/McZ3DGcHEVMRh4VoUqklzyvyrq7b2/UaTd7HN0UUV1CCiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAJLe4mtLiO4tZZIZomDxyxsVZGHIII5B966W68 e6tqUulLq17qV3aWQj8+3e/ci5ZZC+87gQGwQMkHpXLVbvdOlsIrOSZkYXluLiPaTwpZlweOuVP6 Vx4jC4WvOLrRTlql387ME3ql2Op1X4gjWdQ+0anp81+tvfLeWK3155xgBIMkLHYPMibaMLhdvvyD Pf8AxIF1b2YW21S4uLO+W9im1PVvtXI4Me0RqAhHZdpGTyeMcJRXH/YmAXLan8O2stL6Pr169223 qy/aTbbvudNNr3h7+wJdKs9C1CKOa8iunkk1RHb5Ay7R+4AwVd8HGQSCcgbSmr+I9Kvf7Lk03Sby 1uNNSOKNri/SZGRGZsFRCh3Et1zjA6VzVFbxy3DRlzWd9d5Se6s93rp3E5N38zrtQ8VaDd2ksEXh y5RZ9RW/m8zU9/mEFt0fES4UqxAxhgTkluAE17xzLqlnbw2TasktvdC5iudQ1Q3csBAICxPsQxjn J65Kp0288lRUxyrCRlGXK243teUnvvu2P2kv6/rzN/XfGmta/p9pZ32pX8sEMIjljmvHkWZwzN5h B4zhgOc/d61gVbvdOlsIrOSZkYXluLiPaTwpZlweOuVP6VUrqwtKhRpKOHSUfIltu1wqe4vru8GL u6mnHmNLiWQt87Y3Nz3O0ZPfA9KijTzJFTcq7iBuY4A9zXReKfBF/wCErezl1Ge2LXUausSTo7cg k4Cs2VHy/McZ3DGcHCqYjDwrQpVJLnlflXV23t+oJN3sc3UlvcTWlxHcWsskM0TB45Y2KsjDkEEc g+9R0V0tKSsxHR6t461/Vrewim1fUsWkaZ33sjeZKrsyy9eGGQAeSNo5qnd+LPEd+sS32v6pciGV ZohNeyPskX7rjJ4YdiORWRRXHTwGEppKFOKttoupXNLua934s8R36xLfa/qlyIZVmiE17I+yRfuu Mnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZFFWsHhla1OOm2i0FzS7mvd+LPEd+ sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWRRQsH hla1OOm2i0Dml3Ne78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecii78WeI79Ylvtf1S5EMqzRC a9kfZIv3XGTww7EcisiihYPDK1qcdNtFoHNLua934s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5 FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZFFCweGVrU46baLQOaXc17vxZ4jv1iW+1/VL kQyrNEJr2R9ki/dcZPDDsRyKLvxPrOrLFBr+sapqVksqyPbzXrtnHpu3ANgkA4OM9D0rIooWDw0b ctNK21klb07fIOaXc3rzxVciOK08PrJothC4kSG2nbfJICCJZZOC7jAwcBVx8qrk5uXPxE1+6m0p 5tRvZ108Rlorm7eWO4dHZg7KT1wQPXA61ytW73TpbCKzkmZGF5bi4j2k8KWZcHjrlT+lc8svwV4x lBN62vq9d9Xq35vUfNLWx0Nz4vsz4dbQ9PtdXh02a4SSW2n1cSxqisWKxL5ShCSc7iG6Dg1T8Ra3 pGr2dlHYaXe2k1nAtujzX6TK0aljyohQ7st1zjjpXP0VVLLcNSmpwTTTb+KW73b11v53Dnkx8RjW ZDOjPEGG9UbazLnkAkHB98H6V0ep+LIbrxZaa1Y2l3CkF59sNrc3omQSeYHOzEa7AcDsTx1rmaK3 q4WlWmpzV2k1u9nvpe3z3Fd2sddrPxAu9V037LDbmyki1L7ZazwzYa3jVSI4lwB9zcSGGOp4qpq3 jrX9Wt7CKbV9SxaRpnfeyN5kquzLL14YZAB5I2jmucq3e6dLYRWckzIwvLcXEe0nhSzLg8dcqf0r lhluAouMVTV1e3Xffcrnk23f+rly78T6zqyxQa/rGqalZLKsj28167Zx6btwDYJAODjPQ9KfqniJ 7qyGmaTb/wBl6SOTaRysxnb+/M3HmNwOwUfwquTnForpWDw8XFxgly7JbX722v52uTzM6a51ywTV PDd4qvdpptnCs0Ub+UfMSR227ip9Rzg1dXxzZNClpd6NNc2MWppfRI96PNCKJD5DP5eCm+Vm+6D8 zDvkcve6dLYRWckzIwvLcXEe0nhSzLg8dcqf0qpXH/ZuDrQXMnJLS92ur7Na6vXcfM7fd+R2GreO LfXNJvbPU9Mkkaa9F3DNC9tAyHBB3+Xbr5jNk5Y4/h4GDnL8Sa1p2siw/s7TrqyNpbrbHz7xZ96L 908Rpg8nPXPHA74dFbUMtwuHkpUY8tr2Sbtra+l7dO2+u43Uk9yS3uJrS4juLWWSGaJg8csbFWRh yCCOQfet/VvHWv6tb2EU2r6li0jTO+9kbzJVdmWXrwwyADyRtHNc5Vu906Wwis5JmRheW4uI9pPC lmXB465U/pWtbD4apVjKrFOSva6+8lNq9i5c+LvEl6IheeINVuBDKJovNvZG8tx0cZPDDJwRzVjX fGmta/p9pZ32pX8sEMIjljmvHkWZwzN5hB4zhgOc/d61gUUlgcKpRmqcU47aLQfNLuFT3F9d3gxd 3U048xpcSyFvnbG5ue52jJ74HpUUaeZIqblXcQNzHAHua6LxT4Iv/CVvZy6jPbFrqNXWJJ0duQSc BWbKj5fmOM7hjODiqmIw8K0KVSS55X5V1dt7fqJJu9jm6KKK6hBRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAElvcTWlxHcWsskM0TB45Y2KsjDkEEcg+9b+reO tf1a3sIptX1LFpGmd97I3mSq7MsvXhhkAHkjaOa5yiuarhaFacalSCbjs2thptbGvd+LPEd+sS32 v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWRRSWDwyta nHTbRaBzS7mvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyP skX7rjJ4YdiORWRRQsHhla1OOm2i0Dml3Ne78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecii58 XeJL0RC88QarcCGUTRebeyN5bjo4yeGGTgjmsiihYLCq1qcdNtEHNLub+u+NNa1/T7SzvtSv5YIY RHLHNePIszhmbzCDxnDAc5+71rAooq6GHpYeHs6MVFdkDbe4VPcX13eDF3dTTjzGlxLIW+dsbm57 naMnvgelRRp5kipuVdxA3McAe5rpPE3ga/8AC0di2o3NoGvERlQToxGc5PyM3yj5fmOM7uM4OIq4 jD060KdSSU5X5V1dt7fqCTaduhzNFdN4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHB4 m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHGNPM8FV5OSonz35fO29vTqNwkr3WxzNFdN 4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHB4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5 R8vzHGd3GcHBTzPBVeTkqJ89+Xztvb06g4SV7rY5mium8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8 o+X5jjO7jODg8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODgp5ngqvJyVE+e/L523t6d QcJK91sczRXTeJvA1/4WjsW1G5tA14iMqCdGIznJ+Rm+UfL8xxndxnBweJvA1/4WjsW1G5tA14iM qCdGIznJ+Rm+UfL8xxndxnBwU8zwVXk5KifPfl87b29OoOEle62OZorpvE3ga/8AC0di2o3NoGvE RlQToxGc5PyM3yj5fmOM7uM4ODxN4Gv/AAtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODgp5ngq vJyVE+e/L523t6dQcJK91sczRXTeJvA1/wCFo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcHibw Nf8AhaOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHBTzPBVeTkqJ89+Xztvb06g4SV7rY5mium8T eBr/AMLR2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg4PE3ga/wDC0di2o3NoGvERlQToxGc5PyM3 yj5fmOM7uM4OCnmeCq8nJUT578vnbe3p1Bwkr3WxztvcTWlxHcWsskM0TB45Y2KsjDkEEcg+9b+r eOtf1a3sIptX1LFpGmd97I3mSq7MsvXhhkAHkjaOaf4m8DX/AIWjsW1G5tA14iMqCdGIznJ+Rm+U fL8xxndxnBweJvA1/wCFo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcc31nK8XOlUbjJyvyPe9t 7enXsPlnG/pr6FC78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecii78WeI79Ylvtf1S5EMqzRCa 9kfZIv3XGTww7Ecir/ibwNf+Fo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcHibwNf+Fo7FtRub QNeIjKgnRiM5yfkZvlHy/McZ3cZwcTSr5TU9n7PkfNflslrb4radOo3zq9yhd+LPEd+sS32v6pci GVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORV/xN4Gv/C0di2o3 NoGvERlQToxGc5PyM3yj5fmOM7uM4ODxN4Gv/C0di2o3NoGvERlQToxGc5PyM3yj5fmOM7uM4OCl Xymp7P2fI+a/LZLW3xW06dQfOr3KFz4u8SXoiF54g1W4EMomi829kby3HRxk8MMnBHNWNd8aa1r+ n2lnfalfywQwiOWOa8eRZnDM3mEHjOGA5z93rU/ibwNf+Fo7FtRubQNeIjKgnRiM5yfkZvlHy/Mc Z3cZwcHibwNf+Fo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcKlVyipKlOlyXd3CyWtt7enUH7R Xv2/A5mpLe4mtLiO4tZZIZomDxyxsVZGHIII5B966LxN4Gv/AAtHYtqNzaBrxEZUE6MRnOT8jN8o +X5jjO7jODg8TeBr/wALR2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg464Zlgqygo1E/aX5f71t7 d7dSXCSvdbDNW8da/q1vYRTavqWLSNM772RvMlV2ZZevDDIAPJG0c1Tu/FniO/WJb7X9UuRDKs0Q mvZH2SL91xk8MOxHIq/4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHB4m8DX/haOxbUb m0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHHHh6mUNU1R5Pevy2S1t8VvTqU/aK9+i/AoXfizxHfrEt9r +qXIhlWaITXsj7JF+64yeGHYjkUXfizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkVf8TeBr/wAL R2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg4PE3ga/8AC0di2o3NoGvERlQToxGc5PyM3yj5fmOM 7uM4OKpV8pqez9nyPmvy2S1t8VtOnUHzq9yhc+LvEl6IheeINVuBDKJovNvZG8tx0cZPDDJwRzVj XfGmta/p9pZ32pX8sEMIjljmvHkWZwzN5hB4zhgOc/d61P4m8DX/AIWjsW1G5tA14iMqCdGIznJ+ Rm+UfL8xxndxnBweJvA1/wCFo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcKlVyipKlOlyXd3Cy Wtt7enUH7RXv2/A5mium8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODg8TeBr/wtHYtq NzaBrxEZUE6MRnOT8jN8o+X5jjO7jODjsp5ngqvJyVE+e/L523t6dSXCSvdbHM1PcX13eDF3dTTj zGlxLIW+dsbm57naMnvgelb/AIm8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHDfFPgi/8 JW9nLqM9sWuo1dYknR25BJwFZsqPl+Y4zuGM4OFTzHA13TcKibnfl87b29OockldWObooor0SQoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACp7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qCik4ptNrYCe4vru8GLu6mnHmNLi WQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qCipVOCtZbAT3F9d3gxd3U04 8xpcSyFvnbG5ue52jJ74HpRcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelQUUKnBWstgJ7i+u7wYu 7qaceY0uJZC3ztjc3Pc7Rk98D0ouL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKFTgrWWwE9xfX d4MXd1NOPMaXEshb52xubnudoye+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUFFCpwVrLYC e4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qCihU4K 1lsBPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelFxfXd4MXd1NOPMaXEshb52xubnudoye+B6VBR QqcFay2AnuL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSi4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA 9KgooVOCtZbAT3F9d3gxd3U048xpcSyFvnbG5ue52jJ74HpRcX13eDF3dTTjzGlxLIW+dsbm57na MnvgelQUUKnBWstgJ7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0ouL67vBi7uppx5jS4lkLfO2Nz c9ztGT3wPSoKKFTgrWWwE9xfXd4MXd1NOPMaXEshb52xubnudoye+B6UXF9d3gxd3U048xpcSyFv nbG5ue52jJ74HpUFFCpwVrLYCe4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0u JZC3ztjc3Pc7Rk98D0qCihU4K1lsBPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelFxfXd4MXd1NO PMaXEshb52xubnudoye+B6VBRQqcFay2AnuL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSi4vru8GL u6mnHmNLiWQt87Y3Nz3O0ZPfA9KgooVOCtZbAT3F9d3gxd3U048xpcSyFvnbG5ue52jJ74HpRcX1 3eDF3dTTjzGlxLIW+dsbm57naMnvgelQUUKnBWstgJ7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0 ouL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKFTgrWWwE9xfXd4MXd1NOPMaXEshb52xubnudoy e+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUFFCpwVrLYCe4vru8GLu6mnHmNLiWQt87Y3Nz 3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qCihU4K1lsAUUUVYBRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQB//Z --_004_76B41B8FACE1514795D30EC137FF391D3D08E0LILASjungleqosmos_-- From haibin.song@huawei.com Mon Jan 27 01:36:56 2014 Return-Path: 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 21F831A0163 for ; Mon, 27 Jan 2014 01:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.436 X-Spam-Level: X-Spam-Status: No, score=-4.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 lIR8Wn7qSsUG for ; Mon, 27 Jan 2014 01:36:53 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBEC1A0117 for ; Mon, 27 Jan 2014 01:36:52 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAM00627; Mon, 27 Jan 2014 09:36:50 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 27 Jan 2014 09:36:22 +0000 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 27 Jan 2014 09:36:49 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Mon, 27 Jan 2014 17:36:46 +0800 From: "Songhaibin (A)" To: Melinda Shore , "sfc@ietf.org" Thread-Topic: =?utf-8?B?W3NmY10g562U5aSNOiBTZXJ2aWNlcyBlbGlnaWJsZSBmb3IgY2hhaW5pbmc=?= Thread-Index: Ac8aTJ6FwniRxzcWRuaQFnPfr+bu1gAr0QHAAADQNHAAAxej4QANIGbQ Date: Mon, 27 Jan 2014 09:36:45 +0000 Message-ID: References: <9C2DE4B8FE85984BA1B0581235F6B2ED0F633EAB@SZXEMA502-MBS.china.huawei.com> <9C2DE4B8FE85984BA1B0581235F6B2ED0F633F22@SZXEMA502-MBS.china.huawei.com> <52E5CAF7.80603@gmail.com> In-Reply-To: <52E5CAF7.80603@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.70] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [sfc] =?utf-8?b?562U5aSNOiBTZXJ2aWNlcyBlbGlnaWJsZSBmb3IgY2hhaW5p?= =?utf-8?q?ng?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 09:36:56 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1lbGluZGEgU2hvcmUNCj4gU2VudDogTW9uZGF5 LCBKYW51YXJ5IDI3LCAyMDE0IDEwOjU3IEFNDQo+IFRvOiBzZmNAaWV0Zi5vcmcNCj4gU3ViamVj dDogUmU6IFtzZmNdIOetlOWkjTogU2VydmljZXMgZWxpZ2libGUgZm9yIGNoYWluaW5nDQo+IA0K PiBPbiAxLzI2LzE0IDU6MzEgUE0sIFpodWFuZ3l1eGluIHdyb3RlOg0KPiA+ICAgICAgICAgIFdo ZW4gdHJhZmZpYyBmcm9tIEludGVybmV0IGFycml2ZXMgYXQgdGhlIHJvdXRlciwgaXRzIGRlc3RJ UA0KPiA+IHBvaW50cyBhdCBOQVQuIEhvdyBkb2VzIHRoZSByb3V0ZXIgZGVjaWRlIHRoZSBuZXh0 IGhvcD8NCj4gPg0KPiA+IC0gICAgICAgIEFzIHRoZSBwYWNrZXQgaXMgZGlyZWN0bHkgYWRkcmVz c2VkIHRvIHRoZSBOQVQsIGRvZXMgaXQNCj4gPiBjb25mbGljdCB3aXRoIHRoZSDigJh0cmFuc3Bh cmVudCBtaWRib3jigJkgY29uY2VwdCBpbg0KPiA+IGRyYWZ0LXBhcmtlci1zZmMtY2hhaW4tdG8t cGF0aC0wMD8NCg0KSSB0aGluayB0aGUgTkFUIHNlcnZpY2UgZnVuY3Rpb24gaXMgdHJhbnNwYXJl bnQgdG8gdGhlIGVuZCB1c2VycywgYnV0IG5vdCB0byBTRkMuDQoNCj4gPg0KPiA+IC0gICAgICAg IElzIGl0IHBvc3NpYmxlIGZvciB0aGUgUm91dGVyIHRvIHNlbmQgb3V0IEFSUCB0byBxdWVyeSBm b3IgdGhlDQo+ID4gSVAgYWRkcmVzcyBvbiBOQVQ/IEhvdyBkb2VzIE5BVCByZWFjdCB0byBBUlAg cmVxdWVzdCBlc3BlY2lhbGx5IHdoZW4NCj4gPiBOQVQgaXMgU0ZDLWF3YXJlPw0KPiANCj4gV2hl biBJIGZpcnN0IHJlYWQgdGhpcyBJIHRob3VnaHQgIldlbGwsIHllcywgYW5kIE5BVCBpcyBwYXJ0 aWN1bGFybHkgc2Vuc2l0aXZlIHRvDQo+IG5ldHdvcmsgdG9wb2xvZ3kgKGRldmljZSBvcmRlcmlu ZykuIiAgQnV0LCBJIHRoaW5rIHRoaXMgbmVlZG4ndCBhY3R1YWxseSBjcmVhdGUNCj4gYSBwYXJ0 aWN1bGFybHkgZGlmZmljdWx0IHByb2JsZW0gaGVyZSwgc2luY2UgdGhlIG9yaWdpbmFsIHBhY2tl dCBpcyBnb2luZyB0byBiZQ0KPiBlbmNhcHN1bGF0ZWQgYnkgdGhlIFNGQyB0cmFuc3BvcnQuIiAg SG93ZXZlciwgdGhlcmUgY2FuIGJlIHRoZSB1c3VhbA0KPiBwcm9ibGVtcyB3aXRoIHNlcnZpY2Ug b3JkZXJpbmcgdGhhdCB5b3UgZmluZCB3aXRoaW4gYSBzaW5nbGUgYm94IC0gZm9yIGV4YW1wbGUs DQo+IHlvdSBuZWVkIHRvIGJlIGF0dGVudGl2ZSB0byB3aGljaCBhZGRyZXNzZXMgeW91J3JlIHB1 dHRpbmcgaW50byB5b3VyIGZpcmV3YWxsaW5nDQo+IHJ1bGVzLCBldGMuICBCdXQgdGhhdCdzIGdv aW5nIHRvIGJlIHRydWUsIHJlZ2FyZGxlc3Mgd2hldGhlciB0aGUgc2VydmljZXMgYXJlDQo+IGRl Y29tcG9zZWQgaW50byBkaWZmZXJlbnQgYm94ZXMgb3IgY28tcmVzaWRlbnQgd2l0aGluIHRoZSBz YW1lIGJveC4NCj4gU2ltaWxhcmx5LCB0aGUgTkFULWZyb20tdGhlLW91dHNpZGUgcHJvYmxlbSBl eGlzdHMgd2hldGhlciBvciBub3QgeW91J3JlIHVzaW5nDQo+IFNGQy4NCg0KSSBkbyBub3QgdGhp bmsgd2Ugc2hvdWxkIG1ha2UgdGhlIHNlcnZpY2UgZnVuY3Rpb25zIGF3YXJlIG9mIHRoZSBzZXJ2 aWNlIGZ1bmN0aW9uIGNoYWluaW5nLiAgU0ZzIHNob3VsZCBvbmx5IHJlY2VpdmUgdGhlIG9yaWdp bmFsIHBhY2tldCBhcyB0aGV5IGNvbnZlbnRpb25hbGx5IGRvLCB3aXRob3V0IGFueSBTRkMgaGVh ZGVycy4gVGhlIFNGQyBmb3J3YXJkaW5nIGVuZ2luZSBzaG91bGQgYmUgcmVzcG9uc2libGUgZm9y IGFkZGluZy9yZW1vdmluZyB0aGUgaGVhZGVyLg0KDQo+IA0KPiBJZiB0aGVyZSdzIGludGVyZXN0 IEkgY2FuIGNvbnRyaWJ1dGUgYSBkcmFmdCBvbiBtaWRkbGVib3ggY29uc2lkZXJhdGlvbnMuDQoN CldoYXQgYWJvdXQgYWxzbyBkb2N1bWVudGluZyB0aGUgZGVwbG95bWVudCBjb25zaWRlcmF0aW9u cyBpbiBpdD8NCg0KQlIsDQotSGFpYmluDQoNCj4gDQo+IE1lbGluZGENCj4gDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNmYyBtYWlsaW5nIGxp c3QNCj4gc2ZjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjDQo= From melinda.shore@gmail.com Mon Jan 27 02:14:34 2014 Return-Path: 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 746B41A01C8 for ; Mon, 27 Jan 2014 02:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no 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 Nl6Hd64E2Tod for ; Mon, 27 Jan 2014 02:14:33 -0800 (PST) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 855C01A011C for ; Mon, 27 Jan 2014 02:14:33 -0800 (PST) Received: by mail-pb0-f52.google.com with SMTP id jt11so5685197pbb.25 for ; Mon, 27 Jan 2014 02:14:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=9uzbzFv8c2vocw7OaHLXSZ+YY21eiJ0WfkVc19Gmd9s=; b=l6UtJAqW1HUM3eyPLu+lq1lwsuYq5eyoamPpY8HcSQDBg8o4sif7jfAsdPv4VdwoJC cgOF6MfqL8HSYdvs+kdo/DjXZDWLyGf5sxU6+nZcESnI25gvc6NA1XHoYrz2X9yATi7p ReWUA9Le5O80ioF3dn17lwk2BMskJIjSMxOEEDHVtUpEk3ZDUAJvs6jLeKGwmRwc6JgM f3tGkwI+dKjXri+b14Q+iroQVV2asmzrvBa/sTnLerjfg7qJHVEL34hXKf4uiYJDnvah K4ourI8J2JdpSA15rzj+GSG6kEVj6LpEt5VtN839obY+2O50jG1cBgPNcIu8n6yW8oqC Ajyg== X-Received: by 10.67.30.70 with SMTP id kc6mr29657211pad.32.1390817671498; Mon, 27 Jan 2014 02:14:31 -0800 (PST) Received: from spandex.local (216-67-22-153-rb3.fai.dsl.dynamic.acsalaska.net. [216.67.22.153]) by mx.google.com with ESMTPSA id jp3sm30433760pbc.36.2014.01.27.02.14.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Jan 2014 02:14:30 -0800 (PST) Message-ID: <52E63181.1000006@gmail.com> Date: Mon, 27 Jan 2014 01:14:25 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Songhaibin (A)" References: <9C2DE4B8FE85984BA1B0581235F6B2ED0F633EAB@SZXEMA502-MBS.china.huawei.com> <9C2DE4B8FE85984BA1B0581235F6B2ED0F633F22@SZXEMA502-MBS.china.huawei.com> <52E5CAF7.80603@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "sfc@ietf.org" Subject: Re: [sfc] =?utf-8?b?562U5aSNOiBTZXJ2aWNlcyBlbGlnaWJsZSBmb3IgY2hhaW5p?= =?utf-8?q?ng?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 10:14:34 -0000 On 1/27/14 12:36 AM, Songhaibin (A) wrote: > I do not think we should make the service functions aware of the > service function chaining. SFs should only receive the original > packet as they conventionally do, without any SFC headers. The SFC > forwarding engine should be responsible for adding/removing the > header. Yes, but NAT is a special case, since it's a service that actually modifies the IP packet contents and consequently there's a sensitivity in the *service* topology. This is a deployment consideration but it's also a middlebox consideration. If I am applying filtering rules based on source or destination addresses I need to know what those are at which point in the network. If a packet traverses a firewall then a NAT the firewall rules need to be constructed with different addresses than if the order is reversed. I thought the original question was a bit confused, since the same questions about packets arriving at a NAT are the same whether the service is decomposed or not decomposed. Melinda From mohamed.boucadair@orange.com Mon Jan 27 05:28:23 2014 Return-Path: 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 0D3AD1A020E for ; Mon, 27 Jan 2014 05:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 gegzn-e8KN2a for ; Mon, 27 Jan 2014 05:28:20 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id D00F21A020A for ; Mon, 27 Jan 2014 05:28:19 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id E628826419C; Mon, 27 Jan 2014 14:28:16 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id C798535C070; Mon, 27 Jan 2014 14:28:16 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Mon, 27 Jan 2014 14:28:16 +0100 From: To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Date: Mon, 27 Jan 2014 14:28:13 +0100 Thread-Topic: [sfc] Progression of use case documents within the SFC working group Thread-Index: AQHPGS5B+ZYQfqbdGEGHvCjMISf9v5qYJNjAgABvjcA= Message-ID: <94C682931C08B048B7A8645303FDC9F36F47360A1B@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36F473607AF@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F473607AF@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36F47360A1BPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.26.232114 Subject: Re: [sfc] Progression of use case documents within the SFC working group X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 13:28:23 -0000 --_000_94C682931C08B048B7A8645303FDC9F36F47360A1BPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, I meant to adopt "draft-liu-sfc-use-cases" as the use-case document. draft-= liu-service-chaining-use-cases was replaced by draft-liu-sfc-use-cases. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de mohamed.boucadair@oran= ge.com Envoy=E9 : lundi 27 janvier 2014 07:51 =C0 : Jim Guichard (jguichar); sfc@ietf.org Objet : Re: [sfc] Progression of use case documents within the SFC working = group Hi Jim, all, I support the adoption of draft-liu-service-chaining-use-cases as a place t= o record some the use cases already discussed in this list. As I'm the author of the "3GPP Gi Interface Service Function Chaining" sect= ion of the PS document, I'm fine to remove that text from the PS and merge = it with the text of draft-liu-service-chaining-use-cases. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard (jguichar= ) Envoy=E9 : vendredi 24 janvier 2014 19:01 =C0 : sfc@ietf.org Objet : [sfc] Progression of use case documents within the SFC working grou= p Greetings, The documentation and applicability of use cases for the SFC WG was discuss= ed during both the Berlin and Vancouver BOFs. The main purpose of those dis= cussions was to show support for our work and subsequent formation of a wor= king group. As we move forward with our work we would like to solicit opinions of how b= est to approach use cases within the WG. The SFC charter left it open as to= whether we should have a single problem statement that includes use cases = or whether to separate out the use cases. Some background: 1) An important purpose for having use cases is to connect a problem or sol= ution to a real concrete scenario. On the problem side, a use case can high= light requirements for any solution. Hence, having SFC use cases is importa= nt. Lack of use cases could lead to missed requirements. 2) Having just one use case is probably not enough, but having too many qui= ckly leads to diminishing returns. The sweet spot is a relatively small num= ber (3? 4?) that are different enough that they flesh out the (different) k= ey requirements. We know that more use cases aren't helping when they simpl= y reaffirm requirements that have already been made apparent by other use c= ases. 3) Some use cases may be detailed and complicated , i.e., because the scena= rio or technology involved is complicated. Or they may be oriented towards = a particular community. Such use cases may warrant having their own standa= lone document. 4) If we try to put all use cases into a single document, we run the risk t= hat folk will continue to ask that additional scenarios be added, making it= difficult to close out and finish the document. With that in mind, the WG needs to make some choices. We propose: 1) Have the WG develop one use case document that documents a small number = of representative use cases. The document presented by Hongyu Li at the Va= ncouver BOF could serve for this purpose (http://datatracker.ietf.org/doc/d= raft-liu-service-chaining-use-cases). 2) Remove "Section 4. Service Function Chaining Use Cases" from draft-quin= n-sfc-problem-statement. At present, one section is TBD, and the other sec= tion "3GPP Gi Interface Service Function Chaining" would need significant e= xpansion, and that expansion probably makes more sense in a separate docume= nt. If there was a simple use case that could be explained (to an IETF read= er) in 1-2 pages, we could consider putting it here, but we'd need a propos= al. (Any takers?) 3) For additional use cases not covered in 1) above, allow for a small numb= er of documents that are applicable to specific environments (e.g. mobilit= y, data center, broadband, and so forth.) These documents would provide mor= e detailed information and applicability of SFC to these specific environme= nts, and would need to go beyond what is covered in the general use case do= cument (1). Note that it is not the intention to have every potential use c= ase documented. Comments? Does the above approach seem reasonable to folks on the list? Any= objections? Jim & Thomas --_000_94C682931C08B048B7A8645303FDC9F36F47360A1BPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

I= meant to adopt “draft-liu-sfc-use-cases” as the use-case docum= ent. draft-liu-service-chaining-use-cases was replaced by draft-liu-sfc-use= -cases.

 

Cheers,

= Med

 

De : sfc [ma= ilto:sfc-bounces@ietf.org] De la part de mohamed.boucadair@orange.co= m
Envoy=E9 : lundi 27 janvier 2014 07:51
=C0 : Jim Guichard (jguichar); sfc@ietf.org
Objet : Re: [sfc] Pr= ogression of use case documents within the SFC working group

 

Hi Jim, all,

 =

I support the adoption of draft-liu-service-c= haining-use-cases as a place to record some the use cases already discussed= in this list.

 

As I’m the author of the "3GPP Gi In= terface Service Function Chaining” section of the PS document, I̵= 7;m fine to remove that text from the PS and merge it with the text of draf= t-liu-service-chaining-use-cases.

<= o:p> 

Cheers,

=

Med

 <= /o:p>

De : sfc [mailto:sfc-bounces@= ietf.org] De la part de Jim Guichard (jguichar)
Envoy=E9&n= bsp;: vendredi 24 janvier 2014 19:01
=C0 : sfc@ietf.org
Objet : [sfc] Progressio= n of use case documents within the SFC working group

<= /div>

 

Greetings,

 

The do= cumentation and applicability of use cases for the SFC WG was discussed dur= ing both the Berlin and Vancouver BOFs. The main purpose of those discussio= ns was to show support for our work and subsequent formation of a working g= roup.

 =

As we move forward wi= th our work we would like to solicit opinions of how best to approach use c= ases within the WG. The SFC charter left it open as to whether we should ha= ve a single problem statement that includes use cases or whether to separat= e out the use cases.

<= span style=3D'font-size:13.5pt;font-family:"Calibri","sans-serif";color:bla= ck'> 

Some b= ackground:

&= nbsp;

1) An important = purpose for having use cases is to connect a problem or solution to a real = concrete scenario. On the problem side, a use case can highlight requiremen= ts for any solution. Hence, having SFC use cases is important. Lack of use = cases could lead to missed requirements.

 

2) Having just one use case is probably not enough, but havin= g too many quickly leads to diminishing returns. The sweet spot is a relati= vely small number (3? 4?) that are different enough that they flesh out the= (different) key requirements. We know that more use cases aren't helping w= hen they simply reaffirm requirements that have already been made apparent = by other use cases.

 

3) Som= e use cases may be detailed and complicated , i.e., because the scenario or= technology involved is complicated. Or they may be oriented towards a part= icular community.  Such use cases may warrant having their own st= andalone document.

 

4) If = we try to put all use cases into a single document, we run the risk that fo= lk will continue to ask that additional scenarios be added, making it diffi= cult to close out and finish the document.

=

 

With that in mind, the WG needs to make some choices. We = propose:

&= nbsp;

1) Have the WG d= evelop one use case document that documents a small number of representativ= e use cases.  The document presented by Hongyu Li at the Vancouve= r BOF could serve for this purpose (http://datatracker.ietf.org/doc/d= raft-liu-service-chaining-use-cases).

<= p class=3DMsoNormal> 

2) Remove "Section 4.  Service Function Chain= ing Use Cases” from draft-quinn-sfc-problem-statement. At present, on= e section is TBD,  and the other section "3GPP Gi Interface Servi= ce Function Chaining” would need significant expansion, and that expa= nsion probably makes more sense in a separate document. If there was a simp= le use case that could be explained (to an IETF reader) in 1-2 pages, we co= uld consider putting it here, but we'd need a proposal. (Any takers?)<= /o:p>

 

3) For additional use cases not = covered in 1) above, allow for a small number of documents that are applica= ble to specific environments (e.g.  mobility, data center, broadb= and, and so forth.) These documents would provide more detailed information= and applicability of SFC to these specific environments, and would need to= go beyond what is covered in the general use case document (1). Note that = it is not the intention to have every potential use case documented.

 

Comments? Does the above approach= seem reasonable to folks on the list? Any objections?

 

Jim & Thomas

= --_000_94C682931C08B048B7A8645303FDC9F36F47360A1BPUEXCB1Bnante_-- From paulq@cisco.com Mon Jan 27 06:10:31 2014 Return-Path: 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 90B131A0234 for ; Mon, 27 Jan 2014 06:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 fh7E1aIrJRvi for ; Mon, 27 Jan 2014 06:10:29 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id CDE731A020F for ; Mon, 27 Jan 2014 06:10:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3524; q=dns/txt; s=iport; t=1390831828; x=1392041428; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7EI3i47qAKg3qdt1UVVxs0NPR24fqYsC+/GTHl0/LqQ=; b=TfSv5+4U8W6kRlkc7EJ0GqrOLS1ZSHc8kJm3ook67ovegLR9keej3/UR YRdZeo5fHF/AIutOsnpGQ2kECSRkfXitT6RFmpnemcD366N6hMyLnoiCW aqCHqK4vwNYIwdCcRzL8U0phQyLd6UtuyNK8JLNVYLwOmz2Bd7LrOJy8f o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFANtn5lKtJXHB/2dsb2JhbABZgww4VoJ9uVkYdBZ0giUBAQEEAQEBIBE6CwwEAgEGAhEEAQEBAgIjAwICAiULFAEICAIEDgWIBQ2PT5txnF4TBIEpjTEYGwcGgmk1gRQBA5gnkh6DLYIq X-IronPort-AV: E=Sophos;i="4.95,729,1384300800"; d="scan'208";a="299946612" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 27 Jan 2014 14:10:24 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0REAOla026485 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Jan 2014 14:10:24 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.19]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Mon, 27 Jan 2014 08:10:24 -0600 From: "Paul Quinn (paulq)" To: "Songhaibin (A)" Thread-Topic: [sfc] Services eligible for chaining Thread-Index: AQHPG2mFQeofjW3B0UKZbnWKHHGTnQ== Date: Mon, 27 Jan 2014 14:10:23 +0000 Message-ID: <6A6EB5A7-A39B-49DD-B665-7198EBDA9723@cisco.com> References: <9C2DE4B8FE85984BA1B0581235F6B2ED0F633EAB@SZXEMA502-MBS.china.huawei.com> <9C2DE4B8FE85984BA1B0581235F6B2ED0F633F22@SZXEMA502-MBS.china.huawei.com> <52E5CAF7.80603@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.229] Content-Type: text/plain; charset="utf-8" Content-ID: <593814CEC0CD884998493C35DF452A1A@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Melinda Shore , "sfc@ietf.org" Subject: Re: [sfc] Services eligible for chaining X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 14:10:31 -0000 SGkgSGFpYmluLA0KDQoNCk9uIEphbiAyNywgMjAxNCwgYXQgNDozNiBBTSwgU29uZ2hhaWJpbiAo QSkgPGhhaWJpbi5zb25nQGh1YXdlaS5jb20+IHdyb3RlOg0KDQo+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4gRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBNZWxpbmRhIFNob3JlDQo+PiBTZW50OiBNb25kYXksIEphbnVhcnkgMjcsIDIw MTQgMTA6NTcgQU0NCj4+IFRvOiBzZmNAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSDn rZTlpI06IFNlcnZpY2VzIGVsaWdpYmxlIGZvciBjaGFpbmluZw0KPj4gDQo+PiBPbiAxLzI2LzE0 IDU6MzEgUE0sIFpodWFuZ3l1eGluIHdyb3RlOg0KPj4+ICAgICAgICAgV2hlbiB0cmFmZmljIGZy b20gSW50ZXJuZXQgYXJyaXZlcyBhdCB0aGUgcm91dGVyLCBpdHMgZGVzdElQDQo+Pj4gcG9pbnRz IGF0IE5BVC4gSG93IGRvZXMgdGhlIHJvdXRlciBkZWNpZGUgdGhlIG5leHQgaG9wPw0KPj4+IA0K Pj4+IC0gICAgICAgIEFzIHRoZSBwYWNrZXQgaXMgZGlyZWN0bHkgYWRkcmVzc2VkIHRvIHRoZSBO QVQsIGRvZXMgaXQNCj4+PiBjb25mbGljdCB3aXRoIHRoZSDigJh0cmFuc3BhcmVudCBtaWRib3ji gJkgY29uY2VwdCBpbg0KPj4+IGRyYWZ0LXBhcmtlci1zZmMtY2hhaW4tdG8tcGF0aC0wMD8NCj4g DQo+IEkgdGhpbmsgdGhlIE5BVCBzZXJ2aWNlIGZ1bmN0aW9uIGlzIHRyYW5zcGFyZW50IHRvIHRo ZSBlbmQgdXNlcnMsIGJ1dCBub3QgdG8gU0ZDLg0KPiANCj4+PiANCj4+PiAtICAgICAgICBJcyBp dCBwb3NzaWJsZSBmb3IgdGhlIFJvdXRlciB0byBzZW5kIG91dCBBUlAgdG8gcXVlcnkgZm9yIHRo ZQ0KPj4+IElQIGFkZHJlc3Mgb24gTkFUPyBIb3cgZG9lcyBOQVQgcmVhY3QgdG8gQVJQIHJlcXVl c3QgZXNwZWNpYWxseSB3aGVuDQo+Pj4gTkFUIGlzIFNGQy1hd2FyZT8NCj4+IA0KPj4gV2hlbiBJ IGZpcnN0IHJlYWQgdGhpcyBJIHRob3VnaHQgIldlbGwsIHllcywgYW5kIE5BVCBpcyBwYXJ0aWN1 bGFybHkgc2Vuc2l0aXZlIHRvDQo+PiBuZXR3b3JrIHRvcG9sb2d5IChkZXZpY2Ugb3JkZXJpbmcp LiIgIEJ1dCwgSSB0aGluayB0aGlzIG5lZWRuJ3QgYWN0dWFsbHkgY3JlYXRlDQo+PiBhIHBhcnRp Y3VsYXJseSBkaWZmaWN1bHQgcHJvYmxlbSBoZXJlLCBzaW5jZSB0aGUgb3JpZ2luYWwgcGFja2V0 IGlzIGdvaW5nIHRvIGJlDQo+PiBlbmNhcHN1bGF0ZWQgYnkgdGhlIFNGQyB0cmFuc3BvcnQuIiAg SG93ZXZlciwgdGhlcmUgY2FuIGJlIHRoZSB1c3VhbA0KPj4gcHJvYmxlbXMgd2l0aCBzZXJ2aWNl IG9yZGVyaW5nIHRoYXQgeW91IGZpbmQgd2l0aGluIGEgc2luZ2xlIGJveCAtIGZvciBleGFtcGxl LA0KPj4geW91IG5lZWQgdG8gYmUgYXR0ZW50aXZlIHRvIHdoaWNoIGFkZHJlc3NlcyB5b3UncmUg cHV0dGluZyBpbnRvIHlvdXIgZmlyZXdhbGxpbmcNCj4+IHJ1bGVzLCBldGMuICBCdXQgdGhhdCdz IGdvaW5nIHRvIGJlIHRydWUsIHJlZ2FyZGxlc3Mgd2hldGhlciB0aGUgc2VydmljZXMgYXJlDQo+ PiBkZWNvbXBvc2VkIGludG8gZGlmZmVyZW50IGJveGVzIG9yIGNvLXJlc2lkZW50IHdpdGhpbiB0 aGUgc2FtZSBib3guDQo+PiBTaW1pbGFybHksIHRoZSBOQVQtZnJvbS10aGUtb3V0c2lkZSBwcm9i bGVtIGV4aXN0cyB3aGV0aGVyIG9yIG5vdCB5b3UncmUgdXNpbmcNCj4+IFNGQy4NCj4gDQo+IEkg ZG8gbm90IHRoaW5rIHdlIHNob3VsZCBtYWtlIHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucyBhd2FyZSBv ZiB0aGUgc2VydmljZSBmdW5jdGlvbiBjaGFpbmluZy4gIFNGcyBzaG91bGQgb25seSByZWNlaXZl IHRoZSBvcmlnaW5hbCBwYWNrZXQgYXMgdGhleSBjb252ZW50aW9uYWxseSBkbywgd2l0aG91dCBh bnkgU0ZDIGhlYWRlcnMuIFRoZSBTRkMgZm9yd2FyZGluZyBlbmdpbmUgc2hvdWxkIGJlIHJlc3Bv bnNpYmxlIGZvciBhZGRpbmcvcmVtb3ZpbmcgdGhlIGhlYWRlci4NCj4gDQoNCldoYXQgZXhhY3Rs eSBkbyB5b3UgbWVhbiBieSAiYXdhcmUiPyAgSW4gY2VydGFpbiBjYXNlcywgdGhlIFNGcyB3aWxs IG5lZWQgdG8gYmUgYXdhcmUgb2YgdGhlIFNGQyBlbmNhcC4NCg0KDQoNCg0KDQo+PiANCj4+IElm IHRoZXJlJ3MgaW50ZXJlc3QgSSBjYW4gY29udHJpYnV0ZSBhIGRyYWZ0IG9uIG1pZGRsZWJveCBj b25zaWRlcmF0aW9ucy4NCj4gDQo+IFdoYXQgYWJvdXQgYWxzbyBkb2N1bWVudGluZyB0aGUgZGVw bG95bWVudCBjb25zaWRlcmF0aW9ucyBpbiBpdD8NCj4gDQo+IEJSLA0KPiAtSGFpYmluDQo+IA0K Pj4gDQo+PiBNZWxpbmRhDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+PiBzZmMgbWFpbGluZyBsaXN0DQo+PiBzZmNAaWV0Zi5vcmcNCj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNmYyBtYWlsaW5nIGxpc3QN Cj4gc2ZjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2ZjDQoNCg== From cfrederick@sandvine.com Mon Jan 27 06:27:56 2014 Return-Path: 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 1E7221A0236 for ; Mon, 27 Jan 2014 06:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] 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 41pPh_bu3TCM for ; Mon, 27 Jan 2014 06:27:50 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id D20431A013F for ; Mon, 27 Jan 2014 06:27:49 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%16]) with mapi id 14.01.0339.001; Mon, 27 Jan 2014 09:27:46 -0500 From: Chris Frederick To: "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] IPR check for draft-quinn-sfc-problem-statement Thread-Index: AQHPFtu2O3ornJShr0OlqV+EtD9b+pqP/DAA//+Ae4CAACuAgIAAeVkAgAAAywCAAB6YAIAAApGAgACjNECABo4hAIABM8hw Date: Mon, 27 Jan 2014 14:27:46 +0000 Message-ID: <802F0FD88084CC4D82A0663874219D1A1887F398@wtl-exchp-2.sandvine.com> References: <1E714095C88C9D408749A723A59CF6ED1C06E441@SJEXCHMB12.corp.ad.broadcom.com> <8F9A3BC8F79F244DB44EC1569235CB4F79FCC918@ORD1EXD04.RACKSPACE.CORP> <64BC961C-E325-40C4-BFFF-0F4F395FF68F@cisco.com> <802F0FD88084CC4D82A0663874219D1A1887DF44@wtl-exchp-2.sandvine.com> <68BA82B4-DA2E-441B-A2FA-9138711940EA@cisco.com> In-Reply-To: <68BA82B4-DA2E-441B-A2FA-9138711940EA@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.91.160.188] Content-Type: multipart/alternative; boundary="_000_802F0FD88084CC4D82A0663874219D1A1887F398wtlexchp2sandvi_" MIME-Version: 1.0 Cc: Thomas Narten , "sfc@ietf.org" , "Jim Guichard \(jguichar\)" , "Michael Smith \(michsmit\)" , Brad McConnell , "Paul Quinn \(paulq\)" Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 14:27:56 -0000 --_000_802F0FD88084CC4D82A0663874219D1A1887F398wtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Carlos, I was trying to draw a distinction between IPR related to the 'process of a= ctual chaining' (which it's not) and IPR related to the granular selection = of 'what gets chained' (which it is). Thx for the pointer to the proper form, I'm new here + still getting my be= arings. Best, /c From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] Sent: Sunday, January 26, 2014 10:00 AM To: Chris Frederick Cc: Michael Smith (michsmit); Paul Quinn (paulq); Brad McConnell; Thomas Na= rten; Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement Chris, Just to be clear -- when you say "This is not related to SFC specifically",= are you acknowledging that you know of no IPR with subject matter related = to draft-quinn-sfc-problem-statement-02.txt? Also, if there is any IPR to be disclosed, the actual disclosure should be = done at http://www.ietf.org/ipr/file-disclosure.html and not on the WG mail= ing list. Thanks, -- Carlos. On Jan 22, 2014, at 11:07 AM, Chris Frederick > wrote: Hello, Sandvine has intellectual property related to the granular steering of traf= fic flows, specifically where the session has been established. This techni= que enables steering on the basis of application, content, etc, vs. just th= e port that would be seen in the initial SYN packet. This is outlined here: http://www.google.com/patents/WO2004086714A1?cl=3Den This is not related to SFC specifically but I bring it to your attention as= this technique can be used to select flows that would then be redirected t= hrough a service function chain or path; Sandvine uses this mechanism in ou= r own SFC implementation for example. Best regards, Chris Frederick Director, Technology Partnerships cfrederick@sandvine.com From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Michael Smith (michsmi= t) Sent: Tuesday, January 21, 2014 8:10 PM To: Paul Quinn (paulq); Brad McConnell Cc: Thomas Narten; Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement I'm not aware of any either. Michael From: "Paul Quinn (paulq)" > Date: Tuesday, January 21, 2014 5:00 PM To: Brad McConnell > Cc: Thomas Narten >, "Jim Guich= ard (jguichar)" >, "sfc@ietf.= org" > Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement Me neither. Paul On Jan 21, 2014, at 6:11 PM, Brad McConnell > wrote: I'm not aware of any. Thank you, Brad McConnell ________________________________ From: sfc [sfc-bounces@ietf.org] on behalf of = Rajeev Manur [rmanur@broadcom.com] Sent: Tuesday, January 21, 2014 5:08 PM To: Jim Guichard (jguichar) Cc: Thomas Narten; sfc@ietf.org Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement +1 Thanks! --Rajeev From: sfc [mailto:sfc-bounces@ietf.org] On Behalf = Of Surendra Kumar (smkumar) Sent: Tuesday, January 21, 2014 2:54 PM To: Jim Guichard (jguichar) Cc: Thomas Narten; sfc@ietf.org Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement +1 Surendra. From: "Ken Gray (kegray)" > Date: Tuesday, January 21, 2014 12:18 PM To: Thomas Nadeau >= , "Jim Guichard (jguichar)" > Cc: Thomas Narten >, "sfc@ietf.= org" > Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement Ditto From: Thomas Nadeau > Date: Tuesday, January 21, 2014 2:54 PM To: "Jim Guichard (jguichar)" > Cc: Thomas Narten >, "sfc@ietf.= org" > Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement None from my end. On Jan 21, 2014:2:05 PM, at 2:05 PM, Jim Guichard (jguichar) > wrote: This email serves as a poll for knowledge of any IPR that applies to draft = [1], to ensure that IPR has been disclosed in compliance with IETF IPR rule= s (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email whether or not you are aware of any relevant IPR. The draft will no= t be adopted until a response has been received from each author and major = contributor. If you are on the SFC WG mailing list but are not listed as an author or co= ntributor, then please explicitly respond only if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. Thank you, Jim & Thomas SFC chairs [1] http://tools.ietf.org/id/draft-quinn-sfc-problem-statement-02.txt _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_802F0FD88084CC4D82A0663874219D1A1887F398wtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Carlos,

I was trying to draw a di= stinction between IPR related to the ‘process of actual chaining̵= 7; (which it’s not) and IPR related to the granular selection of R= 16;what gets chained’ (which it is).

Thx for the pointer to th= e proper form, I’m new here + still  getting my bearings. Be= st,

/c

 <= /p>

From: Carlos P= ignataro (cpignata) [mailto:cpignata@cisco.com]
Sent: Sunday, January 26, 2014 10:00 AM
To: Chris Frederick
Cc: Michael Smith (michsmit); Paul Quinn (paulq); Brad McConnell; Th= omas Narten; Jim Guichard (jguichar); sfc@ietf.org
Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement

 

Chris,

 

Just to be clear -- when you say "This is not r= elated to SFC specifically", are you acknowledging that you know of no= IPR with subject matter related to draft-quinn-sfc-problem-statement-= 02.txt?

 

Also, if there is any IPR to be disclosed, the actua= l disclosure should be done at http://www.ietf.org/ipr/file-disclosure.html and not = on the WG mailing list.

 

Thanks,

 

-- Carlos.

 

On Jan 22, 2014, at 11:07 AM, Chris Frederick <cfrederick@sandvine.com> wr= ote:



Hello,<= /p>

Sandvine has intellectual= property related to the granular steering of traffic flows, specifically w= here the session has been established. This technique enables steering on the basis of application, content, etc, vs. just the port that= would be seen in the initial SYN packet.

This is not related to SF= C specifically but I bring it to your attention as this technique can be us= ed to select flows that would then be redirected through a service function chain or path; Sandvine uses this mechanism in our own = SFC implementation for example. Best regards,

 <= /p>

From: sfc [mail= to:sfc-bounces@ietf.org]&n= bsp;On Behalf Of Michael Smith (michsmit)
Sent: Tuesday, Jan= uary 21, 2014 8:10 PM
To: Paul Quinn (pa= ulq); Brad McConnell
Cc: Thomas Narten;= Jim Guichard (jguichar); sfc@ietf.org<= /span>
Subject: Re: [sfc]= IPR check for draft-quinn-sfc-problem-statement

 

I'm not aware of any either.

Michael

 

From: "Paul Quinn (paulq)" = <paulq@c= isco.com>
Date: Tuesday, Jan= uary 21, 2014 5:00 PM
To: Brad McConnell= <bmcconne@rackspace.com>
Cc: Thomas Narten = <narte= n@us.ibm.com>, "Jim Guichard (jguichar)" <jguichar@cisco= .com>, "sfc@iet= f.org" <sfc@ietf.org>
Subject: Re: [sfc]= IPR check for draft-quinn-sfc-problem-statement

 

Me neither.

 

Paul

 

 

On Jan 21, 2014, at 6:11 PM, Brad McCon= nell <bmcconne@rackspace.com> wrote:




I'm not a= ware of any.

Thank you,

Brad McConnell

From:<= /span> sfc [sfc-= bounces@ietf.org] on behalf of Rajeev Manur [rmanur@broadcom.com= ]
Sent: Tuesday, Jan= uary 21, 2014 5:08 PM
To: Jim Guichard (= jguichar)
Cc: Thomas Narten;=  sfc@ietf.org
Subject: Re: [sfc]= IPR check for draft-quinn-sfc-problem-statement

 <= /p>

+1<= /p>

 <= /p>

Thanks!=

--Rajeev

 <= /p>

From: sfc [mailto:sfc-bounces@= ietf.org] O= n Behalf Of Surendra Kumar (smkumar)
Sent: Tuesday, Jan= uary 21, 2014 2:54 PM
To: Jim Guichard (= jguichar)
Cc: Thomas Narten;=  sfc@ietf.org
Subject: Re: [sfc]= IPR check for draft-quinn-sfc-problem-statement

 

+1

 

Surendra.

 

From: "Ken Gray (kegray)" &= lt;kegray@cisco.com>
Date: Tuesday, Jan= uary 21, 2014 12:18 PM
To: Thomas Nadeau = <tnadeau@lucidvision.com>, "Jim Guicha= rd (jguichar)" <jguichar@cisco.com>
Cc: Thomas Narten = <narten@us.ibm.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc]= IPR check for draft-quinn-sfc-problem-statement

 

Ditto

 

From: Thomas Nadeau <tnadeau@lucidvision.com>
Date: Tuesday, Jan= uary 21, 2014 2:54 PM
To: "Jim Guic= hard (jguichar)" <jguichar@cisco.com>
Cc: Thomas Narten = <narten@us.ibm.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc]= IPR check for draft-quinn-sfc-problem-statement

 

 

None from my end.

 

On Jan 21, 2014:2:05 PM, at 2:05 PM, Ji= m Guichard (jguichar) <jguichar@cisco.com> wrote:

 

This email serves as a poll for knowled= ge of any IPR that applies to draft [1], to ensure that IPR has been disclo= sed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). 

 

If you are listed as a document author = or contributor please respond to this email whether or not you are aware of= any relevant IPR. The draft will not be adopted until a response has been received from each author and major contributor. 

 

If you are on the SFC WG mailing list b= ut are not listed as an author or contributor, then please explicitly respo= nd only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. 

 

Thank you,

 

Jim & Thomas

SFC chairs

 

_______________________________________= ________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc<= /a>

 

 

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

 

--_000_802F0FD88084CC4D82A0663874219D1A1887F398wtlexchp2sandvi_-- From cfrederick@sandvine.com Mon Jan 27 06:36:37 2014 Return-Path: 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 0B2021A0214 for ; Mon, 27 Jan 2014 06:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] 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 57tOwGSshNWx for ; Mon, 27 Jan 2014 06:36:32 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 35E6A1A013F for ; Mon, 27 Jan 2014 06:36:31 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%20]) with mapi id 14.01.0339.001; Mon, 27 Jan 2014 09:36:28 -0500 From: Chris Frederick To: "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] IPR check for draft-quinn-sfc-problem-statement Thread-Index: AQHPFtu2O3ornJShr0OlqV+EtD9b+pqP/DAA//+Ae4CAACuAgIAAeVkAgAAAywCAAB6YAIAAApGAgACjNECABo4hAIABM8hwgAACNIA= Date: Mon, 27 Jan 2014 14:36:28 +0000 Message-ID: <802F0FD88084CC4D82A0663874219D1A1887F3DD@wtl-exchp-2.sandvine.com> References: <1E714095C88C9D408749A723A59CF6ED1C06E441@SJEXCHMB12.corp.ad.broadcom.com> <8F9A3BC8F79F244DB44EC1569235CB4F79FCC918@ORD1EXD04.RACKSPACE.CORP> <64BC961C-E325-40C4-BFFF-0F4F395FF68F@cisco.com> <802F0FD88084CC4D82A0663874219D1A1887DF44@wtl-exchp-2.sandvine.com> <68BA82B4-DA2E-441B-A2FA-9138711940EA@cisco.com> <802F0FD88084CC4D82A0663874219D1A1887F398@wtl-exchp-2.sandvine.com> In-Reply-To: <802F0FD88084CC4D82A0663874219D1A1887F398@wtl-exchp-2.sandvine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.91.160.188] Content-Type: multipart/alternative; boundary="_000_802F0FD88084CC4D82A0663874219D1A1887F3DDwtlexchp2sandvi_" MIME-Version: 1.0 Cc: Thomas Narten , "sfc@ietf.org" , "Jim Guichard \(jguichar\)" , "Michael Smith \(michsmit\)" , Brad McConnell , "Paul Quinn \(paulq\)" Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 14:36:37 -0000 --_000_802F0FD88084CC4D82A0663874219D1A1887F3DDwtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry, that's still not quite accurate; it's not just 'what gets chained', = there's an element of 'how' as well...I felt it was worth flagging because = the IPR covers an ability to steer (including into service function chains)= based on protocol/application, content, and so on (i.e. information not av= ailable on the first packet), yet the technique enables redirection from th= e first packet. Again, apologies for using the wrong forum; I'll check the link you provide= d. Thx, /c From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Chris Frederick Sent: Monday, January 27, 2014 9:28 AM To: Carlos Pignataro (cpignata) Cc: Thomas Narten; sfc@ietf.org; Jim Guichard (jguichar); Michael Smith (mi= chsmit); Brad McConnell; Paul Quinn (paulq) Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement Hi Carlos, I was trying to draw a distinction between IPR related to the 'process of a= ctual chaining' (which it's not) and IPR related to the granular selection = of 'what gets chained' (which it is). Thx for the pointer to the proper form, I'm new here + still getting my be= arings. Best, /c From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] Sent: Sunday, January 26, 2014 10:00 AM To: Chris Frederick Cc: Michael Smith (michsmit); Paul Quinn (paulq); Brad McConnell; Thomas Na= rten; Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement Chris, Just to be clear -- when you say "This is not related to SFC specifically",= are you acknowledging that you know of no IPR with subject matter related = to draft-quinn-sfc-problem-statement-02.txt? Also, if there is any IPR to be disclosed, the actual disclosure should be = done at http://www.ietf.org/ipr/file-disclosure.html and not on the WG mail= ing list. Thanks, -- Carlos. On Jan 22, 2014, at 11:07 AM, Chris Frederick > wrote: Hello, Sandvine has intellectual property related to the granular steering of traf= fic flows, specifically where the session has been established. This techni= que enables steering on the basis of application, content, etc, vs. just th= e port that would be seen in the initial SYN packet. This is outlined here: http://www.google.com/patents/WO2004086714A1?cl=3Den This is not related to SFC specifically but I bring it to your attention as= this technique can be used to select flows that would then be redirected t= hrough a service function chain or path; Sandvine uses this mechanism in ou= r own SFC implementation for example. Best regards, Chris Frederick Director, Technology Partnerships cfrederick@sandvine.com From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Michael Smith (michsmi= t) Sent: Tuesday, January 21, 2014 8:10 PM To: Paul Quinn (paulq); Brad McConnell Cc: Thomas Narten; Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement I'm not aware of any either. Michael From: "Paul Quinn (paulq)" > Date: Tuesday, January 21, 2014 5:00 PM To: Brad McConnell > Cc: Thomas Narten >, "Jim Guich= ard (jguichar)" >, "sfc@ietf.= org" > Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement Me neither. Paul On Jan 21, 2014, at 6:11 PM, Brad McConnell > wrote: I'm not aware of any. Thank you, Brad McConnell ________________________________ From: sfc [sfc-bounces@ietf.org] on behalf of = Rajeev Manur [rmanur@broadcom.com] Sent: Tuesday, January 21, 2014 5:08 PM To: Jim Guichard (jguichar) Cc: Thomas Narten; sfc@ietf.org Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement +1 Thanks! --Rajeev From: sfc [mailto:sfc-bounces@ietf.org] On Behalf = Of Surendra Kumar (smkumar) Sent: Tuesday, January 21, 2014 2:54 PM To: Jim Guichard (jguichar) Cc: Thomas Narten; sfc@ietf.org Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement +1 Surendra. From: "Ken Gray (kegray)" > Date: Tuesday, January 21, 2014 12:18 PM To: Thomas Nadeau >= , "Jim Guichard (jguichar)" > Cc: Thomas Narten >, "sfc@ietf.= org" > Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement Ditto From: Thomas Nadeau > Date: Tuesday, January 21, 2014 2:54 PM To: "Jim Guichard (jguichar)" > Cc: Thomas Narten >, "sfc@ietf.= org" > Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement None from my end. On Jan 21, 2014:2:05 PM, at 2:05 PM, Jim Guichard (jguichar) > wrote: This email serves as a poll for knowledge of any IPR that applies to draft = [1], to ensure that IPR has been disclosed in compliance with IETF IPR rule= s (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email whether or not you are aware of any relevant IPR. The draft will no= t be adopted until a response has been received from each author and major = contributor. If you are on the SFC WG mailing list but are not listed as an author or co= ntributor, then please explicitly respond only if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. Thank you, Jim & Thomas SFC chairs [1] http://tools.ietf.org/id/draft-quinn-sfc-problem-statement-02.txt _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_802F0FD88084CC4D82A0663874219D1A1887F3DDwtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry, that’s still= not quite accurate; it’s not just ‘what gets chained’, t= here’s an element of ‘how’ as well…I felt it was wo= rth flagging because the IPR covers an ability to steer (including into service function chains) based = on protocol/application, content, and so on (i.e. information not available= on the first packet), yet the technique enables redirection from the first= packet.

Again, apologies for usin= g the wrong forum; I’ll check the link you provided. Thx,<= /span>

/c

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Chris Frederick
Sent: Monday, January 27, 2014 9:28 AM
To: Carlos Pignataro (cpignata)
Cc: Thomas Narten; sfc@ietf.org; Jim Guichard (jguichar); Michael Sm= ith (michsmit); Brad McConnell; Paul Quinn (paulq)
Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement

 

Hi Carlos,

I was trying to draw a di= stinction between IPR related to the ‘process of actual chaining̵= 7; (which it’s not) and IPR related to the granular selection of R= 16;what gets chained’ (which it is).

Thx for the pointer to th= e proper form, I’m new here + still  getting my bearings. Be= st,

/c

 <= /p>

From: Carlos P= ignataro (cpignata) [mailto:cpignata@= cisco.com]
Sent: Sunday, January 26, 2014 10:00 AM
To: Chris Frederick
Cc: Michael Smith (michsmit); Paul Quinn (paulq); Brad McConnell; Th= omas Narten; Jim Guichard (jguichar); sfc@ietf.org
Subject: Re: [sfc] IPR check for draft-quinn-sfc-problem-statement

 

Chris,

 

Just to be clear -- when you say "This is not r= elated to SFC specifically", are you acknowledging that you know of no= IPR with subject matter related to draft-quinn-sfc-problem-statement-= 02.txt?

 

Also, if there is any IPR to be disclosed, the actua= l disclosure should be done at http://www.ietf.org/ipr/file-disclosure.html and not = on the WG mailing list.

 

Thanks,

 

-- Carlos.

 

On Jan 22, 2014, at 11:07 AM, Chris Frederick <cfrederick@sandvine.com> wr= ote:

 

Hello,<= /p>

Sandvine has intellectual= property related to the granular steering of traffic flows, specifically w= here the session has been established. This technique enables steering on the basis of application, content, etc, vs. just the port that= would be seen in the initial SYN packet.

This is not related to SF= C specifically but I bring it to your attention as this technique can be us= ed to select flows that would then be redirected through a service function chain or path; Sandvine uses this mechanism in our own = SFC implementation for example. Best regards,

 <= /p>

From: sfc [mail= to:sfc-bounces@ietf.org]&n= bsp;On Behalf Of Michael Smith (michsmit)
Sent: Tuesday, Jan= uary 21, 2014 8:10 PM
To: Paul Quinn (pa= ulq); Brad McConnell
Cc: Thomas Narten;= Jim Guichard (jguichar); sfc@ietf.org<= /span>
Subject: Re: [sfc]= IPR check for draft-quinn-sfc-problem-statement

 

I'm not aware of any either.

Michael

 

From: "Paul Quinn (paulq)" = <paulq@c= isco.com>
Date: Tuesday, Jan= uary 21, 2014 5:00 PM
To: Brad McConnell= <bmcconne@rackspace.com>
Cc: Thomas Narten = <narte= n@us.ibm.com>, "Jim Guichard (jguichar)" <jguichar@cisco= .com>, "sfc@iet= f.org" <sfc@ietf.org>
Subject: Re: [sfc]= IPR check for draft-quinn-sfc-problem-statement

 

Me neither.

 

Paul

 

 

On Jan 21, 2014, at 6:11 PM, Brad McCon= nell <bmcconne@rackspace.com> wrote:



I'm not a= ware of any.

Thank you,

Brad McConnell

From:<= /span> sfc [sfc-= bounces@ietf.org] on behalf of Rajeev Manur [rmanur@broadcom.com= ]
Sent: Tuesday, Jan= uary 21, 2014 5:08 PM
To: Jim Guichard (= jguichar)
Cc: Thomas Narten;=  sfc@ietf.org
Subject: Re: [sfc]= IPR check for draft-quinn-sfc-problem-statement

 <= /p>

+1<= /p>

 <= /p>

Thanks!=

--Rajeev

 <= /p>

From: sfc [mailto:sfc-bounces@= ietf.org] O= n Behalf Of Surendra Kumar (smkumar)
Sent: Tuesday, Jan= uary 21, 2014 2:54 PM
To: Jim Guichard (= jguichar)
Cc: Thomas Narten;=  sfc@ietf.org
Subject: Re: [sfc]= IPR check for draft-quinn-sfc-problem-statement

 

+1

 

Surendra.

 

From: "Ken Gray (kegray)" &= lt;kegray@cisco.com>
Date: Tuesday, Jan= uary 21, 2014 12:18 PM
To: Thomas Nadeau = <tnadeau@lucidvision.com>, "Jim Guicha= rd (jguichar)" <jguichar@cisco.com>
Cc: Thomas Narten = <narten@us.ibm.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc]= IPR check for draft-quinn-sfc-problem-statement

 

Ditto

 

From: Thomas Nadeau <tnadeau@lucidvision.com>
Date: Tuesday, Jan= uary 21, 2014 2:54 PM
To: "Jim Guic= hard (jguichar)" <jguichar@cisco.com>
Cc: Thomas Narten = <narten@us.ibm.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc]= IPR check for draft-quinn-sfc-problem-statement

 

 

None from my end.

 

On Jan 21, 2014:2:05 PM, at 2:05 PM, Ji= m Guichard (jguichar) <jguichar@cisco.com> wrote:

 

This email serves as a poll for knowled= ge of any IPR that applies to draft [1], to ensure that IPR has been disclo= sed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). 

 

If you are listed as a document author = or contributor please respond to this email whether or not you are aware of= any relevant IPR. The draft will not be adopted until a response has been received from each author and major contributor. 

 

If you are on the SFC WG mailing list b= ut are not listed as an author or contributor, then please explicitly respo= nd only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. 

 

Thank you,

 

Jim & Thomas

SFC chairs

 

_______________________________________= ________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc<= /a>

 

 

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

 

--_000_802F0FD88084CC4D82A0663874219D1A1887F3DDwtlexchp2sandvi_-- From linda.dunbar@huawei.com Mon Jan 27 12:19:52 2014 Return-Path: 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 DD5EB1A029E for ; Mon, 27 Jan 2014 12:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 0zjAY8VDANtS for ; Mon, 27 Jan 2014 12:19:50 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 646FE1A029F for ; Mon, 27 Jan 2014 12:19:49 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAM52293; Mon, 27 Jan 2014 20:19:46 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 27 Jan 2014 20:19:30 +0000 Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 27 Jan 2014 20:19:46 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml706-chm.china.huawei.com ([169.254.8.193]) with mapi id 14.03.0158.001; Mon, 27 Jan 2014 12:19:29 -0800 From: Linda Dunbar To: "Hongyu Li (Julio)" , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Progression of use case documents within the SFC working group Thread-Index: AQHPGnUSkkJmGtXDZEuu+by8Ow4ZnZqZBSQw Date: Mon, 27 Jan 2014 20:19:28 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C71C73@dfweml701-chm.china.huawei.com> References: <6EB34CB5D82C4645B826C56144826EA97E9B780F@SZXEMA509-MBX.china.huawei.com> In-Reply-To: <6EB34CB5D82C4645B826C56144826EA97E9B780F@SZXEMA509-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.174] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645C71C73dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [sfc] Progression of use case documents within the SFC working group X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 20:19:53 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645C71C73dfweml701chmchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydCB0aGUgYXBwcm9hY2guDQoNCkxpbmRhDQoNCg0KRnJvbTogc2ZjIFttYWlsdG86c2Zj LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKQ0K U2VudDogU2F0dXJkYXksIEphbnVhcnkgMjUsIDIwMTQgMjowMSBBTQ0KVG86IHNmY0BpZXRmLm9y ZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDogW3NmY10gUHJvZ3Jlc3Npb24gb2YgdXNl IGNhc2UgZG9jdW1lbnRzIHdpdGhpbiB0aGUgU0ZDIHdvcmtpbmcgZ3JvdXANCg0KR3JlZXRpbmdz LA0KDQpUaGUgZG9jdW1lbnRhdGlvbiBhbmQgYXBwbGljYWJpbGl0eSBvZiB1c2UgY2FzZXMgZm9y IHRoZSBTRkMgV0cgd2FzIGRpc2N1c3NlZCBkdXJpbmcgYm90aCB0aGUgQmVybGluIGFuZCBWYW5j b3V2ZXIgQk9Gcy4gVGhlIG1haW4gcHVycG9zZSBvZiB0aG9zZSBkaXNjdXNzaW9ucyB3YXMgdG8g c2hvdyBzdXBwb3J0IGZvciBvdXIgd29yayBhbmQgc3Vic2VxdWVudCBmb3JtYXRpb24gb2YgYSB3 b3JraW5nIGdyb3VwLg0KDQpBcyB3ZSBtb3ZlIGZvcndhcmQgd2l0aCBvdXIgd29yayB3ZSB3b3Vs ZCBsaWtlIHRvIHNvbGljaXQgb3BpbmlvbnMgb2YgaG93IGJlc3QgdG8gYXBwcm9hY2ggdXNlIGNh c2VzIHdpdGhpbiB0aGUgV0cuIFRoZSBTRkMgY2hhcnRlciBsZWZ0IGl0IG9wZW4gYXMgdG8gd2hl dGhlciB3ZSBzaG91bGQgaGF2ZSBhIHNpbmdsZSBwcm9ibGVtIHN0YXRlbWVudCB0aGF0IGluY2x1 ZGVzIHVzZSBjYXNlcyBvciB3aGV0aGVyIHRvIHNlcGFyYXRlIG91dCB0aGUgdXNlIGNhc2VzLg0K DQpTb21lIGJhY2tncm91bmQ6DQoNCjEpIEFuIGltcG9ydGFudCBwdXJwb3NlIGZvciBoYXZpbmcg dXNlIGNhc2VzIGlzIHRvIGNvbm5lY3QgYSBwcm9ibGVtIG9yIHNvbHV0aW9uIHRvIGEgcmVhbCBj b25jcmV0ZSBzY2VuYXJpby4gT24gdGhlIHByb2JsZW0gc2lkZSwgYSB1c2UgY2FzZSBjYW4gaGln aGxpZ2h0IHJlcXVpcmVtZW50cyBmb3IgYW55IHNvbHV0aW9uLiBIZW5jZSwgaGF2aW5nIFNGQyB1 c2UgY2FzZXMgaXMgaW1wb3J0YW50LiBMYWNrIG9mIHVzZSBjYXNlcyBjb3VsZCBsZWFkIHRvIG1p c3NlZCByZXF1aXJlbWVudHMuDQoNCjIpIEhhdmluZyBqdXN0IG9uZSB1c2UgY2FzZSBpcyBwcm9i YWJseSBub3QgZW5vdWdoLCBidXQgaGF2aW5nIHRvbyBtYW55IHF1aWNrbHkgbGVhZHMgdG8gZGlt aW5pc2hpbmcgcmV0dXJucy4gVGhlIHN3ZWV0IHNwb3QgaXMgYSByZWxhdGl2ZWx5IHNtYWxsIG51 bWJlciAoMz8gND8pIHRoYXQgYXJlIGRpZmZlcmVudCBlbm91Z2ggdGhhdCB0aGV5IGZsZXNoIG91 dCB0aGUgKGRpZmZlcmVudCkga2V5IHJlcXVpcmVtZW50cy4gV2Uga25vdyB0aGF0IG1vcmUgdXNl IGNhc2VzIGFyZW4ndCBoZWxwaW5nIHdoZW4gdGhleSBzaW1wbHkgcmVhZmZpcm0gcmVxdWlyZW1l bnRzIHRoYXQgaGF2ZSBhbHJlYWR5IGJlZW4gbWFkZSBhcHBhcmVudCBieSBvdGhlciB1c2UgY2Fz ZXMuDQoNCjMpIFNvbWUgdXNlIGNhc2VzIG1heSBiZSBkZXRhaWxlZCBhbmQgY29tcGxpY2F0ZWQg LCBpLmUuLCBiZWNhdXNlIHRoZSBzY2VuYXJpbyBvciB0ZWNobm9sb2d5IGludm9sdmVkIGlzIGNv bXBsaWNhdGVkLiBPciB0aGV5IG1heSBiZSBvcmllbnRlZCB0b3dhcmRzIGEgcGFydGljdWxhciBj b21tdW5pdHkuICBTdWNoIHVzZSBjYXNlcyBtYXkgd2FycmFudCBoYXZpbmcgdGhlaXIgb3duIHN0 YW5kYWxvbmUgZG9jdW1lbnQuDQoNCjQpIElmIHdlIHRyeSB0byBwdXQgYWxsIHVzZSBjYXNlcyBp bnRvIGEgc2luZ2xlIGRvY3VtZW50LCB3ZSBydW4gdGhlIHJpc2sgdGhhdCBmb2xrIHdpbGwgY29u dGludWUgdG8gYXNrIHRoYXQgYWRkaXRpb25hbCBzY2VuYXJpb3MgYmUgYWRkZWQsIG1ha2luZyBp dCBkaWZmaWN1bHQgdG8gY2xvc2Ugb3V0IGFuZCBmaW5pc2ggdGhlIGRvY3VtZW50Lg0KDQpXaXRo IHRoYXQgaW4gbWluZCwgdGhlIFdHIG5lZWRzIHRvIG1ha2Ugc29tZSBjaG9pY2VzLiBXZSBwcm9w b3NlOg0KDQoxKSBIYXZlIHRoZSBXRyBkZXZlbG9wIG9uZSB1c2UgY2FzZSBkb2N1bWVudCB0aGF0 IGRvY3VtZW50cyBhIHNtYWxsIG51bWJlciBvZiByZXByZXNlbnRhdGl2ZSB1c2UgY2FzZXMuICBU aGUgZG9jdW1lbnQgcHJlc2VudGVkIGJ5IEhvbmd5dSBMaSBhdCB0aGUgVmFuY291dmVyIEJPRiBj b3VsZCBzZXJ2ZSBmb3IgdGhpcyBwdXJwb3NlIChodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWxpdS1zZXJ2aWNlLWNoYWluaW5nLXVzZS1jYXNlcykuDQoNCjIpIFJlbW92ZSAi U2VjdGlvbiA0LiAgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyBVc2UgQ2FzZXPigJ0gZnJvbSBk cmFmdC1xdWlubi1zZmMtcHJvYmxlbS1zdGF0ZW1lbnQuIEF0IHByZXNlbnQsIG9uZSBzZWN0aW9u IGlzIFRCRCwgIGFuZCB0aGUgb3RoZXIgc2VjdGlvbiAiM0dQUCBHaSBJbnRlcmZhY2UgU2Vydmlj ZSBGdW5jdGlvbiBDaGFpbmluZ+KAnSB3b3VsZCBuZWVkIHNpZ25pZmljYW50IGV4cGFuc2lvbiwg YW5kIHRoYXQgZXhwYW5zaW9uIHByb2JhYmx5IG1ha2VzIG1vcmUgc2Vuc2UgaW4gYSBzZXBhcmF0 ZSBkb2N1bWVudC4gSWYgdGhlcmUgd2FzIGEgc2ltcGxlIHVzZSBjYXNlIHRoYXQgY291bGQgYmUg ZXhwbGFpbmVkICh0byBhbiBJRVRGIHJlYWRlcikgaW4gMS0yIHBhZ2VzLCB3ZSBjb3VsZCBjb25z aWRlciBwdXR0aW5nIGl0IGhlcmUsIGJ1dCB3ZSdkIG5lZWQgYSBwcm9wb3NhbC4gKEFueSB0YWtl cnM/KQ0KDQozKSBGb3IgYWRkaXRpb25hbCB1c2UgY2FzZXMgbm90IGNvdmVyZWQgaW4gMSkgYWJv dmUsIGFsbG93IGZvciBhIHNtYWxsIG51bWJlciBvZiBkb2N1bWVudHMgdGhhdCBhcmUgYXBwbGlj YWJsZSB0byBzcGVjaWZpYyBlbnZpcm9ubWVudHMgKGUuZy4gIG1vYmlsaXR5LCBkYXRhIGNlbnRl ciwgYnJvYWRiYW5kLCBhbmQgc28gZm9ydGguKSBUaGVzZSBkb2N1bWVudHMgd291bGQgcHJvdmlk ZSBtb3JlIGRldGFpbGVkIGluZm9ybWF0aW9uIGFuZCBhcHBsaWNhYmlsaXR5IG9mIFNGQyB0byB0 aGVzZSBzcGVjaWZpYyBlbnZpcm9ubWVudHMsIGFuZCB3b3VsZCBuZWVkIHRvIGdvIGJleW9uZCB3 aGF0IGlzIGNvdmVyZWQgaW4gdGhlIGdlbmVyYWwgdXNlIGNhc2UgZG9jdW1lbnQgKDEpLiBOb3Rl IHRoYXQgaXQgaXMgbm90IHRoZSBpbnRlbnRpb24gdG8gaGF2ZSBldmVyeSBwb3RlbnRpYWwgdXNl IGNhc2UgZG9jdW1lbnRlZC4NCg0KQ29tbWVudHM/IERvZXMgdGhlIGFib3ZlIGFwcHJvYWNoIHNl ZW0gcmVhc29uYWJsZSB0byBmb2xrcyBvbiB0aGUgbGlzdD8gQW55IG9iamVjdGlvbnM/DQoNCkpp bSAmIFRob21hcw0K --_000_4A95BA014132FF49AE685FAB4B9F17F645C71C73dfweml701chmchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5 bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjI1aW4gMS4waW4gMS4yNWluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TdXBwb3J0IHRoZSBhcHByb2FjaC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxp bmRhDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpz ZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkppbSBHdWljaGFy ZCAoamd1aWNoYXIpPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBKYW51YXJ5IDI1LCAyMDE0 IDI6MDEgQU08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNm Y0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3NmY10gUHJvZ3Jlc3Npb24gb2Yg dXNlIGNhc2UgZG9jdW1lbnRzIHdpdGhpbiB0aGUgU0ZDIHdvcmtpbmcgZ3JvdXA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5HcmVldGluZ3MsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPlRoZSBkb2N1bWVudGF0aW9uIGFuZCBhcHBsaWNhYmlsaXR5IG9m IHVzZSBjYXNlcyBmb3IgdGhlIFNGQyBXRyB3YXMgZGlzY3Vzc2VkIGR1cmluZyBib3RoIHRoZSBC ZXJsaW4gYW5kIFZhbmNvdXZlciBCT0ZzLiBUaGUgbWFpbiBwdXJwb3NlIG9mIHRob3NlIGRpc2N1 c3Npb25zDQogd2FzIHRvIHNob3cgc3VwcG9ydCBmb3Igb3VyIHdvcmsgYW5kIHN1YnNlcXVlbnQg Zm9ybWF0aW9uIG9mIGEgd29ya2luZyBncm91cC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEz LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+QXMgd2UgbW92ZSBmb3J3YXJkIHdpdGggb3VyIHdvcmsgd2Ugd291bGQgbGlrZSB0 byBzb2xpY2l0IG9waW5pb25zIG9mIGhvdyBiZXN0IHRvIGFwcHJvYWNoIHVzZSBjYXNlcyB3aXRo aW4gdGhlIFdHLiBUaGUgU0ZDIGNoYXJ0ZXIgbGVmdCBpdCBvcGVuIGFzIHRvIHdoZXRoZXINCiB3 ZSBzaG91bGQgaGF2ZSBhIHNpbmdsZSBwcm9ibGVtIHN0YXRlbWVudCB0aGF0IGluY2x1ZGVzIHVz ZSBjYXNlcyBvciB3aGV0aGVyIHRvIHNlcGFyYXRlIG91dCB0aGUgdXNlIGNhc2VzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Tb21lIGJhY2tncm91bmQ6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjEpIEFuIGltcG9ydGFudCBwdXJwb3NlIGZvciBoYXZp bmcgdXNlIGNhc2VzIGlzIHRvIGNvbm5lY3QgYSBwcm9ibGVtIG9yIHNvbHV0aW9uIHRvIGEgcmVh bCBjb25jcmV0ZSBzY2VuYXJpby4gT24gdGhlIHByb2JsZW0gc2lkZSwgYSB1c2UgY2FzZSBjYW4g aGlnaGxpZ2h0IHJlcXVpcmVtZW50cw0KIGZvciBhbnkgc29sdXRpb24uIEhlbmNlLCBoYXZpbmcg U0ZDIHVzZSBjYXNlcyBpcyBpbXBvcnRhbnQuIExhY2sgb2YgdXNlIGNhc2VzIGNvdWxkIGxlYWQg dG8gbWlzc2VkIHJlcXVpcmVtZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+MikgSGF2aW5nIGp1c3Qgb25lIHVzZSBjYXNlIGlzIHByb2JhYmx5IG5vdCBlbm91Z2gsIGJ1 dCBoYXZpbmcgdG9vIG1hbnkgcXVpY2tseSBsZWFkcyB0byBkaW1pbmlzaGluZyByZXR1cm5zLiBU aGUgc3dlZXQgc3BvdCBpcyBhIHJlbGF0aXZlbHkgc21hbGwgbnVtYmVyICgzPw0KIDQ/KSB0aGF0 IGFyZSBkaWZmZXJlbnQgZW5vdWdoIHRoYXQgdGhleSBmbGVzaCBvdXQgdGhlIChkaWZmZXJlbnQp IGtleSByZXF1aXJlbWVudHMuIFdlIGtub3cgdGhhdCBtb3JlIHVzZSBjYXNlcyBhcmVuJ3QgaGVs cGluZyB3aGVuIHRoZXkgc2ltcGx5IHJlYWZmaXJtIHJlcXVpcmVtZW50cyB0aGF0IGhhdmUgYWxy ZWFkeSBiZWVuIG1hZGUgYXBwYXJlbnQgYnkgb3RoZXIgdXNlIGNhc2VzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4zKSBTb21lIHVzZSBjYXNlcyBtYXkgYmUgZGV0YWlsZWQg YW5kIGNvbXBsaWNhdGVkICwgaS5lLiwgYmVjYXVzZSB0aGUgc2NlbmFyaW8gb3IgdGVjaG5vbG9n eSBpbnZvbHZlZCBpcyBjb21wbGljYXRlZC4gT3IgdGhleSBtYXkgYmUgb3JpZW50ZWQgdG93YXJk cyBhIHBhcnRpY3VsYXINCiBjb21tdW5pdHkuJm5ic3A7Jm5ic3A7U3VjaCB1c2UgY2FzZXMgbWF5 IHdhcnJhbnQgaGF2aW5nIHRoZWlyIG93biBzdGFuZGFsb25lIGRvY3VtZW50LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj40KSBJZiB3ZSB0cnkgdG8gcHV0IGFsbCB1c2UgY2Fz ZXMgaW50byBhIHNpbmdsZSBkb2N1bWVudCwgd2UgcnVuIHRoZSByaXNrIHRoYXQgZm9sayB3aWxs IGNvbnRpbnVlIHRvIGFzayB0aGF0IGFkZGl0aW9uYWwgc2NlbmFyaW9zIGJlIGFkZGVkLCBtYWtp bmcgaXQgZGlmZmljdWx0DQogdG8gY2xvc2Ugb3V0IGFuZCBmaW5pc2ggdGhlIGRvY3VtZW50Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5XaXRoIHRoYXQgaW4gbWluZCwgdGhl IFdHIG5lZWRzIHRvIG1ha2Ugc29tZSBjaG9pY2VzLiBXZSBwcm9wb3NlOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4xKSBIYXZlIHRoZSBXRyBkZXZlbG9wIG9uZSB1c2UgY2Fz ZSBkb2N1bWVudCB0aGF0IGRvY3VtZW50cyBhIHNtYWxsIG51bWJlciBvZiByZXByZXNlbnRhdGl2 ZSB1c2UgY2FzZXMuJm5ic3A7Jm5ic3A7VGhlIGRvY3VtZW50IHByZXNlbnRlZCBieSBIb25neXUg TGkgYXQgdGhlIFZhbmNvdXZlcg0KIEJPRiBjb3VsZCBzZXJ2ZSBmb3IgdGhpcyBwdXJwb3NlICg8 YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpdS1zZXJ2aWNl LWNoYWluaW5nLXVzZS1jYXNlcyI+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1saXUtc2VydmljZS1jaGFpbmluZy11c2UtY2FzZXM8L2E+KS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+MikgUmVtb3ZlICZxdW90O1NlY3Rpb24gNC4mbmJzcDsmbmJzcDtT ZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIFVzZSBDYXNlc+KAnSBmcm9tIGRyYWZ0LXF1aW5uLXNm Yy1wcm9ibGVtLXN0YXRlbWVudC4gQXQgcHJlc2VudCwgb25lIHNlY3Rpb24gaXMgVEJELCAmbmJz cDthbmQgdGhlIG90aGVyIHNlY3Rpb24gJnF1b3Q7M0dQUA0KIEdpIEludGVyZmFjZSBTZXJ2aWNl IEZ1bmN0aW9uIENoYWluaW5n4oCdIHdvdWxkIG5lZWQgc2lnbmlmaWNhbnQgZXhwYW5zaW9uLCBh bmQgdGhhdCBleHBhbnNpb24gcHJvYmFibHkgbWFrZXMgbW9yZSBzZW5zZSBpbiBhIHNlcGFyYXRl IGRvY3VtZW50LiBJZiB0aGVyZSB3YXMgYSBzaW1wbGUgdXNlIGNhc2UgdGhhdCBjb3VsZCBiZSBl eHBsYWluZWQgKHRvIGFuIElFVEYgcmVhZGVyKSBpbiAxLTIgcGFnZXMsIHdlIGNvdWxkIGNvbnNp ZGVyIHB1dHRpbmcNCiBpdCBoZXJlLCBidXQgd2UnZCBuZWVkIGEgcHJvcG9zYWwuIChBbnkgdGFr ZXJzPyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+MykgRm9yIGFkZGl0aW9u YWwgdXNlIGNhc2VzIG5vdCBjb3ZlcmVkIGluIDEpIGFib3ZlLCBhbGxvdyBmb3IgYSBzbWFsbCBu dW1iZXIgb2YgZG9jdW1lbnRzIHRoYXQgYXJlIGFwcGxpY2FibGUgdG8gc3BlY2lmaWMgZW52aXJv bm1lbnRzIChlLmcuJm5ic3A7Jm5ic3A7bW9iaWxpdHksIGRhdGENCiBjZW50ZXIsIGJyb2FkYmFu ZCwgYW5kIHNvIGZvcnRoLikgVGhlc2UgZG9jdW1lbnRzIHdvdWxkIHByb3ZpZGUgbW9yZSBkZXRh aWxlZCBpbmZvcm1hdGlvbiBhbmQgYXBwbGljYWJpbGl0eSBvZiBTRkMgdG8gdGhlc2Ugc3BlY2lm aWMgZW52aXJvbm1lbnRzLCBhbmQgd291bGQgbmVlZCB0byBnbyBiZXlvbmQgd2hhdCBpcyBjb3Zl cmVkIGluIHRoZSBnZW5lcmFsIHVzZSBjYXNlIGRvY3VtZW50ICgxKS4gTm90ZSB0aGF0IGl0IGlz IG5vdCB0aGUgaW50ZW50aW9uDQogdG8gaGF2ZSBldmVyeSBwb3RlbnRpYWwgdXNlIGNhc2UgZG9j dW1lbnRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Q29tbWVudHM/IERv ZXMgdGhlIGFib3ZlIGFwcHJvYWNoIHNlZW0gcmVhc29uYWJsZSB0byBmb2xrcyBvbiB0aGUgbGlz dD8gQW55IG9iamVjdGlvbnM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkpp bSAmYW1wOyBUaG9tYXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_4A95BA014132FF49AE685FAB4B9F17F645C71C73dfweml701chmchi_-- From zhuangyuxin@huawei.com Mon Jan 27 16:48:37 2014 Return-Path: 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 2078D1A02DA for ; Mon, 27 Jan 2014 16:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.215 X-Spam-Level: * X-Spam-Status: No, score=1.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 8THDzjo1KG9M for ; Mon, 27 Jan 2014 16:48:35 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 753E51A008F for ; Mon, 27 Jan 2014 16:48:34 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAM63309; Tue, 28 Jan 2014 00:48:31 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 00:48:01 +0000 Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 00:48:30 +0000 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.128]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Tue, 28 Jan 2014 08:48:22 +0800 From: Zhuangyuxin To: Zhuangyuxin , Ron Parker , "sfc@ietf.org" , "Melinda Shore" Thread-Topic: Services eligible for chaining Thread-Index: Ac8aTJ6FwniRxzcWRuaQFnPfr+bu1gAr0QHAAADQNHAAABcD4AAwlPPg Date: Tue, 28 Jan 2014 00:48:21 +0000 Message-ID: <9C2DE4B8FE85984BA1B0581235F6B2ED0F6350D1@SZXEMA502-MBS.china.huawei.com> References: <9C2DE4B8FE85984BA1B0581235F6B2ED0F633EAB@SZXEMA502-MBS.china.huawei.com> <9C2DE4B8FE85984BA1B0581235F6B2ED0F633F22@SZXEMA502-MBS.china.huawei.com> In-Reply-To: <9C2DE4B8FE85984BA1B0581235F6B2ED0F633F22@SZXEMA502-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.75.59] Content-Type: multipart/alternative; boundary="_000_9C2DE4B8FE85984BA1B0581235F6B2ED0F6350D1SZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [sfc] =?gb2312?b?tPC4tDogU2VydmljZXMgZWxpZ2libGUgZm9yIGNoYWluaW5n?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 00:48:37 -0000 --_000_9C2DE4B8FE85984BA1B0581235F6B2ED0F6350D1SZXEMA502MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 QWN0dWFsbHksIHdpdGggdGhlc2UgcXVlc3Rpb25zLCBJoa9tIHRyeWluZyB0byBmaWd1cmUgb3V0 IHdoZW4gd2UgcHV0IGFueSBzZXJ2aWNlIChlLmcuIE5BVC9MQi9WUE4pIHdpdGggTDMgYWRkcmVz cyBpbiB0aGUgY2hhaW4sIGEpIGhvdyB0aGUgcG9zc2libGUgQVJQIHBhY2tldHMgYXJlIGhhbmRs ZWQsIGIpIGhvdyB0aGUgcm91dGluZyB0YWJsZSBpcyBjb25maWd1cmVkIGZvciB0aGUgcm91dGVy cyB3aGljaCBhcmUgbm90IGluIHRoZSBjaGFpbiwgYnV0IHRoZSB0cmFmZmljIGNvbWluZyBvdXQg b2YgdGhlIGNoYWluIHdpbGwgZ28gdGhydS4NCg0KDQpUaGFua3MsDQpZdXhpbg0KDQq3orz+yMs6 IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFpodWFuZ3l1eGluDQq3osvN yrG85DogMjAxNMTqMdTCMjfI1SAxMDozMg0KytW8/sjLOiBSb24gUGFya2VyOyBzZmNAaWV0Zi5v cmcNCtb3zOI6IFtzZmNdILTwuLQ6IFNlcnZpY2VzIGVsaWdpYmxlIGZvciBjaGFpbmluZw0KDQpI aSwgUm9uLA0KDQpUaGFua3MgZm9yIHRoZSByZXBseS4NCg0KV2hlbiB3ZSBjb25zaWRlciBpbnNl cnRpbmcgTEIvTkFUIGluIHRoZSBjaGFpbiwgSSBoYXZlIHNvbWUgZnVydGhlciBxdWVzdGlvbnMg aGVyZS4NCg0KLSAgICAgICAgTGV0oa9zIHRha2UgYSBjaGFpbiB3aXRoIE5BVCBzZXJ2aWNlIGZ1 bmN0aW9uIGFzIGFuIGV4YW1wbGUsIHVzZXIgaXMgdXNpbmcgdGhpcyBjaGFpbiB0byBwcm9jZXNz IHRyYWZmaWMgcHJvZHVjZWQgYnkgVk0xIGFjY2Vzc2luZyBJbnRlcm5ldC4gSSBhc3N1bWUgdGhl IHRvcG9sb2d5IGlzIGxpa2UgdGhpczoNCiAgICAgICAgIFZNMSAgLS0tIChjaGFpbiBpbmNsdWRp bmcgTkFUKSAtLS0gUm91dGVyIC0tLSBJbnRlcm5ldA0KICAgICAgICAgV2hlbiB0cmFmZmljIGZy b20gSW50ZXJuZXQgYXJyaXZlcyBhdCB0aGUgcm91dGVyLCBpdHMgZGVzdElQIHBvaW50cyBhdCBO QVQuIEhvdyBkb2VzIHRoZSByb3V0ZXIgZGVjaWRlIHRoZSBuZXh0IGhvcD8NCi0gICAgICAgIEFz IHRoZSBwYWNrZXQgaXMgZGlyZWN0bHkgYWRkcmVzc2VkIHRvIHRoZSBOQVQsIGRvZXMgaXQgY29u ZmxpY3Qgd2l0aCB0aGUgoa50cmFuc3BhcmVudCBtaWRib3ihryBjb25jZXB0IGluIGRyYWZ0LXBh cmtlci1zZmMtY2hhaW4tdG8tcGF0aC0wMD8NCi0gICAgICAgIElzIGl0IHBvc3NpYmxlIGZvciB0 aGUgUm91dGVyIHRvIHNlbmQgb3V0IEFSUCB0byBxdWVyeSBmb3IgdGhlIElQIGFkZHJlc3Mgb24g TkFUPyBIb3cgZG9lcyBOQVQgcmVhY3QgdG8gQVJQIHJlcXVlc3QgZXNwZWNpYWxseSB3aGVuIE5B VCBpcyBTRkMtYXdhcmU/DQoNClRoYW5rcywNCll1eGluDQoNCreivP7IyzogUm9uIFBhcmtlciBb bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb21dDQq3osvNyrG85DogMjAxNMTq MdTCMjfI1SA5OjI5DQrK1bz+yMs6IFpodWFuZ3l1eGluOyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNm Y0BpZXRmLm9yZz4NCtb3zOI6IFJFOiBTZXJ2aWNlcyBlbGlnaWJsZSBmb3IgY2hhaW5pbmcNCg0K WXV4aW4sDQoNCkJvdGggbG9hZCBiYWxhbmNlciBhbmQgTkFUIGFyZSBkZWZpbml0ZWx5IGNhbmRp ZGF0ZXMgZm9yIFNGQyBzZXJ2aWNlIGZ1bmN0aW9ucy4NCg0KICAgUm9uDQoNCg0KRnJvbTogc2Zj IFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBaaHVhbmd5dXhpbg0K U2VudDogU3VuZGF5LCBKYW51YXJ5IDI2LCAyMDE0IDg6MDYgUE0NClRvOiBzZmNAaWV0Zi5vcmc8 bWFpbHRvOnNmY0BpZXRmLm9yZz4NClN1YmplY3Q6IFtzZmNdIFNlcnZpY2VzIGVsaWdpYmxlIGZv ciBjaGFpbmluZw0KDQpIZWxsbywgRm9sa3MsDQoNCkZvciBTRkMsIGRvIHlvdSBoYXZlIGFueSBj b25jcmV0ZSBzZXJ2aWNlIGNhbmRpZGF0ZXMgd2hpY2ggYXJlIGVsaWdpYmxlIGZvciBjaGFpbmlu Zz8gSG93IGFib3V0IGxvYWQgYmFsYW5jZXIgYW5kIE5BVCwgd2hpY2ggdXN1YWxseSBjcm9zcyBz dWJuZXRzIGFuZCBjaGFuZ2UgcGFja2V0IGhlYWRlcj8gQXJlIHRoZXkgc3VpdGFibGUgZm9yIHRo ZSBjaGFpbiB3ZSBhcmUgZGlzY3Vzc2luZyBoZXJlPw0KDQpUaGFua3MsDQpZdXhpbg0K --_000_9C2DE4B8FE85984BA1B0581235F6B2ED0F6350D1SZXEMA502MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Actuall= y, with these questions, I=A1=AFm trying to figure out when we put any serv= ice (e.g. NAT/LB/VPN) with L3 address in the chain, a) how the possible ARP= packets are handled, b) how the routing table is configured for the routers which are not in the chain, but the traffic = coming out of the chain will go thru.

&n= bsp;

&n= bsp;

Thanks,=

Yuxin

&n= bsp;

=B7=A2=BC=FE=C8=CB: sfc [mailto:sfc-bounces@ietf.org] =B4=FA= =B1=ED Zhuangyuxin
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C227=C8=D5 10:32
=CA=D5=BC=FE=C8=CB: Ron Parker; sfc@ietf.org
=D6=F7=CC=E2: [sfc] =B4=F0=B8=B4: Services eligible for cha= ining

 

Hi, Ron= ,

&n= bsp;

Thanks = for the reply.

&n= bsp;

When we= consider inserting LB/NAT in the chain, I have some further questions here= .

&n= bsp;

- =        Let=A1=AFs take a chain with NAT servi= ce function as an example, user is using this chain to process traffic prod= uced by VM1 accessing Internet. I assume the topology is like this:

 &= nbsp;       VM1  --- (chain including NA= T) --- Router --- Internet

   &nb= sp;     When traffic from Internet arrives at the route= r, its destIP points at NAT. How does the router decide the next hop?<= /o:p>

-   &n= bsp;    As the packet is directly addressed to the NAT, does= it conflict with the =A1=AEtransparent midbox=A1=AF concept in draft-parke= r-sfc-chain-to-path-00?

-   &n= bsp;    Is it possible for the Router to send out ARP to que= ry for the IP address on NAT? How does NAT react to ARP request especially = when NAT is SFC-aware?

&n= bsp;

Thanks,=

Yuxin

&n= bsp;

=B7=A2=BC=FE=C8=CB: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C227=C8=D5 9:29
=CA=D5=BC=FE=C8=CB: Zhuangyuxin; sfc@ietf.org
=D6=F7=CC=E2: RE: Services eligible for chaining

 

Yuxin,

 

Both load balancer and NAT are definitely candidates for SFC serv= ice functions.

 

   Ron

 

 

From: sfc [= mailto:sfc-bounces@ietf.org] On Behalf Of Zhuangyuxin
Sent: Sunday, January 26, 2014 8:06 PM
To: sfc@ietf.org
Subject: [sfc] Services eligible for chaining

 

Hello, Folks,=

 

For SFC, do you have any concre= te service candidates which are eligible for chaining? How about load balan= cer and NAT, which usually cross subnets and change packet header? Are they= suitable for the chain we are discussing here?

 

Thanks,

Yuxin

--_000_9C2DE4B8FE85984BA1B0581235F6B2ED0F6350D1SZXEMA502MBSchi_-- From jmh@joelhalpern.com Mon Jan 27 16:58:09 2014 Return-Path: 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 A5D391A016E for ; Mon, 27 Jan 2014 16:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 B7k6lZOjKL6S for ; Mon, 27 Jan 2014 16:58:08 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADF31A008F for ; Mon, 27 Jan 2014 16:58:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 5751F184C7F; Mon, 27 Jan 2014 16:58:06 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-128.clppva.east.verizon.net [70.106.135.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 4E9EE184C7E; Mon, 27 Jan 2014 16:58:03 -0800 (PST) Message-ID: <52E70099.1040705@joelhalpern.com> Date: Mon, 27 Jan 2014 19:58:01 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Zhuangyuxin , Ron Parker , "sfc@ietf.org" , Melinda Shore References: <9C2DE4B8FE85984BA1B0581235F6B2ED0F633EAB@SZXEMA502-MBS.china.huawei.com> <9C2DE4B8FE85984BA1B0581235F6B2ED0F633F22@SZXEMA502-MBS.china.huawei.com> <9C2DE4B8FE85984BA1B0581235F6B2ED0F6350D1@SZXEMA502-MBS.china.huawei.com> In-Reply-To: <9C2DE4B8FE85984BA1B0581235F6B2ED0F6350D1@SZXEMA502-MBS.china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sfc] =?utf-8?b?562U5aSNOiBTZXJ2aWNlcyBlbGlnaWJsZSBmb3IgY2hhaW5p?= =?utf-8?q?ng?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 00:58:09 -0000 A priori, ARP internal to the network will work as always. Whether that is relevant for directing service chain traffic depends upon the service chain transport. In terms of general operation, it helps to keep the two different directions, and two different cases. Traffic from the users should be directed via service chain to the services, which are not addressed by the user. The NAT is an example of such a service. In the reverse direction, there are two ways to handle it, although they work out very similarly in the end. Initially, the easy shortcut is to put the NAT at the end of the chain, co-resident with the Internet facing ingress to the chain. Thus, packets will arrive at the right place. Clearly, that is quite limiting. So the other laternative is for the NAT to inform the control structure of the induced flow bindings (i.e. what the subscriber flow is translated into) so that the ingress classifier can put the packets from the Internet on the correct chain based on that information. Yours, Joel On 1/27/14 7:48 PM, Zhuangyuxin wrote: > Actually, with these questions, I’m trying to figure out when we put any > service (e.g. NAT/LB/VPN) with L3 address in the chain, a) how the > possible ARP packets are handled, b) how the routing table is configured > for the routers which are not in the chain, but the traffic coming out > of the chain will go thru. > > Thanks, > > Yuxin > > *å‘件人:*sfc [mailto:sfc-bounces@ietf.org] *代表 *Zhuangyuxin > *å‘é€æ—¶é—´:*2014å¹´1月27æ—¥10:32 > *收件人:*Ron Parker; sfc@ietf.org > *主题:*[sfc] ç­”å¤: Services eligible for chaining > > Hi, Ron, > > Thanks for the reply. > > When we consider inserting LB/NAT in the chain, I have some further > questions here. > > - Let’s take a chain with NAT service function as an example, > user is using this chain to process traffic produced by VM1 accessing > Internet. I assume the topology is like this: > > VM1 --- (chain including NAT) --- Router --- Internet > > When traffic from Internet arrives at the router, its destIP > points at NAT. How does the router decide the next hop? > > - As the packet is directly addressed to the NAT, does it > conflict with the ‘transparent midbox’ concept in > draft-parker-sfc-chain-to-path-00? > > - Is it possible for the Router to send out ARP to query for the > IP address on NAT? How does NAT react to ARP request especially when NAT > is SFC-aware? > > Thanks, > > Yuxin > > *å‘件人:*Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > *å‘é€æ—¶é—´:*2014å¹´1月27æ—¥9:29 > *收件人:*Zhuangyuxin; sfc@ietf.org > *主题:*RE: Services eligible for chaining > > Yuxin, > > Both load balancer and NAT are definitely candidates for SFC service > functions. > > Ron > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Zhuangyuxin > *Sent:* Sunday, January 26, 2014 8:06 PM > *To:* sfc@ietf.org > *Subject:* [sfc] Services eligible for chaining > > Hello, Folks, > > For SFC, do you have any concrete service candidates which are eligible > for chaining? How about load balancer and NAT, which usually cross > subnets and change packet header? Are they suitable for the chain we are > discussing here? > > Thanks, > > Yuxin > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From haibin.song@huawei.com Mon Jan 27 17:35:31 2014 Return-Path: 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 30C471A025B for ; Mon, 27 Jan 2014 17:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 P9MXT9g7-hyi for ; Mon, 27 Jan 2014 17:35:29 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 91C221A00A7 for ; Mon, 27 Jan 2014 17:35:28 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCZ65256; Tue, 28 Jan 2014 01:35:25 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 01:34:55 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 01:35:24 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Tue, 28 Jan 2014 09:35:19 +0800 From: "Songhaibin (A)" To: "Paul Quinn (paulq)" Thread-Topic: [sfc] Services eligible for chaining Thread-Index: AQHPG2mPKQekg45kuE+liiqDaAKKRJqZWMDg Date: Tue, 28 Jan 2014 01:35:18 +0000 Message-ID: References: <9C2DE4B8FE85984BA1B0581235F6B2ED0F633EAB@SZXEMA502-MBS.china.huawei.com> <9C2DE4B8FE85984BA1B0581235F6B2ED0F633F22@SZXEMA502-MBS.china.huawei.com> <52E5CAF7.80603@gmail.com> <6A6EB5A7-A39B-49DD-B665-7198EBDA9723@cisco.com> In-Reply-To: <6A6EB5A7-A39B-49DD-B665-7198EBDA9723@cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.70] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Melinda Shore , "sfc@ietf.org" Subject: Re: [sfc] Services eligible for chaining X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 01:35:31 -0000 SGkgUGF1bCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBQYXVsIFF1 aW5uIChwYXVscSkgW21haWx0bzpwYXVscUBjaXNjby5jb21dDQo+IFNlbnQ6IE1vbmRheSwgSmFu dWFyeSAyNywgMjAxNCAxMDoxMCBQTQ0KPiBUbzogU29uZ2hhaWJpbiAoQSkNCj4gQ2M6IE1lbGlu ZGEgU2hvcmU7IHNmY0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZXMgZWxp Z2libGUgZm9yIGNoYWluaW5nDQo+IA0KPiBIaSBIYWliaW4sDQo+IA0KPiANCj4gT24gSmFuIDI3 LCAyMDE0LCBhdCA0OjM2IEFNLCBTb25naGFpYmluIChBKSA8aGFpYmluLnNvbmdAaHVhd2VpLmNv bT4NCj4gd3JvdGU6DQo+IA0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBG cm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1lbGlu ZGEgU2hvcmUNCj4gPj4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDI3LCAyMDE0IDEwOjU3IEFNDQo+ ID4+IFRvOiBzZmNAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFtzZmNdIOetlOWkjTogU2Vy dmljZXMgZWxpZ2libGUgZm9yIGNoYWluaW5nDQo+ID4+DQo+ID4+IE9uIDEvMjYvMTQgNTozMSBQ TSwgWmh1YW5neXV4aW4gd3JvdGU6DQo+ID4+PiAgICAgICAgIFdoZW4gdHJhZmZpYyBmcm9tIElu dGVybmV0IGFycml2ZXMgYXQgdGhlIHJvdXRlciwgaXRzIGRlc3RJUA0KPiA+Pj4gcG9pbnRzIGF0 IE5BVC4gSG93IGRvZXMgdGhlIHJvdXRlciBkZWNpZGUgdGhlIG5leHQgaG9wPw0KPiA+Pj4NCj4g Pj4+IC0gICAgICAgIEFzIHRoZSBwYWNrZXQgaXMgZGlyZWN0bHkgYWRkcmVzc2VkIHRvIHRoZSBO QVQsIGRvZXMgaXQNCj4gPj4+IGNvbmZsaWN0IHdpdGggdGhlIOKAmHRyYW5zcGFyZW50IG1pZGJv eOKAmSBjb25jZXB0IGluDQo+ID4+PiBkcmFmdC1wYXJrZXItc2ZjLWNoYWluLXRvLXBhdGgtMDA/ DQo+ID4NCj4gPiBJIHRoaW5rIHRoZSBOQVQgc2VydmljZSBmdW5jdGlvbiBpcyB0cmFuc3BhcmVu dCB0byB0aGUgZW5kIHVzZXJzLCBidXQgbm90IHRvDQo+IFNGQy4NCj4gPg0KPiA+Pj4NCj4gPj4+ IC0gICAgICAgIElzIGl0IHBvc3NpYmxlIGZvciB0aGUgUm91dGVyIHRvIHNlbmQgb3V0IEFSUCB0 byBxdWVyeSBmb3IgdGhlDQo+ID4+PiBJUCBhZGRyZXNzIG9uIE5BVD8gSG93IGRvZXMgTkFUIHJl YWN0IHRvIEFSUCByZXF1ZXN0IGVzcGVjaWFsbHkgd2hlbg0KPiA+Pj4gTkFUIGlzIFNGQy1hd2Fy ZT8NCj4gPj4NCj4gPj4gV2hlbiBJIGZpcnN0IHJlYWQgdGhpcyBJIHRob3VnaHQgIldlbGwsIHll cywgYW5kIE5BVCBpcyBwYXJ0aWN1bGFybHkNCj4gPj4gc2Vuc2l0aXZlIHRvIG5ldHdvcmsgdG9w b2xvZ3kgKGRldmljZSBvcmRlcmluZykuIiAgQnV0LCBJIHRoaW5rIHRoaXMNCj4gPj4gbmVlZG4n dCBhY3R1YWxseSBjcmVhdGUgYSBwYXJ0aWN1bGFybHkgZGlmZmljdWx0IHByb2JsZW0gaGVyZSwg c2luY2UNCj4gPj4gdGhlIG9yaWdpbmFsIHBhY2tldCBpcyBnb2luZyB0byBiZSBlbmNhcHN1bGF0 ZWQgYnkgdGhlIFNGQw0KPiA+PiB0cmFuc3BvcnQuIiAgSG93ZXZlciwgdGhlcmUgY2FuIGJlIHRo ZSB1c3VhbCBwcm9ibGVtcyB3aXRoIHNlcnZpY2UNCj4gPj4gb3JkZXJpbmcgdGhhdCB5b3UgZmlu ZCB3aXRoaW4gYSBzaW5nbGUgYm94IC0gZm9yIGV4YW1wbGUsIHlvdSBuZWVkIHRvDQo+ID4+IGJl IGF0dGVudGl2ZSB0byB3aGljaCBhZGRyZXNzZXMgeW91J3JlIHB1dHRpbmcgaW50byB5b3VyIGZp cmV3YWxsaW5nDQo+ID4+IHJ1bGVzLCBldGMuICBCdXQgdGhhdCdzIGdvaW5nIHRvIGJlIHRydWUs IHJlZ2FyZGxlc3Mgd2hldGhlciB0aGUgc2VydmljZXMgYXJlDQo+IGRlY29tcG9zZWQgaW50byBk aWZmZXJlbnQgYm94ZXMgb3IgY28tcmVzaWRlbnQgd2l0aGluIHRoZSBzYW1lIGJveC4NCj4gPj4g U2ltaWxhcmx5LCB0aGUgTkFULWZyb20tdGhlLW91dHNpZGUgcHJvYmxlbSBleGlzdHMgd2hldGhl ciBvciBub3QNCj4gPj4geW91J3JlIHVzaW5nIFNGQy4NCj4gPg0KPiA+IEkgZG8gbm90IHRoaW5r IHdlIHNob3VsZCBtYWtlIHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucyBhd2FyZSBvZiB0aGUgc2Vydmlj ZQ0KPiBmdW5jdGlvbiBjaGFpbmluZy4gIFNGcyBzaG91bGQgb25seSByZWNlaXZlIHRoZSBvcmln aW5hbCBwYWNrZXQgYXMgdGhleQ0KPiBjb252ZW50aW9uYWxseSBkbywgd2l0aG91dCBhbnkgU0ZD IGhlYWRlcnMuIFRoZSBTRkMgZm9yd2FyZGluZyBlbmdpbmUgc2hvdWxkDQo+IGJlIHJlc3BvbnNp YmxlIGZvciBhZGRpbmcvcmVtb3ZpbmcgdGhlIGhlYWRlci4NCj4gPg0KPiANCj4gV2hhdCBleGFj dGx5IGRvIHlvdSBtZWFuIGJ5ICJhd2FyZSI/ICBJbiBjZXJ0YWluIGNhc2VzLCB0aGUgU0ZzIHdp bGwgbmVlZCB0bw0KPiBiZSBhd2FyZSBvZiB0aGUgU0ZDIGVuY2FwLg0KDQpJIG1lYW4gdGhleShT RnMpIGNhbiBwcm9jZXNzIHRoZSBwYWNrZXRzIGFzIHRoZXJlIHdlcmUgbm8gU0ZDLiBPdGhlcndp c2Ugd2UgbmVlZCB0byB1cGdyYWRlIHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucyB0byBzdXBwb3J0IFNG Qywgd2hpY2ggd2lsbCBiZSBhIGhpbmRyYW5jZSBmb3IgdGhlIGFkb3B0aW9uIG9mIFNGQy4gTWF5 YmUgSSBtaXNzZWQgc29tZXRoaW5nIG9yIG15IHRob3VnaHQgaXMgdG9vIGlkZWFsLCBidXQgd2hh dCBpcyB0aGUgdXNlIGNhc2UgaW4geW91ciBtaW5kIHRoYXQgYSBTRiBtdXN0IGJlIGF3YXJlIG9m IHRoZSBTRkMgZW5jYXA/IFRoZSBtZXRhZGF0YT8NCg0KQlIsDQotSGFpYmluDQoNCg0KPiANCj4g DQo+ID4+DQo+ID4+IElmIHRoZXJlJ3MgaW50ZXJlc3QgSSBjYW4gY29udHJpYnV0ZSBhIGRyYWZ0 IG9uIG1pZGRsZWJveCBjb25zaWRlcmF0aW9ucy4NCj4gPg0KPiA+IFdoYXQgYWJvdXQgYWxzbyBk b2N1bWVudGluZyB0aGUgZGVwbG95bWVudCBjb25zaWRlcmF0aW9ucyBpbiBpdD8NCj4gPg0KPiA+ IEJSLA0KPiA+IC1IYWliaW4NCj4gPg0KPiA+Pg0KPiA+PiBNZWxpbmRhDQo+ID4+DQo+ID4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IHNmYyBt YWlsaW5nIGxpc3QNCj4gPj4gc2ZjQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPiBzZmMgbWFpbGluZyBsaXN0DQo+ID4gc2ZjQGlldGYub3Jn DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0K From jun.lee@huawei.com Mon Jan 27 18:16:09 2014 Return-Path: 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 D22991A00A7 for ; Mon, 27 Jan 2014 18:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.215 X-Spam-Level: * X-Spam-Status: No, score=1.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 GwxCnd1GnIMP for ; Mon, 27 Jan 2014 18:16:08 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 407971A008F for ; Mon, 27 Jan 2014 18:16:07 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAM67358; Tue, 28 Jan 2014 02:16:03 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 02:15:33 +0000 Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 02:16:02 +0000 Received: from SZXEMA507-MBS.china.huawei.com ([169.254.6.91]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Tue, 28 Jan 2014 10:15:50 +0800 From: Leejun To: Zhuangyuxin , Zhuangyuxin , Ron Parker , "sfc@ietf.org" , Melinda Shore Thread-Topic: Services eligible for chaining Thread-Index: Ac8aTJ6FwniRxzcWRuaQFnPfr+bu1gAr0QHAAADQNHAAABcD4AAwlPPgAAKOGCA= Date: Tue, 28 Jan 2014 02:15:49 +0000 Message-ID: <81126FE293D58240BD872F99F2606543368E3E75@szxema507-mbs.china.huawei.com> References: <9C2DE4B8FE85984BA1B0581235F6B2ED0F633EAB@SZXEMA502-MBS.china.huawei.com> <9C2DE4B8FE85984BA1B0581235F6B2ED0F633F22@SZXEMA502-MBS.china.huawei.com> <9C2DE4B8FE85984BA1B0581235F6B2ED0F6350D1@SZXEMA502-MBS.china.huawei.com> In-Reply-To: <9C2DE4B8FE85984BA1B0581235F6B2ED0F6350D1@SZXEMA502-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.205] Content-Type: multipart/alternative; boundary="_000_81126FE293D58240BD872F99F2606543368E3E75szxema507mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [sfc] =?gb2312?b?tPC4tDogU2VydmljZXMgZWxpZ2libGUgZm9yIGNoYWluaW5n?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 02:16:10 -0000 --_000_81126FE293D58240BD872F99F2606543368E3E75szxema507mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 V2l0aG91dCBTRkMsIHBhY2tldHMgY2FuIGFscmVhZHkgYmUgZm9yd2FyZGVkIHRvIHNlcnZpY2Ug ZnVuY3Rpb25zIHdpdGggTDMgYWRkcmVzcy4gIEluIHRoaXMgcmVnYXJkLCAgc2VydmljZSBmdW5j dGlvbnMgd2l0aCBMMyBhZGRyZXNzIGFyZSBxdWl0ZSBkaWZmZXJlbnQgdG8gdGhvc2Ugoa50cmFu c3BhcmVudCBtaWRib3ihry4NClNvLCBJIHdvbmRlciB3aHkgU0ZDIHNob3VsZCBjb3ZlciBOQVQg YW5kIExCLg0KDQpSZWdhcmRzDQpMaSBqdW4NCg0KDQoNCreivP7Iyzogc2ZjIFttYWlsdG86c2Zj LWJvdW5jZXNAaWV0Zi5vcmddILT6se0gWmh1YW5neXV4aW4NCreiy83KsbzkOiAyMDE0xOox1MIy OMjVIDg6NDgNCsrVvP7IyzogWmh1YW5neXV4aW47IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZzsg TWVsaW5kYSBTaG9yZQ0K1vfM4jogW3NmY10gtPC4tDogU2VydmljZXMgZWxpZ2libGUgZm9yIGNo YWluaW5nDQoNCkFjdHVhbGx5LCB3aXRoIHRoZXNlIHF1ZXN0aW9ucywgSaGvbSB0cnlpbmcgdG8g ZmlndXJlIG91dCB3aGVuIHdlIHB1dCBhbnkgc2VydmljZSAoZS5nLiBOQVQvTEIvVlBOKSB3aXRo IEwzIGFkZHJlc3MgaW4gdGhlIGNoYWluLCBhKSBob3cgdGhlIHBvc3NpYmxlIEFSUCBwYWNrZXRz IGFyZSBoYW5kbGVkLCBiKSBob3cgdGhlIHJvdXRpbmcgdGFibGUgaXMgY29uZmlndXJlZCBmb3Ig dGhlIHJvdXRlcnMgd2hpY2ggYXJlIG5vdCBpbiB0aGUgY2hhaW4sIGJ1dCB0aGUgdHJhZmZpYyBj b21pbmcgb3V0IG9mIHRoZSBjaGFpbiB3aWxsIGdvIHRocnUuDQoNCg0KVGhhbmtzLA0KWXV4aW4N Cg0Kt6K8/sjLOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBaaHVhbmd5 dXhpbg0Kt6LLzcqxvOQ6IDIwMTTE6jHUwjI3yNUgMTA6MzINCsrVvP7IyzogUm9uIFBhcmtlcjsg c2ZjQGlldGYub3JnDQrW98ziOiBbc2ZjXSC08Li0OiBTZXJ2aWNlcyBlbGlnaWJsZSBmb3IgY2hh aW5pbmcNCg0KSGksIFJvbiwNCg0KVGhhbmtzIGZvciB0aGUgcmVwbHkuDQoNCldoZW4gd2UgY29u c2lkZXIgaW5zZXJ0aW5nIExCL05BVCBpbiB0aGUgY2hhaW4sIEkgaGF2ZSBzb21lIGZ1cnRoZXIg cXVlc3Rpb25zIGhlcmUuDQoNCi0gICAgICAgIExldKGvcyB0YWtlIGEgY2hhaW4gd2l0aCBOQVQg c2VydmljZSBmdW5jdGlvbiBhcyBhbiBleGFtcGxlLCB1c2VyIGlzIHVzaW5nIHRoaXMgY2hhaW4g dG8gcHJvY2VzcyB0cmFmZmljIHByb2R1Y2VkIGJ5IFZNMSBhY2Nlc3NpbmcgSW50ZXJuZXQuIEkg YXNzdW1lIHRoZSB0b3BvbG9neSBpcyBsaWtlIHRoaXM6DQogICAgICAgICBWTTEgIC0tLSAoY2hh aW4gaW5jbHVkaW5nIE5BVCkgLS0tIFJvdXRlciAtLS0gSW50ZXJuZXQNCiAgICAgICAgIFdoZW4g dHJhZmZpYyBmcm9tIEludGVybmV0IGFycml2ZXMgYXQgdGhlIHJvdXRlciwgaXRzIGRlc3RJUCBw b2ludHMgYXQgTkFULiBIb3cgZG9lcyB0aGUgcm91dGVyIGRlY2lkZSB0aGUgbmV4dCBob3A/DQot ICAgICAgICBBcyB0aGUgcGFja2V0IGlzIGRpcmVjdGx5IGFkZHJlc3NlZCB0byB0aGUgTkFULCBk b2VzIGl0IGNvbmZsaWN0IHdpdGggdGhlIKGudHJhbnNwYXJlbnQgbWlkYm94oa8gY29uY2VwdCBp biBkcmFmdC1wYXJrZXItc2ZjLWNoYWluLXRvLXBhdGgtMDA/DQotICAgICAgICBJcyBpdCBwb3Nz aWJsZSBmb3IgdGhlIFJvdXRlciB0byBzZW5kIG91dCBBUlAgdG8gcXVlcnkgZm9yIHRoZSBJUCBh ZGRyZXNzIG9uIE5BVD8gSG93IGRvZXMgTkFUIHJlYWN0IHRvIEFSUCByZXF1ZXN0IGVzcGVjaWFs bHkgd2hlbiBOQVQgaXMgU0ZDLWF3YXJlPw0KDQpUaGFua3MsDQpZdXhpbg0KDQq3orz+yMs6IFJv biBQYXJrZXIgW21haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tXQ0Kt6LLzcqx vOQ6IDIwMTTE6jHUwjI3yNUgOToyOQ0KytW8/sjLOiBaaHVhbmd5dXhpbjsgc2ZjQGlldGYub3Jn PG1haWx0bzpzZmNAaWV0Zi5vcmc+DQrW98ziOiBSRTogU2VydmljZXMgZWxpZ2libGUgZm9yIGNo YWluaW5nDQoNCll1eGluLA0KDQpCb3RoIGxvYWQgYmFsYW5jZXIgYW5kIE5BVCBhcmUgZGVmaW5p dGVseSBjYW5kaWRhdGVzIGZvciBTRkMgc2VydmljZSBmdW5jdGlvbnMuDQoNCiAgIFJvbg0KDQoN CkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWmh1 YW5neXV4aW4NClNlbnQ6IFN1bmRheSwgSmFudWFyeSAyNiwgMjAxNCA4OjA2IFBNDQpUbzogc2Zj QGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbc2ZjXSBTZXJ2aWNlcyBl bGlnaWJsZSBmb3IgY2hhaW5pbmcNCg0KSGVsbG8sIEZvbGtzLA0KDQpGb3IgU0ZDLCBkbyB5b3Ug aGF2ZSBhbnkgY29uY3JldGUgc2VydmljZSBjYW5kaWRhdGVzIHdoaWNoIGFyZSBlbGlnaWJsZSBm b3IgY2hhaW5pbmc/IEhvdyBhYm91dCBsb2FkIGJhbGFuY2VyIGFuZCBOQVQsIHdoaWNoIHVzdWFs bHkgY3Jvc3Mgc3VibmV0cyBhbmQgY2hhbmdlIHBhY2tldCBoZWFkZXI/IEFyZSB0aGV5IHN1aXRh YmxlIGZvciB0aGUgY2hhaW4gd2UgYXJlIGRpc2N1c3NpbmcgaGVyZT8NCg0KVGhhbmtzLA0KWXV4 aW4NCg== --_000_81126FE293D58240BD872F99F2606543368E3E75szxema507mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Without= SFC, packets can already be forwarded to service functions with L3 address= .  In this regard,  service functions with L3 address are quite d= ifferent to those =A1=AEtransparent midbo= x=A1=AF.

So, I w= onder why SFC should cover NAT and LB.

&n= bsp;

Regards=

Li jun<= o:p>

&n= bsp;

&n= bsp;

&n= bsp;

=B7=A2=BC=FE=C8=CB: sfc [mailto:sfc-bounces@ietf.org] =B4=FA= =B1=ED Zhuangyuxin
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C228=C8=D5 8:48
=CA=D5=BC=FE=C8=CB: Zhuangyuxin; Ron Parker; sfc@ietf.org; Melinda Shore
=D6=F7=CC=E2: [sfc] =B4=F0=B8=B4: Services eligible for cha= ining

 

Actuall= y, with these questions, I=A1=AFm trying to figure out when we put any serv= ice (e.g. NAT/LB/VPN) with L3 address in the chain, a) how the possible ARP= packets are handled, b) how the routing table is configured for the routers which are not in the chain, but the traffic = coming out of the chain will go thru.

&n= bsp;

&n= bsp;

Thanks,=

Yuxin

&n= bsp;

=B7=A2=BC=FE=C8=CB: sfc [mailto:sfc-bounces@ietf.org] =B4=FA= =B1=ED Zhuangyuxin
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C227=C8=D5 10:32
=CA=D5=BC=FE=C8=CB: Ron Parker; sfc@ietf.org
=D6=F7=CC=E2: [sfc] =B4=F0=B8=B4: Services eligible for cha= ining

 

Hi, Ron= ,

&n= bsp;

Thanks = for the reply.

&n= bsp;

When we= consider inserting LB/NAT in the chain, I have some further questions here= .

&n= bsp;

- =        Let=A1=AFs take a chain with NAT servi= ce function as an example, user is using this chain to process traffic prod= uced by VM1 accessing Internet. I assume the topology is like this:

 &= nbsp;       VM1  --- (chain including NA= T) --- Router --- Internet

   &nb= sp;     When traffic from Internet arrives at the route= r, its destIP points at NAT. How does the router decide the next hop?<= /o:p>

-   &n= bsp;    As the packet is directly addressed to the NAT, does= it conflict with the =A1=AEtransparent midbox=A1=AF concept in draft-parke= r-sfc-chain-to-path-00?

-   &n= bsp;    Is it possible for the Router to send out ARP to que= ry for the IP address on NAT? How does NAT react to ARP request especially = when NAT is SFC-aware?

&n= bsp;

Thanks,=

Yuxin

&n= bsp;

=B7=A2=BC=FE=C8=CB: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C227=C8=D5 9:29
=CA=D5=BC=FE=C8=CB: Zhuangyuxin; sfc@ietf.org
=D6=F7=CC=E2: RE: Services eligible for chaining

 

Yuxin,

 

Both load balancer and NAT are definitely candidates for SFC serv= ice functions.

 

   Ron

 

 

From: sfc [= mailto:sfc-bounces@ietf.org] On Behalf Of Zhuangyuxin
Sent: Sunday, January 26, 2014 8:06 PM
To: sfc@ietf.org
Subject: [sfc] Services eligible for chaining

 

Hello, Folks,=

 

For SFC, do you have any concre= te service candidates which are eligible for chaining? How about load balan= cer and NAT, which usually cross subnets and change packet header? Are they= suitable for the chain we are discussing here?

 

Thanks,

Yuxin

--_000_81126FE293D58240BD872F99F2606543368E3E75szxema507mbschi_-- From guanxiaoran@huawei.com Mon Jan 27 23:23:52 2014 Return-Path: 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 D0E931A01C9 for ; Mon, 27 Jan 2014 23:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.216 X-Spam-Level: * X-Spam-Status: No, score=1.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 qbYqsCo3kbru for ; Mon, 27 Jan 2014 23:23:49 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 921C41A0161 for ; Mon, 27 Jan 2014 23:23:48 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCZ87492; Tue, 28 Jan 2014 07:23:44 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 07:23:03 +0000 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 07:23:32 +0000 Received: from SZXEML522-MBX.china.huawei.com ([169.254.2.227]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.03.0158.001; Tue, 28 Jan 2014 15:23:27 +0800 From: Guanxiaoran To: Nicolas BOUTHORS , "sfc@ietf.org" Thread-Topic: Note on GI deployment scenario draft-liu-sfc-use-cases-00 Thread-Index: AQHPG0E50IKowRRhXEC5c6zdZjgHZZqZvJyA Date: Tue, 28 Jan 2014 07:23:27 +0000 Message-ID: <2C5AD5728DB9B24189E3A93140E45786367C79@szxeml522-mbx.china.huawei.com> References: <76B41B8FACE1514795D30EC137FF391D3D08E0@LILAS.jungle.qosmos.com> In-Reply-To: <76B41B8FACE1514795D30EC137FF391D3D08E0@LILAS.jungle.qosmos.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.113] Content-Type: multipart/related; boundary="_004_2C5AD5728DB9B24189E3A93140E45786367C79szxeml522mbxchina_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [sfc] =?gb2312?b?tPC4tDogTm90ZSBvbiBHSSBkZXBsb3ltZW50IHNjZW5hcmlv?= =?gb2312?b?IGRyYWZ0LWxpdS1zZmMtdXNlLWNhc2VzLTAw?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 07:23:53 -0000 --_004_2C5AD5728DB9B24189E3A93140E45786367C79szxeml522mbxchina_ Content-Type: multipart/alternative; boundary="_000_2C5AD5728DB9B24189E3A93140E45786367C79szxeml522mbxchina_" --_000_2C5AD5728DB9B24189E3A93140E45786367C79szxeml522mbxchina_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgTmljb2xhcywNCg0KRG8geW91IG1lYW4gdGhhdCBEUEkgbXVzdCBzdXBwb3J0IFJBRElVUyBw cm94eSBpbiB0aGlzIGNhc2U/DQoNClJhbg0KDQq3orz+yMs6IHNmYyBbbWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnXSC0+rHtIE5pY29sYXMgQk9VVEhPUlMNCreiy83KsbzkOiAyMDE0xOox1MIy N8jVIDE3OjIzDQrK1bz+yMs6IHNmY0BpZXRmLm9yZw0K1vfM4jogW3NmY10gTm90ZSBvbiBHSSBk ZXBsb3ltZW50IHNjZW5hcmlvIGRyYWZ0LWxpdS1zZmMtdXNlLWNhc2VzLTAwDQoNCkhlbGxvLA0K DQpPbiBHaSBkZXBsb3ltZW50cyB0aGUgR0dTTiBjb25uZWN0cyB0byBhIFJhZGl1cyBGdW5jdGlv biBhdCBQRFAgQ29udGV4dCBTZXR1cCBUaW1lLiBJbiBtb3N0IGNhc2UNCnRoaXMgaXMgdXNlZCB0 byBwZXJmb3JtIGFuZCBNU0lTRE4gdG8gSVAgYWRkcmVzcyBtYXBwaW5nLCB3aGljaCBpcyB0aGVu IHVzZWQgYnkgdGhlIEdpIHNlcnZpY2UgaW5mcmFzdHJ1Y3R1cmUNCnRvIGRlY2lkZSBob3cgdG8g aGFuZGxlIHRoZSBJUCBmbG93cyBmb3IgdGhhdCBwYXJ0aWN1bGFyIHN1YnNjcmliZXIuDQoNClRo aXMgaW5mb3JtYXRpb24gY2Fubm90IGJlIGRlcml2ZWQgYnkgdGhlIERQSSBsb2NhdGVkIGFmdGVy IHRoZSBHR1NOLiAoSXQgY291bGQgaWYgdGhlIERQSSB3ZXJlIHRvIGJlIGxvY2F0ZWQgb24gdGhl IG90aGVyIHNpZGUgb2YgdGhlIEdHU04sIHRoZSBHbiBpbnRlcmZhY2UpLg0KDQpJdCBpcyBjbGVh ciB0aGF0IHdlIHNob3VsZCB1cGRhdGUgdGhlIGRpYWdyYW0gdG8gc2hvdyB0aGUgUmFkaXVzIHRy YWZmaWMgZ28gdGhyb3VnaCB0aGUgRFBJIHNvIHRoYXQgdGhlIERQSSBjYW4gZXh0cmFjdCB0aGUg aW5mb3JtYXRpb24gYW5kIGFkZCBpdCB0byB0aGUgbWV0YWRhdGEgd2hpY2ggd2lsbCBiZSBjb2xs ZWN0ZWQgbGF0ZXIgYXMgdGhlIHN1YnNjcmliZXIgdHJhZmZpYyBnb2VzIHRocm91Z2guDQoNClNv bWV0aGluZyBsaWtlOg0KDQpDaGFpbiAwOiBHR1NOIHNlbmQgUmFkaXVzIHRyYWZmaWMgdG8gUmFk aXVzIHNlcnZlciB2aWEgdGhlIERQSSBzbyB0aGF0IHRoZSBEUEkgY2FuIGVzdGFibGlzaCB0aGUg SVAvTVNJU0ROIGNvcnJlbGF0aW9uDQoNCg0KW2NpZDppbWFnZTAwMS5qcGdAMDFDRjFDM0MuRTQx MUVGRjBdDQoNCg0KDQpOaWNvbGFzDQoNCg== --_000_2C5AD5728DB9B24189E3A93140E45786367C79szxeml522mbxchina_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Nicolas= ,

 = ;

Do you mea= n that DPI must support RADIUS proxy in this case?

 = ;

Ran

 = ;

=B7=A2=BC=FE=C8=CB: sfc [mailto:sfc-bounc= es@ietf.org] =B4=FA=B1=ED = Nicolas BOUTHORS
=B7=A2=CB=CD= =CA=B1=BC=E4: 2014=C4=EA1=D4=C2<= span lang=3D"EN-US">27=C8=D5 17:23
=CA=D5=BC=FE=C8=CB: sfc@ietf.org
=D6=F7=CC=E2: [sfc] Note on GI deployment scenario draft-liu-sfc-use-cases-00

 

Hello,

 

On Gi deploym= ents the GGSN connects to a Radius Function at PDP Context Setup Time. In m= ost case

this is used = to perform and MSISDN to IP address mapping, which is then used by the Gi s= ervice infrastructure

to decide how= to handle the IP flows for that particular subscriber.

 

This informat= ion cannot be derived by the DPI located after the GGSN. (It could if the D= PI were to be located on the other side of the GGSN, the Gn interface).

 

It is clear t= hat we should update the diagram to show the Radius traffic go through the = DPI so that the DPI can extract the information and add it to the metadata which will be collected later as the subscriber traffic go= es through. 

 

Something lik= e:

 

Chain 0: GGSN= send Radius traffic to Radius server via the DPI so that the DPI can estab= lish the IP/MSISDN correlation

 

 

 

 

 

Nicolas<= /o:p>

 

--_000_2C5AD5728DB9B24189E3A93140E45786367C79szxeml522mbxchina_-- --_004_2C5AD5728DB9B24189E3A93140E45786367C79szxeml522mbxchina_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=34434; creation-date="Tue, 28 Jan 2014 07:23:27 GMT"; modification-date="Tue, 28 Jan 2014 07:23:27 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/4RDSRXhpZgAATU0AKgAAAAgABAE7AAIAAAAEZGNoAIdpAAQA AAABAAAISpydAAEAAAAIAAAQwuocAAcAAAgMAAAAPgAAAAAc6gAAAAgAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFkAMAAgAAABQAABCY kAQAAgAAABQAABCskpEAAgAAAAM0OAAAkpIAAgAAAAM0OAAA6hwABwAACAwAAAiMAAAAABzqAAAA CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAMjAxNDowMToyNyAxMDoyMjowOQAyMDE0OjAxOjI3IDEwOjIyOjA5AAAAZABjAGgAAAD/4QsW aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49J++7vycgaWQ9J1c1 TTBNcENlaGlIenJlU3pOVGN6a2M5ZCc/Pg0KPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczpt ZXRhLyI+PHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJk Zi1zeW50YXgtbnMjIj48cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0idXVpZDpmYWY1YmRkNS1i YTNkLTExZGEtYWQzMS1kMzNkNzUxODJmMWIiIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcvZGMv ZWxlbWVudHMvMS4xLyIvPjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSJ1dWlkOmZhZjViZGQ1 LWJhM2QtMTFkYS1hZDMxLWQzM2Q3NTE4MmYxYiIgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUu Y29tL3hhcC8xLjAvIj48eG1wOkNyZWF0ZURhdGU+MjAxNC0wMS0yN1QxMDoyMjowOS40NzU8L3ht cDpDcmVhdGVEYXRlPjwvcmRmOkRlc2NyaXB0aW9uPjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0 PSJ1dWlkOmZhZjViZGQ1LWJhM2QtMTFkYS1hZDMxLWQzM2Q3NTE4MmYxYiIgeG1sbnM6ZGM9Imh0 dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIj48ZGM6Y3JlYXRvcj48cmRmOlNlcSB4bWxu czpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPjxyZGY6 bGk+ZGNoPC9yZGY6bGk+PC9yZGY6U2VxPg0KCQkJPC9kYzpjcmVhdG9yPjwvcmRmOkRlc2NyaXB0 aW9uPjwvcmRmOlJERj48L3g6eG1wbWV0YT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgPD94cGFja2V0IGVuZD0ndyc/Pv/bAEMABwUFBgUEBwYF BggHBwgKEQsKCQkKFQ8QDBEYFRoZGBUYFxseJyEbHSUdFxgiLiIlKCkrLCsaIC8zLyoyJyorKv/b AEMBBwgICgkKFAsLFCocGBwqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKv/AABEIARoCPAMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUG BwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR 8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5 eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj 5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQAC AQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXx FxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqS k5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T1 9vf4+fr/2gAMAwEAAhEDEQA/APn6iiiv0k5AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAop0aeZIqblXcQNzHAHua6TxN4Gv/AAtHYtqNzaBrxEZU E6MRnOT8jN8o+X5jjO7jODjmqYqhSqxozklKV7Lq7b29ASbTfY5mium8TeBr/wALR2Lajc2ga8RG VBOjEZzk/IzfKPl+Y4zu4zg4PE3ga/8AC0di2o3NoGvERlQToxGc5PyM3yj5fmOM7uM4OMKeZ4Kr yclRPnvy+dt7enUpwkr3WxzNFdN4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHB4m8DX /haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHBTzPBVeTkqJ89+Xztvb06g4SV7rY5mium8TeBr /wALR2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg4PE3ga/8AC0di2o3NoGvERlQToxGc5PyM3yj5 fmOM7uM4OCnmeCq8nJUT578vnbe3p1Bwkr3WxzNFdN4m8DX/AIWjsW1G5tA14iMqCdGIznJ+Rm+U fL8xxndxnBweJvA1/wCFo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcFPM8FV5OSonz35fO29vT qDhJXutjmaK6bxN4Gv8AwtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODg8TeBr/AMLR2Lajc2ga 8RGVBOjEZzk/IzfKPl+Y4zu4zg4KeZ4KryclRPnvy+dt7enUHCSvdbHM0V03ibwNf+Fo7FtRubQN eIjKgnRiM5yfkZvlHy/McZ3cZwcHibwNf+Fo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcFPM8F V5OSonz35fO29vTqDhJXutjmaK6bxN4Gv/C0di2o3NoGvERlQToxGc5PyM3yj5fmOM7uM4ODxN4G v/C0di2o3NoGvERlQToxGc5PyM3yj5fmOM7uM4OCnmeCq8nJUT578vnbe3p1Bwkr3WxzNFdN4m8D X/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHB4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vz HGd3GcHBTzPBVeTkqJ89+Xztvb06g4SV7rY5mium8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8o+X5 jjO7jODg8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODgp5ngqvJyVE+e/L523t6dQcJK 91sczRXTeJvA1/4WjsW1G5tA14iMqCdGIznJ+Rm+UfL8xxndxnBweJvA1/4WjsW1G5tA14iMqCdG IznJ+Rm+UfL8xxndxnBwU8zwVXk5KifPfl87b29OoOEle62OZorpvE3ga/8AC0di2o3NoGvERlQT oxGc5PyM3yj5fmOM7uM4ODxN4Gv/AAtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODgp5ngqvJyV E+e/L523t6dQcJK91sczRXTeJvA1/wCFo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcHibwNf8A haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHBTzPBVeTkqJ89+Xztvb06g4SV7rY5mium8TeBr/ AMLR2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg4PE3ga/wDC0di2o3NoGvERlQToxGc5PyM3yj5f mOM7uM4OCnmeCq8nJUT578vnbe3p1Bwkr3WxzNFdN4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8v zHGd3GcHB4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHBTzPBVeTkqJ89+Xztvb06g4S V7rY5mium8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODg8TeBr/wtHYtqNzaBrxEZUE6 MRnOT8jN8o+X5jjO7jODgp5ngqvJyVE+e/L523t6dQcJK91sczRXTeJvA1/4WjsW1G5tA14iMqCd GIznJ+Rm+UfL8xxndxnBweJvA1/4WjsW1G5tA14iMqCdGIznJ+Rm+UfL8xxndxnBwU8zwVXk5Kif Pfl87b29OoOEle62OZorpvE3ga/8LR2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg4b4p8EX/AISt 7OXUZ7YtdRq6xJOjtyCTgKzZUfL8xxncMZwcFLMsHWdNU6ifPfl87b29OockuxzdFFFegSFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAVPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelRRp5kipuVdxA3McAe5rovFPgi/8JW9n LqM9sWuo1dYknR25BJwFZsqPl+Y4zuGM4OOWpiMPCtClUkueV+VdXbe36jSbvYwri+u7wYu7qace Y0uJZC3ztjc3Pc7Rk98D0ouL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKK3VOCtZbCJ7i+u7wYu 7qaceY0uJZC3ztjc3Pc7Rk98D0ouL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKFTgrWWwE9xfX d4MXd1NOPMaXEshb52xubnudoye+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUFFCpwVrLYC e4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qFFDSKr MEBIBZs4X3OOa1fEOkWukXFqLC/a/t7m3E6TNB5WfnZeFJJxlMgnBwRkA8Vk5UYVI07au9tPv1tZ fqPV3KFxfXd4MXd1NOPMaXEshb52xubnudoye+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ74HpU FFaqnBWsthE9xfXd4MXd1NOPMaXEshb52xubnudoye+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ 74HpUFFCpwVrLYCe4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3P c7Rk98D0qCrd7p0thFZyTMjC8txcR7SeFLMuDx1yp/SptTi4xsk9bfrYNWR3F9d3gxd3U048xpcS yFvnbG5ue52jJ74HpRcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelQUVSpwVrLYCe4vru8GLu6mnH mNLiWQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qCihU4K1lsBPcX13eDF3 dTTjzGlxLIW+dsbm57naMnvgelFxfXd4MXd1NOPMaXEshb52xubnudoye+B6VBRQqcFay2AnuL67 vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSi4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KkvdOlsIrOSZ kYXluLiPaTwpZlweOuVP6VUqYKnJKUErLb9Q1J7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0ouL6 7vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKpU4K1lsBPcX13eDF3dTTjzGlxLIW+dsbm57naMnvge lFxfXd4MXd1NOPMaXEshb52xubnudoye+B6VBRQqcFay2AnuL67vBi7uppx5jS4lkLfO2Nzc9ztG T3wPSi4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KgooVOCtZbAT3F9d3gxd3U048xpcSyFvnbG5u e52jJ74HpRcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelQUUKnBWstgJ7i+u7wYu7qaceY0uJZC3z tjc3Pc7Rk98D0ouL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKFTgrWWwE9xfXd4MXd1NOPMaXE shb52xubnudoye+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUUaeZIqblXcQNzHAHua6LxT4 Iv8Awlb2cuoz2xa6jV1iSdHbkEnAVmyo+X5jjO4Yzg4551sNSqwoyaUpX5V1dt7fqNJu9jm6KKK6 xBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFT3F9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUUaeZIqblXcQNzHAHua6LxT4 Iv8Awlb2cuoz2xa6jV1iSdHbkEnAVmyo+X5jjO4Yzg45amIw8K0KVSS55X5V1dt7fqNJu9jm6KKK 6hBRVu906Wwis5JmRheW4uI9pPClmXB465U/pVSpjOM1zRegBRRRVAOjKCVDMrNGGG5VbaSO4Bwc H3wa29f1jSNUsrGLTtMvbSWziECvPfpMrRhnblREnzZfrnGB071hUVhOhCdSNSV7x21a/BOz+YJ2 CiiitwCiinwxrLcRxvKkKuwVpZASqAn7x2gnA68An2NJuyuAtvcTWlxHcWsskM0TB45Y2KsjDkEE cg+9b+reOtf1a3sIptX1LFpGmd97I3mSq7MsvXhhkAHkjaOaztY0C/0OSP7YiPBPuNvdwOJIbgA4 JRxw2MjI6jOCAeKtaX4b+2a7o1he3XkR6sqtHLDH5rJuZkUFSVydy+vQ59q82s8DUjHFVEpWTadr 6Le1r39ClzJtIiu/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIou/FniO/WJb7X9UuRDKs0Qmv ZH2SL91xk8MOxHIrTu/CVjYaK+o3t/fQIXt3t0exjJnt5txWQYmOG2xyHYfQDPORB4m8M2nh+8tR DqUt3ZysY5pDaiOSCRQpkjKbyCyh1/iAJJHbNc9Ktlk5xhTir629x9Em7O1tn8ynz2uynd+LPEd+ sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWn4h8J WGkrqy6dqtzeTaRdLb3Sz2QgUkllyjCR88r0IU457Gue03T5tV1S2sLXb51zKsSbzhQScZJ7CtqH 9n1aXtqcFyx/u2tpfZpNaO4pc8XZsvXfizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkUXPi7xJe iIXniDVbgQyiaLzb2RvLcdHGTwwycEc1raf4a8M6pqVtZWPie6aae6W2CvpO0vu4Dp+9IK5x94qe enaodR8J22neHp9SkvLtHzA9pDNaIouIZt5RyyyttOI5CVwcYHPPGEa+WKcafIlLSydNr4nbS8V1 3/Edp9/xK+u+NNa1/T7SzvtSv5YIYRHLHNePIszhmbzCDxnDAc5+71rAq3e6dLYRWckzIwvLcXEe 0nhSzLg8dcqf0qpXp4WlQo0lHDpKPkQ23a4UUUV0iCiiigAooooAKKKKACiird7p0thFZyTMjC8t xcR7SeFLMuDx1yp/Spc4pqLerAqVPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelRRp5kipuVdxA3 McAe5rovFPgi/wDCVvZy6jPbFrqNXWJJ0duQScBWbKj5fmOM7hjODjnqYjDwrQpVJLnlflXV23t+ o0m72ObooorqEFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAVPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelRRp5kipuVdxA 3McAe5rovFPgi/8ACVvZy6jPbFrqNXWJJ0duQScBWbKj5fmOM7hjODjlqYjDwrQpVJLnlflXV23t +o0m72ObqS3uJrS4juLWWSGaJg8csbFWRhyCCOQfeo6K6WlJWYjo9W8da/q1vYRTavqWLSNM772R vMlV2ZZevDDIAPJG0c1Tu/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIqHVtJ/suPT287zfttm t1jZt2bmYbepz93rx1rOrgw+EwXs4ulTjbW2n3lOUur6fga934s8R36xLfa/qlyIZVmiE17I+yRf uuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZFFbLB4ZWtTjptotBc0u5r3fizx HfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkUXfizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkVkUU LB4ZWtTjptotA5pdzXu/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIou/FniO/WJb7X9UuRDKs 0QmvZH2SL91xk8MOxHIrIooWDwytanHTbRaBzS7mvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4Yd iORRd+J9Z1ZYoNf1jVNSsllWR7ea9ds49N24BsEgHBxnoelZFFCweGjblppW2skrenb5BzS7m9ee KrkRxWnh9ZNFsIXEiQ207b5JAQRLLJwXcYGDgKuPlVcnNyf4ha5d3WjyXl/f3MWnNE7wT3rutw8c pcOwPfkDPJ4rlat3unS2EVnJMyMLy3FxHtJ4Usy4PHXKn9K55ZfgrxjKCvra++u+u7fne4cz1t2/ A62f4iQagsMOq6N59rBqgvY4YrkR4iVSI7fJQ/Ku4845BPTORBqnji11zS7yz1bS5ZfOvhdxSwSW 1u6cENvMduPMZgTljjnbxwc8dRWUclwEJKUadmttXprfTXS/W260ehXtJdzpvGfjKfxZqDTCTU4r ZpGl+x3eom5iick/6sbFCAA4AwfrWHpeoS6Tq1rqFuFaW2lWVVccMQc4Psaq0V20cHQoUFhqcbQt a3l+ZMpOTuztIfHkOm6fBY6Ja6pDaR3sN19lu9V8+FRHIZNqII025bBJOenrzUOs/EC71XTfssNu bKSLUvtlrPDNhreNVIjiXAH3NxIYY6niuRorkjk+BjP2ip63vdtvXzu9fmV7ST/r+u50ereOtf1a 3sIptX1LFpGmd97I3mSq7MsvXhhkAHkjaOap3fizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkVT vdOlsIrOSZkYXluLiPaTwpZlweOuVP6VUrajgsFGC9lTjZXtovmLml36fga934s8R36xLfa/qlyI ZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZFFarB4ZWtTjpto tBc0u5r3fizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkUXfizxHfrEt9r+qXIhlWaITXsj7JF+6 4yeGHYjkVkUULB4ZWtTjptotA5pdzXu/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIou/FniO/ WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIrIooWDwytanHTbRaBzS7mvd+LPEd+sS32v6pciGVZohNe yPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWRRQsHhla1OOm2i0Dml3Ne 58XeJL0RC88QarcCGUTRebeyN5bjo4yeGGTgjmrGu+NNa1/T7SzvtSv5YIYRHLHNePIszhmbzCDx nDAc5+71rArR1bSf7Lj09vO837bZrdY2bdm5mG3qc/d68daxeFwUKsP3cVJX5dPvGpS116fgZ1T3 F9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUUaeZIqblXcQNzHAHua6LxT4Iv/AAlb2cuoz2xa6jV1 iSdHbkEnAVmyo+X5jjO4Yzg42qYjDwrQpVJLnlflXV23t+okm72ObooorqEFFFFABRRWpe6ZDYeH 7C4naT7dfM0qRZG1LcHarEYzlmD456KDzuGM51IwlGL3k7L7r/oCVzLp8M0ttcRz28jxTRMHjkjY qyMDkEEdCD3rRvdMhsPD9hcTtJ9uvmaVIsjaluDtViMZyzB8c9FB53DGXShUhWi2tVqvu0YNWNe7 8WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecii78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Eci siislg8MrWpx020Wg+aXc17vxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKLvxZ4jv1iW+1/VL kQyrNEJr2R9ki/dcZPDDsRyKyKKFg8MrWpx020Wgc0u5r3fizxHfrEt9r+qXIhlWaITXsj7JF+64 yeGHYjkVHqPibXtYthbatreo30AYOIrm7kkUMMgHDEjPJ596zKKccJhoNONOKttotPQOaXcKKltj ALuE3iyNbiRfNWIgOUz8wUkEA4zjIrQ1TTING8TNaXTST2KSq6yQsA01u2GV1JGAWQgjI4zyKuVa MZ8nW1/W2/6feK2lzKorQ13S/wCx9auLNZPNhUh4Jh0liYBo3H+8pU/jWfV06kakFOOz1Q2rOwUU UVYgooooAKKKKACiird7p0thFZyTMjC8txcR7SeFLMuDx1yp/Spc4pqLerAqUUUVQBRRRQAUVbvd OlsIrOSZkYXluLiPaTwpZlweOuVP6VUqYzjNc0XoAUUUVQBRRVu906Wwis5JmRheW4uI9pPClmXB 465U/pUucU1FvVgVKnuL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKbim02tgCiird7p0thFZyT MjC8txcR7SeFLMuDx1yp/Sk5xTUW9WBe8Q39tfQ6MtrJ5httNjgl+Uja4dyRz14I5HFY1aOraT/Z cent53m/bbNbrGzbs3Mw29Tn7vXjrWdWGFVNUYqk7xG76ei/IKKt3unS2EVnJMyMLy3FxHtJ4Usy 4PHXKn9KqVvGcZrmi9BBRRRVAFFFFABRRRQBJb3E1pcR3FrLJDNEweOWNirIw5BBHIPvW/q3jrX9 Wt7CKbV9SxaRpnfeyN5kquzLL14YZAB5I2jmucormq4WhWnGpUgm47NrYabWxr3fizxHfrEt9r+q XIhlWaITXsj7JF+64yeGHYjkUXfizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkVTvdOlsIrOSZk YXluLiPaTwpZlweOuVP6VUqKeFwjSlCnGy20XzHzS7mvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ 4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWRVu906Wwis5JmRheW4uI9pPClmXB46 5U/pR9VwkHGPs4p620XzsHNJ9S5d+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRc+LvEl6Ihe eINVuBDKJovNvZG8tx0cZPDDJwRzWRRVLBYVWtTjptohc0u5v67401rX9PtLO+1K/lghhEcsc148 izOGZvMIPGcMBzn7vWsCiiroYelh4ezoxUV2QNt7hRRVu906Wwis5JmRheW4uI9pPClmXB465U/p WrnFNRb1YipRRRVAFFFFABRRRQAVs+Ib+2vodGW1k8w22mxwS/KRtcO5I568Ecjis2xsptRvobO1 8vzpm2IJJVjUn3ZiAPxNaV74U1bT7G8u7pLVYbG4FtPsvoHZZT/CFVyWPXoD91v7pxx1qmHVeHtJ pSWyutb6bb+nmNX1t/XX9DGqe4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KijTzJFTcq7iBuY4A9 zXReKfBF/wCErezl1Ge2LXUausSTo7cgk4Cs2VHy/McZ3DGcHFVMRh4VoUqklzyvyrq7b2/UEm72 ObooorqEFFFFAEtsIDdwi8aRbcyL5rRKC4TPzFQSATjOMmtDVNTg1nxM13dLJBYvKqLHCoLQ264V UUE4JVAAMnnHJqPVtJ/suPT287zfttmt1jZt2bmYbepz93rx1rOrmjGnXtWi+jSf5/kvuHqlbuaG u6p/bGtXF4sflQsQkEI6RRKAsaD/AHVCj8Kz6KK2pwjTgoR2WiBu7uFFFFWIKKKKACiiigArUvdT hv8Aw/YW86yfbrFmiSTA2vbk7lUnOcqxfHHRgONozl0VnOnGcoye8Xdfdb9QTsal7qcN/wCH7C3n WT7dYs0SSYG17cncqk5zlWL446MBxtGcuitHVtJ/suPT287zfttmt1jZt2bmYbepz93rx1rOHs6D VJdbtfm/zHqzOoooroEFFFFABRRRQBJb3E1pcR3FrLJDNEweOWNirIw5BBHIPvW/q3jrX9Wt7CKb V9SxaRpnfeyN5kquzLL14YZAB5I2jmucrak8NTHUNFsrWZZZtWgjlTeNixl3ZcE5PA25z+lcOJp4 R1I1K8VzK9m1sktRxbV7DLvxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKLvxZ4jv1iW+1/VLk QyrNEJr2R9ki/dcZPDDsRyKujw9ot/JFa6Br8t3fy3KW8cFzYGBZNxx5iuHYbR/tbT7dcQ3ek+Hv s5OleIpJ7gTrEIrqwMCuCceYHDsNo/2tp6cdcckZ5fdJUrNf9O5K1/8At3RPu7J69mU+bq/xILvx Z4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKLnxd4kvRELzxBqtwIZRNF5t7I3luOjjJ4YZOCOa3 9T8B2Wl6hZWl3qOqW8t1fC1UXOjGISL0M0TGTbIgYoOoOGBxVLWPCNto2k6jcTajNJcWl3FbxRpa r5U6SBnSQSeZkAojEjaSDgepGNHFZTUcFTitdvcfV2093a+je3cbU9blXXfGmta/p9pZ32pX8sEM IjljmvHkWZwzN5hB4zhgOc/d61gVbvdOlsIrOSZkYXluLiPaTwpZlweOuVP6VUr1sLSoUaSjh0lH yIbbtcKKKfDGstxHG8qQq7BWlkBKoCfvHaCcDrwCfY10N2VxC29xNaXEdxayyQzRMHjljYqyMOQQ RyD71v6t461/Vrewim1fUsWkaZ33sjeZKrsyy9eGGQAeSNo5rO1jQL/Q5I/tiI8E+4293A4khuAD glHHDYyMjqM4IB4qa50SKzu9HjuLp/K1G3jnd0hBaIM7KQFLDcRtz1GfavOqfUazhWmlJ2dna+29 v6/Ed3G/p+Al34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+ yRfuuMnhh2I5FaWseFNNsZNRFhq9zdjSLryNQWWxWJ0TzPL8yMCVg43cYJU/MvqSH674S03S31NL PV7u5bSbtba882wWIYLMu6MiVtxyp4O3I+hxywr5W3FRgvL3GrXt/d0vzLe17o0caivf8zKufF3i S9EQvPEGq3AhlE0Xm3sjeW46OMnhhk4I5qxrvjTWtf0+0s77Ur+WCGERyxzXjyLM4Zm8wg8ZwwHO fu9aPEeiaVo9rYPp+p3l5LewLcqk9ikKrGSw5Ilf5sr0xjB69qo6tpP9lx6e3neb9ts1usbNuzcz Db1Ofu9eOtbUYZfVdOpTgr68vu29dGlYm809+n4FjxDf219Doy2snmG202OCX5SNrh3JHPXgjkcV lW9xNaXEdxayyQzRMHjljYqyMOQQRyD71an0t7V9P+0zwxR30SzLIdxWNC7JlsAnjaTwDx0yeKk1 jQL/AEOSP7YiPBPuNvdwOJIbgA4JRxw2MjI6jOCAeK6aMsPCEaCle97X69/XzJ1av5I0dW8da/q1 vYRTavqWLSNM772RvMlV2ZZevDDIAPJG0c1Tu/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIps Ph29uNQ0qzhMTS6oivB8xwoZ2T5jjjBUk9eK0l8J22qgr4U1T+05o5lhljuYVtM7jhHRnkIZS3y/ NsbLL8vPHF/wl4ZKPLFJa35dFd9Xa0bu61auVeTW/T8DPu/FniO/WJb7X9UuRDKs0QmvZH2SL91x k8MOxHIou/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIqW+8Ha1ppUXsNvHmcW7kXsDCCQ5wsu HPlHg/f2/dPoaZrnha/8P3ptr2fT5HExhzb6hDL8w7lQ25B7sBWlOWVylGNPkb1tbl+dv1G/aK97 jbvxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKLvxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDs RyKsXHhDUE1yw0i1Ec15fQLJEpuYNjkkjCSLIyMPlwOQSeMdMt1LwXrmk232i/toY4t6puW8hfqS A3yufl3AqW+6GBUnIIpRnlV4Ri6d3rFe7ez7Lz/EXv67kN34s8R36xLfa/qlyIZVmiE17I+yRfuu Mnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FJq3h650rULOybEk11Cki7ZInRixIG 143ZWXI65H0FT6j4L1zS7eGa5t7d0nufskf2a9huGabum2N2ORxnjjI9RVReWLktyK/w/Cr97f8A AD39SG78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecii58XeJL0RC88QarcCGUTRebeyN5bjo4y eGGTgjmlv/C2q6asT3SWpjlm+z+bDewzRxyf3XdHKxnqfmI4BPY4fq3g/W9DtTcanaxxRgK3y3UT sUb7sgVWJKHoHA2k8ZzRF5W3BR9nrfl+HXvb9bB7/mSa7401rX9PtLO+1K/lghhEcsc148izOGZv MIPGcMBzn7vWsCrd7p0thFZyTMjC8txcR7SeFLMuDx1yp/Sq8May3EcbypCrsFaWQEqgJ+8doJwO vAJ9jXXh6dChStQilHXZfeS23a4tvcTWlxHcWsskM0TB45Y2KsjDkEEcg+9b+reOtf1a3sIptX1L FpGmd97I3mSq7MsvXhhkAHkjaOaztY0C/wBDkj+2IjwT7jb3cDiSG4AOCUccNjIyOozggHirEvhq b7fo1nazLLNq0Ecqbl2CMu7LgnJ4G3Of0rnqPA1nCvPllo7PfRb6jXMm0uwy78WeI79Ylvtf1S5E MqzRCa9kfZIv3XGTww7Ecii78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecipr3SdBFpIdJ8QTX l2kgjW3l08w+dkgbkbew29T8209Pl5OK+oeGdU01YWmhhmSeUwxvZ3MVypk4+TMTMA3I+U81FP8A s98qUIxetk48r87KST9bDfP3HXfizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkUXfizxHfrEt9r +qXIhlWaITXsj7JF+64yeGHYjkVfXwLqlvJFJqqpBZfaktbia2nhuXt5GOArRrJkN1+VsHg+lQa3 4M1fRLzyJoFmD3RtY/JljkcyfwqyIxMbEchWwevoazp1cplNQpuF9bW5fnZ7eqWvV7h79m3f+v6Z XufF3iS9EQvPEGq3AhlE0Xm3sjeW46OMnhhk4I5qxrvjTWtf0+0s77Ur+WCGERyxzXjyLM4Zm8wg 8ZwwHOfu9aq6r4a1PRrdbi9jgaEyGIy213FcKj4zsYxswVsZIDYJwcdDVW906Wwis5JmRheW4uI9 pPClmXB465U/pW1Ojl83CpSjF2vytW+drCvNN37fgVKKKK9MkKKKKACiiigArc8QeJ5det7SJ4Fg 8vMtwytk3NwwAeZvchV49cnvWHVu906Wwis5JmRheW4uI9pPClmXB465U/pXPUp0ZVYTmveV7fdq NN7IqVPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelQUVu4ptNrYQUUUUwCinwxrLcRxvKkKuwVpZ ASqAn7x2gnA68An2NX9Y0C/0OSP7YiPBPuNvdwOJIbgA4JRxw2MjI6jOCAeKylWpxmqbdm9l39O4 WZP4hv7a+h0ZbWTzDbabHBL8pG1w7kjnrwRyOKxqt3unS2EVnJMyMLy3FxHtJ4Usy4PHXKn9KqVO HhCFJRpu6B9PRfkFFOjCGVBMzLGWG5lXcQO5AyMn2yK6TVfDFhBJpdvoup3N7d6nGksSXdrFaoqM WAy5mYBsr0OBz17VNXFUqM1Co7Xv0dtN7u1l82hpNnM0Vt6j4P1nSZIkv4baIyT/AGYkXsDCKX+5 IQ5ER/39vQ+ho1nwlqWiaiLKdrK5nac26JZXsU7M+cY2Ixdcn+8BURx2Fm4qNSLvdrVa23t6DcZL dGJRWxf+FtV01YnuktTHLN9n82G9hmjjk/uu6OVjPU/MRwCexxaufAfiGzkiS6tbeJpmQRhr6D5g /wBx/v8A+rJ4D/dJ4znik8wwaSbqx1vb3lrbe2vTqLll2Odorb1LwhrekyRpeWiGSSf7MI7e4inZ Zv8AnmyxsxR/9lsHg+hpt74U1bT/ACTcJaGOWb7OJor+CWOOT+67q5WM9T85HAJ7HFRx2Fkk41Yu +2q1tvbXoDjJboxqK2Nf8MX3hu6eC/msJWSVoj9lvopjkeqqxZf+BAVj1tRrU68FUpSUovqgaadm FbPiG/tr6HRltZPMNtpscEvykbXDuSOevBHI4rGrR1bSf7Lj09vO837bZrdY2bdm5mG3qc/d68da zqKm60HJ+9rb9QV9bdv1RnUUUV0iCiiigAooooAK6S+1+ODUPDl9prrLNpllCrq6kASJI7FT0yME dPWubq3e6dLYRWckzIwvLcXEe0nhSzLg8dcqf0rlrUqVScfaeat3utfwBdbdv1R1Efj5dM0yOx8P 2+pW9ul1HcC3vdU+0QKEcvtWMRptBY5Jyc49eajfxnYxaKuj2dhqn9lPdRTT2N3q5liMauXaNAsa bNxPLcnv15rkKK5P7HwV78mt7/FLfvvq10e66F+0kdXD4p0iwWCDTNHvorNdQivpoZtSWQs0YYIq HyRs++ckhiQB6U3UPGsk+kPYWFvNabNRS9tLk3O6a3CiT93uVVyA8rMCACCT1zxy1FWsrwnNzuN3 5uT++7d/n002Fzv+v68zo9W8da/q1vYRTavqWLSNM772RvMlV2ZZevDDIAPJG0c1Tu/FniO/WJb7 X9UuRDKs0QmvZH2SL91xk8MOxHIqne6dLYRWckzIwvLcXEe0nhSzLg8dcqf0qpV0cFgowXsqcbK9 tF8w5pd+n4Gvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+J9Z1ZYoNf1jVNSsllWR7ea9 ds49N24BsEgHBxnoelZFPhjWW4jjeVIVdgrSyAlUBP3jtBOB14BPsa0+qYaCTVNK21lqvS2v3C5p dzX1TxE91ZDTNJt/7L0kcm0jlZjO39+ZuPMbgdgo/hVcnM2qarYzXPh+Rd9zHZWMUdxGhMbblkdi oYqQDgjnBHPeqOsaBf6HJH9sRHgn3G3u4HEkNwAcEo44bGRkdRnBAPFQXunS2EVnJMyMLy3FxHtJ 4Usy4PHXKn9K56dHCTjB03o72s977tvdvzvcHfVPt+Ghvav4q0y+k1NrHSbu1OsXQmvzLfrKWTzD IY48RLsBYg5O77q++U8X+MpPFeqCaRtVWyaYzNY3Op+ekZJPEXyAIMHA4OP0rl6KqnlmEpzjUjHW N7NtvdJPd9klfdW0KdSTvfqb/iPW9K1i1sE0/TLyzlsoFt1ee+SZWjBY8gRJ82W65xgdO9N1rV0k fQptLupEnsdPijaSPcjRSq7ng8cjIORWFVu906Wwis5JmRheW4uI9pPClmXB465U/pVRwmHpckF0 vZNt3vvvd/iLmbfy/DT/AIBsat411XXbewtNXv8AUrmzgjRLiF752+0EOzF/mBAbDYBIbGB16VFe eKrkRxWnh9ZNFsIXEiQ207b5JAQRLLJwXcYGDgKuPlVcnNLVtJ/suPT287zfttmt1jZt2bmYbepz 93rx1rOqKGDwTpxdKC5Vey6ettr+drg5S69jqrn4i+IrmXS5H1O+k+wKhaO4u3ljnkV2beyk4PDB ec8DrVjR/EWi2+s2Uen2X9i2st9FcX1xc3DXOI43DiNAse5VyOhDsSFy2Ac8xe6dLYRWckzIwvLc XEe0nhSzLg8dcqf0qpWf9l4KpS5aceVNNe7p36bNp6q6dmDk2tex1fibWdGEmqWnh6CQi/uFlmuz dtLG6gl9savDG6jcwzu3H5cZPU1Na13SNXujdf2JNDc3NwJ72U324t/eWIbAIwSSfmEhHy4PBzz9 FbUsvoU1G17rrzSu7pJ3112XkraWHKo5O52a+MNCi1jRNQg0HURJo4jWNX1VCJFQswBxbjncwyfQ YxzkQS+LdLn0lNOl0e88lbZbXK6goYok7Sqc+TjOHKnjng4HSuTorJZRg007PS1vel0ba+13bFzv 9P6+46PXdd0TVYdPW20i/t2sokt8y6ikgeJSxIwIVwx3fezgelXNW8Z2E95YXuiaRcafc6dPFJaL LfCaG3jjJPloixpwzEMzMWYkdckk8hRVrK8LaKs7Rva8pPffd638w5mdZr/jGLXoI4bhvEUkIuFl kgu9dNxFtGchFaLKtg4DEtjuDVPXdfsb/UodR0Wzv9MvYvLAlbUFkx5aKqldsSFW+UHOTz6Vz9FV Ry3C0eX2cWrXW8ra73V7O9utwc5Pc6PVvHWv6tb2EU2r6li0jTO+9kbzJVdmWXrwwyADyRtHNU7v xPrOrLFBr+sapqVksqyPbzXrtnHpu3ANgkA4OM9D0qne6dLYRWckzIwvLcXEe0nhSzLg8dcqf0qp To4PBxgvZQSSvay272e6Dml36fgbWqeInurIaZpNv/Zekjk2kcrMZ2/vzNx5jcDsFH8Krk5s3+vp BfeHb7SpFkn02yhVg6HaJFkdtpBxkYI6cc1zlW73TpbCKzkmZGF5bi4j2k8KWZcHjrlT+lH1PDRc YW76d7rW99W/Nu4ru79P1Rrf214ftbqG50zw24kS5jnZb6+M8YVWyY1UInynod+/gfUnX1X4i/br OzWODVJbuyv0voLnU9V+1bXX+Hb5agLwOFx368AcPRWc8pwlScZzi247Nyk/zf4MfPJbHRDWfDkF 3FPZeHrqMrcJM/manvKKpzsjxEAoJxy4c4AxzkmyfGFrb+fNpum3MF42rJqcEsl4rrGyEkKVEalh 8zc5Hb0OefvdOlsIrOSZkYXluLiPaTwpZlweOuVP6VUoWX4SquZ3kvOUn+bDmf8AXp/kzrde8cTa rDH9lu/EUM0dws8f2vXWuYomGcFFMasCM8NuJAz1zmqOu+NNa1/T7SzvtSv5YIYRHLHNePIszhmb zCDxnDAc5+71rAq3e6dLYRWckzIwvLcXEe0nhSzLg8dcqf0op5fgaDgowV1flvq/PV3Y+eTe/T8C pRRRXpkBRRRQAUUUUASW9xNaXEdxayyQzRMHjljYqyMOQQRyD71v6t461/Vrewim1fUsWkaZ33sj eZKrsyy9eGGQAeSNo5rno4zLKkalQzsFBZgo59SeAPc1ra1o1lp1vHJp+sW+o7X8m4VAEMcoGTsB JMkZ5AkAHIOQMru4a9PCzrw9rFOettL2+drLyvv0HG6vYS78WeI79Ylvtf1S5EMqzRCa9kfZIv3X GTww7Ecii78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7EcisqNPMkVNyruIG5jgD3NdF4p8EX/hK 3s5dRnti11GrrEk6O3IJOArNlR8vzHGdwxnBxnKGX0asKMoxUpX5VZX87afeNOcr2KV34s8R36xL fa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZFFdCweG VrU46baLQXNLua934n1nVlig1/WNU1KyWVZHt5r12zj03bgGwSAcHGeh6VPeeKrkRxWnh9ZNFsIX EiQ207b5JAQRLLJwXcYGDgKuPlVcnODRU/UcNp7istl09bbX87XDmZv67401rX9PtLO+1K/lghhE csc148izOGZvMIPGcMBzn7vWsCtHVtJ/suPT287zfttmt1jZt2bmYbepz93rx1rOqsJTw9Oilhkl HyVgbbtcdGUEqGZWaMMNyq20kdwDg4Pvg109/wCJdEurvR5oNG1CL+zFji2vqSP5saMzAcQDDZbr yMDp3rlqKK2EpV5KVS91dbtb6PZoV7X8zotT8Q6de6XqVrBpl1DLeagL1ZHvVdY+GG0qIhu++3OR 2445kv8AxXaSavDrOl6S1rqwvEvZbiW7Mq+YpzhECrtUtkkMXPQAjnPM0Vl/Z+G7Pr9qXW1766rR aPQpzb3/AK/q51mv+MYtegjhuG8RSQi4WWSC7103EW0ZyEVosq2DgMS2O4NQ6j4h0W816z1ODSL+ FoXi82N9RRxIsaqqhSIRtPyjJO7vxXM0VFPK8JTiowi0kmviltLfr/XQJTctzqz4wtbfz5tN025g vG1ZNTglkvFdY2QkhSojUsPmbnI7ehy3xL4w/wCEgsPs/m6+f3wl8q/1s3cC8HhUMYIIzwSxIGeu c1y1FEcrwkasaqj7y2d2/wA2P2kv6/rzN3xBrmm6y8tzbaO9tf3U3nXNxJdmUbsciNAqhVJJJDbz 0wRznCoorsoUIUKap072Xdt/m2yW29wrZ8Q39tfQ6MtrJ5httNjgl+Uja4dyRz14I5HFY1aOraT/ AGXHp7ed5v22zW6xs27NzMNvU5+71461FRU3Wg5P3tbfqCvrbt+qM6iiiukQUUUUAFFFFAElvcTW lxHcWsskM0TB45Y2KsjDkEEcg+9b+reOtf1a3sIptX1LFpGmd97I3mSq7MsvXhhkAHkjaOa5yiua rhaFacalSCbjs2thptbGvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pci GVZohNeyPskX7rjJ4YdiORWRRSWDwytanHTbRaBzS7mvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ 4YdiORRc+LvEl6IheeINVuBDKJovNvZG8tx0cZPDDJwRzWRRQsFhVa1OOm2iDml3Oj1bx1r+rW9h FNq+pYtI0zvvZG8yVXZll68MMgA8kbRzVO78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecisiio p4DCU0lCnFW20XUfNLua934s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34n1nVlig1/WNU1K yWVZHt5r12zj03bgGwSAcHGeh6VkUVaweGjblppW2skrenb5C5pdzevPFVyI4rTw+smi2ELiRIba dt8kgIIllk4LuMDBwFXHyquTmXVvHWv6tb2EU2r6li0jTO+9kbzJVdmWXrwwyADyRtHNc5Wpe6ZD YeH7C4naT7dfM0qRZG1LcHarEYzlmD456KDzuGOeWDwVOcL005Xdr6u9rttvV+bf5jTlrYfd+LPE d+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWVGn mSKm5V3EDcxwB7mui8U+CL/wlb2cuoz2xa6jV1iSdHbkEnAVmyo+X5jjO4Yzg4JQy+jVhRlGKlK/ KrK/nbT7wTnK9ilc+LvEl6IheeINVuBDKJovNvZG8tx0cZPDDJwRzVjXfGmta/p9pZ32pX8sEMIj ljmvHkWZwzN5hB4zhgOc/d61gUVssDhVKM1TinHbRaBzS7mz4hv7a+h0ZbWTzDbabHBL8pG1w7kj nrwRyOKyre4mtLiO4tZZIZomDxyxsVZGHIII5B96u6tpP9lx6e3neb9ts1usbNuzczDb1Ofu9eOt Z1Vho0vYKMNY+YnfT0X5HR6t461/Vrewim1fUsWkaZ33sjeZKrsyy9eGGQAeSNo5qnd+LPEd+sS3 2v6pciGVZohNeyPskX7rjJ4YdiORWRRUU8BhKaShTirbaLqPml3Ne78WeI79Ylvtf1S5EMqzRCa9 kfZIv3XGTww7Ecii78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7EcisiirWDwytanHTbRaC5pdzX u/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIou/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxH IrIooWDwytanHTbRaBzS7mvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6p ciGVZohNeyPskX7rjJ4YdiORWRRQsHhla1OOm2i0Dml3Ne78WeI79Ylvtf1S5EMqzRCa9kfZIv3X GTww7Ecii58XeJL0RC88QarcCGUTRebeyN5bjo4yeGGTgjmsiihYLCq1qcdNtEHNLub+u+NNa1/T 7SzvtSv5YIYRHLHNePIszhmbzCDxnDAc5+71rAooq6GHpYeHs6MVFdkDbe5Jb3E1pcR3FrLJDNEw eOWNirIw5BBHIPvW/q3jrX9Wt7CKbV9SxaRpnfeyN5kquzLL14YZAB5I2jmucoqauFoVpxqVIJuO za2BNrY17vxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKLnxd4kvRELzxBqtwIZRNF5t7I3luO jjJ4YZOCOayKKSwWFVrU46baIOaXc6PVvHWv6tb2EU2r6li0jTO+9kbzJVdmWXrwwyADyRtHNU7v xZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKj1LRxpx0zddKVv7VLkuyECLczLg4ySBtzkD8Ks6 voum2ulRaho+rSX0LXL2zCe18hiyqrbkG5tyYYcnBGRlRkVxUqeXw9nGnTWt+X3dPPW2nzauVeT6 9PwIrnxd4kvRELzxBqtwIZRNF5t7I3luOjjJ4YZOCOasa7401rX9PtLO+1K/lghhEcsc148izOGZ vMIPGcMBzn7vWsCiutYHCqUZqnFOO2i0FzS7hRRRXYSFFFFABRRRQAUUVo6tpP8AZcent53m/bbN brGzbs3Mw29Tn7vXjrUSqRjJQb1e3yDczqnuL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoo08yRU 3Ku4gbmOAPc10XinwRf+Erezl1Ge2LXUausSTo7cgk4Cs2VHy/McZ3DGcHGFTEYeFaFKpJc8r8q6 u29v1Gk3exzdFFFdQgooooA2fEN/bX0OjLayeYbbTY4JflI2uHckc9eCORxWNUtsYBdwm8WRrcSL 5qxEBymfmCkggHGcZFaGqaZBo3iZrS6aSexSVXWSFgGmt2wyupIwCyEEZHGeRXJT5MOlQjd2Ta89 dfzX3j1av2sZVFaGu6X/AGPrVxZrJ5sKkPBMOksTANG4/wB5Sp/Gs+uinUjUgpx2eqBqzsFFFFWI KKKKACiiigAoorUvdMhsPD9hcTtJ9uvmaVIsjaluDtViMZyzB8c9FB53DGc6kYSjF7ydl91/0BK5 l1s+Ib+2vodGW1k8w22mxwS/KRtcO5I568Ecjior3TIbDw/YXE7Sfbr5mlSLI2pbg7VYjGcswfHP RQedwxl1jFU68o1l9m6/R/kPVfMKKKK6hBRRRQAUUUUAFFFFABRRRQAUUUUAFFS2ltJe3kNrAAZZ 5FjQE4yxOB/OtnWdAsrHT5brS9Skvltbv7HdeZa+SFkIYqU+ZtynY/JCngZUZrnniKVOpGnJ6vyf 4vZX6XtfoCTZg0UUV0AS2wgN3CLxpFtzIvmtEoLhM/MVBIBOM4yat67qn9sa1cXix+VCxCQQjpFE oCxoP91Qo/CpL3TIbDw/YXE7Sfbr5mlSLI2pbg7VYjGcswfHPRQedwxl1zU/Z1Z+2j0uvx1+9r8B 6pWCp7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qKNPMkVNyruIG5jgD3NdF4p8EX/hK3s5dRnti 11GrrEk6O3IJOArNlR8vzHGdwxnBwqmIw8K0KVSS55X5V1dt7fqCTd7HN0UUV1CNnxDf219Doy2s nmG202OCX5SNrh3JHPXgjkcVjVo6tpP9lx6e3neb9ts1usbNuzczDb1Ofu9eOtZ1c2FVNUYqk7xG 76ei/IKKKK6RBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRU9jZTajfQ2dr5fnTNsQSSrGpPuzEA fiamUowi5SdkgNnVdT065uNAZka8gs7GKK6hVjEWKyOWTcRxkEcgHrS+KvEVhr7QGwsLuwSDKxW7 3iSQQxnnZGixJt56kkk9SSear3vhTVtPsby7uktVhsbgW0+y+gdllP8ACFVyWPXoD91v7pxjV52H w+Em4VaUuZwuk1K6V9Xona+va9rFNyWj9Pu0CiiivTJCiiigAooooAKKKKACtnxDf219Doy2snmG 202OCX5SNrh3JHPXgjkcVjVo6tpP9lx6e3neb9ts1usbNuzczDb1Ofu9eOtc1RU3Wg5P3tbfqNX1 t2/VGdU9xfXd4MXd1NOPMaXEshb52xubnudoye+B6VFGnmSKm5V3EDcxwB7mui8U+CL/AMJW9nLq M9sWuo1dYknR25BJwFZsqPl+Y4zuGM4OFUxGHhWhSqSXPK/Kurtvb9QSbvY5uiiiuoQUUUUAFal7 qcN/4fsLedZPt1izRJJgbXtydyqTnOVYvjjowHG0Zy6KznTjOUZPeLuvut+oJ2NS91OG/wDD9hbz rJ9usWaJJMDa9uTuVSc5yrF8cdGA42jOXRRRTpxpR5Y7Xb+93Bu4UUUVoAUUUUAFFFFAEtsIDdwi 8aRbcyL5rRKC4TPzFQSATjOMmtDVNTg1nxM13dLJBYvKqLHCoLQ264VUUE4JVAAMnnHJrKorGVGM p8/W1vS+/wCn3BfSxoa7qn9sa1cXix+VCxCQQjpFEoCxoP8AdUKPwrPooq6cI04KEdloht3dwooo qxBRRRQAUUUUAFFFFABRRVu906Wwis5JmRheW4uI9pPClmXB465U/pUucU1FvVgVKKKKoCW1uZLO 7huYDtlhdZEOM4YHI/UVta14gsr6xltdK02axS6u/tlz510JtzgMFCYRNqje/ByeRzxWBRXPPD0q lSNSS1Xm/wAVs7dL3t0Gm0FS2wgN3CLxpFtzIvmtEoLhM/MVBIBOM4yaioreSumiTQ13VP7Y1q4v Fj8qFiEghHSKJQFjQf7qhR+FZ9W73TpbCKzkmZGF5bi4j2k8KWZcHjrlT+lVKzoqmqajT+FaL5aF Ntu4VPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelRRp5kipuVdxA3McAe5rovFPgi/8ACVvZy6jP bFrqNXWJJ0duQScBWbKj5fmOM7hjODjKpiMPCtClUkueV+VdXbe36gk3exzdFFFdQjZ8Q39tfQ6M trJ5httNjgl+Uja4dyRz14I5HFY1aOraT/Zcent53m/bbNbrGzbs3Mw29Tn7vXjrWdXNhVTVGKpO 8Ru+novyCiiiukQUUU6NQ8qIzrGrMAXbOF9zgE4+gNDdlcBtFdH4g8LRaPo9rqNtd3U0NxIUQ3di bbzxtBEsOWJkj/2iFIyvHPHOVhh8RSxNP2lJ3Xo1to9HZjaa3CiiitxBRRRQAUUVbvdOlsIrOSZk YXluLiPaTwpZlweOuVP6VLnFNRb1YFSiiiqAKKKKANzxB4nl163tIngWDy8y3DK2Tc3DAB5m9yFX j1ye9YdFW73TpbCKzkmZGF5bi4j2k8KWZcHjrlT+lc9KnRw0Y0aastbL8WO7bKlFFFdAgoq3e6dL YRWckzIwvLcXEe0nhSzLg8dcqf0qpUxnGa5ovQAoooqgCiird7p0thFZyTMjC8txcR7SeFLMuDx1 yp/Spc4pqLerAqVs+Ib+2vodGW1k8w22mxwS/KRtcO5I568EcjisatHVtJ/suPT287zfttmt1jZt 2bmYbepz93rx1rCoqbrQcn72tv1Gr627fqjOqe4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KijTz JFTcq7iBuY4A9zXReKfBF/4St7OXUZ7YtdRq6xJOjtyCTgKzZUfL8xxncMZwcKpiMPCtClUkueV+ VdXbe36gk3exzdFFFdQgooooAKKKKACnwzS21xHPbyPFNEweOSNirIwOQQR0IPemUUmk1Zga934s 8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZF FcyweGVrU46baLQfNLua934s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyI ZVmiE17I+yRfuuMnhh2I5FZFFCweGVrU46baLQOaXc17vxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZP DDsRyKj1HxNr2sWwttW1vUb6AMHEVzdySKGGQDhiRnk8+9ZlFOOEw0GnGnFW20WnoHNLuFFFFdIg ooooAKKKKACiiigAooooAKKKKAJLe4mtLiO4tZZIZomDxyxsVZGHIII5B9639W8da/q1vYRTavqW LSNM772RvMlV2ZZevDDIAPJG0c1zlakWildQ0mG9n8qHUlSRZIU8xo0Zyn3SVycqeM/jXFiaWFcl VrxTcb2bV3tqCbV7dh934s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZV miE17I+yRfuuMnhh2I5FX9e8K2unQSS6TqFxeiDUG0+YXFmLc+aAcFCHcMvBzyCPlyPmqhe+FtWs Wtg8EVx9qm8iJrK5iug0vH7vMTMA3I+U8muWjLLJxi4qK3tdKL87JpP10NHzq9wu/FniO/WJb7X9 UuRDKs0QmvZH2SL91xk8MOxHIou/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIq7f+DLvTPDja leTRCUX6WYSGeGaLLIzcypIQrDZyrAYDKc81Vv8Awxd2WrWGmqY3uL2FJEJuIPLYsSBtlWRkK5HU kfQUqVTK529nyaXtounxW8tdXsJ86vcZd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRc+LvE l6IheeINVuBDKJovNvZG8tx0cZPDDJwRzUU+galb2f2mSFDGLk2hWOZHdZRn5SiksM7TgkYOOM1P qnhPV9G0831/Dbi3WcWzvDeQzbJcE7GCOSrYU8EDpWqjlqlGK5L6pL3d+qX62D3/ADJtd8aa1r+n 2lnfalfywQwiOWOa8eRZnDM3mEHjOGA5z93rWBVu906Wwis5JmRheW4uI9pPClmXB465U/pVSurC 0qFGko4dJR8iW27XCp7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qKNPMkVNyruIG5jgD3NdF4p8 EX/hK3s5dRnti11GrrEk6O3IJOArNlR8vzHGdwxnBwqmIw8K0KVSS55X5V1dt7fqCTd7HN0UUV1C NnxDf219Doy2snmG202OCX5SNrh3JHPXgjkcVjVbvdOlsIrOSZkYXluLiPaTwpZlweOuVP6VUrDD whCko03dA+novyCiiitwCnxOscyO8ayqrAmNydrj0OCDg+xB96ZRSaurAb2qa5p02inS9E0u4sbe S6F1L9pvftB3BSqqmEQKuGbOQxPy5PFYNFFZUaEKEeWHrq2397bY22wooorYQUUU+GNZbiON5UhV 2CtLICVQE/eO0E4HXgE+xpN2VwFt7ia0uI7i1lkhmiYPHLGxVkYcggjkH3rf1bx1r+rW9hFNq+pY tI0zvvZG8yVXZll68MMgA8kbRzWdrGgX+hyR/bER4J9xt7uBxJDcAHBKOOGxkZHUZwQDxTovD95N f6VZxNEZdVRHg+YgKGdkG4kccqSevFefUWBrcuInyytez0enUa5otpf0h934s8R36xLfa/qlyIZV miE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FS32l+H0s3fSfEE11d LMIhBcWHkCQH+NX3sAv+9tPI464ra5okuhXFtBcMGea3WfcskUiHJI+V43dWXjrkH2FRSWAnKMYw Setk48r87JpO2u5T5+5Jd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciG VZohNeyPskX7rjJ4YdiORWXEI2mQTsyRFhvZF3Mq55IBIyfbI+tegXXw102x1q202+1jVbWW8nMN o8+joFuSHVcpicnHzAgsACM4JPFZYqpluClGNWCTabVoN6Le1k/V+WoLnkm0cnc+LvEl6IheeINV uBDKJovNvZG8tx0cZPDDJwRzVjXfGmta/p9pZ32pX8sEMIjljmvHkWZwzN5hB4zhgOc/d61Y1Hwn bad4en1KS8u0fMD2kM1oii4hm3lHLLK204jkJXBxgc88Yd7p0thFZyTMjC8txcR7SeFLMuDx1yp/ SroQy6tKM6UY3i3b3ba2u7aLo9/1Buae/T8LlSpLe4mtLiO4tZZIZomDxyxsVZGHIII5B96SGNZb iON5UhV2CtLICVQE/eO0E4HXgE+xq/rGgX+hyR/bER4J9xt7uBxJDcAHBKOOGxkZHUZwQDxXoTqU uZUptXl0fXv6+ZFjR1bx1r+rW9hFNq+pYtI0zvvZG8yVXZll68MMgA8kbRzVO78WeI79Ylvtf1S5 EMqzRCa9kfZIv3XGTww7Ecip18Owpq2h2lzeukerQxSmSOAMYd7soG0sN2COuR1q9qXg+x0iwvZ7 7VLnfa30NuBDZK6SxShmWVWMo/gRjtx97CkjkjyIzyqi4U4wXlaLe7t277/K/Qv32t+35afgZV34 s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5Fa es+E9N0fWLGGTW5Dp07GO4uns8PbSqFLxmJXbJUOnRupPpmotf8AD+iaTpsM1nrl1cXU8MVxFbz6 cIg0b553LK4BGOQfXgmqpVstm6apw+L4f3b72evLp53tbqO09dfxKNz4u8SXoiF54g1W4EMomi82 9kby3HRxk8MMnBHNWNd8aa1r+n2lnfalfywQwiOWOa8eRZnDM3mEHjOGA5z93rWBVu906Wwis5Jm RheW4uI9pPClmXB465U/pXb9TwcakH7OKavy6L52J5pa69PwKlbPiG/tr6HRltZPMNtpscEvykbX DuSOevBHI4rGq3e6dLYRWckzIwvLcXEe0nhSzLg8dcqf0repCDqwlJ6q9v1JXW3b9UVKnuL67vBi 7uppx5jS4lkLfO2Nzc9ztGT3wPSoo08yRU3Ku4gbmOAPc10XinwRf+Erezl1Ge2LXUausSTo7cgk 4Cs2VHy/McZ3DGcHEVMRh4VoUqklzyvyrq7b2/UaTd7HN0UUV1CCiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAJLe4mtLiO4tZZIZomDxyxsVZGHIII5B966W68 e6tqUulLq17qV3aWQj8+3e/ci5ZZC+87gQGwQMkHpXLVbvdOlsIrOSZkYXluLiPaTwpZlweOuVP6 Vx4jC4WvOLrRTlql387ME3ql2Op1X4gjWdQ+0anp81+tvfLeWK3155xgBIMkLHYPMibaMLhdvvyD Pf8AxIF1b2YW21S4uLO+W9im1PVvtXI4Me0RqAhHZdpGTyeMcJRXH/YmAXLan8O2stL6Pr169223 qy/aTbbvudNNr3h7+wJdKs9C1CKOa8iunkk1RHb5Ay7R+4AwVd8HGQSCcgbSmr+I9Kvf7Lk03Sby 1uNNSOKNri/SZGRGZsFRCh3Et1zjA6VzVFbxy3DRlzWd9d5Se6s93rp3E5N38zrtQ8VaDd2ksEXh y5RZ9RW/m8zU9/mEFt0fES4UqxAxhgTkluAE17xzLqlnbw2TasktvdC5iudQ1Q3csBAICxPsQxjn J65Kp0288lRUxyrCRlGXK243teUnvvu2P2kv6/rzN/XfGmta/p9pZ32pX8sEMIjljmvHkWZwzN5h B4zhgOc/d61gVbvdOlsIrOSZkYXluLiPaTwpZlweOuVP6VUrqwtKhRpKOHSUfIltu1wqe4vru8GL u6mnHmNLiWQt87Y3Nz3O0ZPfA9KijTzJFTcq7iBuY4A9zXReKfBF/wCErezl1Ge2LXUausSTo7cg k4Cs2VHy/McZ3DGcHCqYjDwrQpVJLnlflXV23t+oJN3sc3UlvcTWlxHcWsskM0TB45Y2KsjDkEEc g+9R0V0tKSsxHR6t461/Vrewim1fUsWkaZ33sjeZKrsyy9eGGQAeSNo5qnd+LPEd+sS32v6pciGV ZohNeyPskX7rjJ4YdiORWRRXHTwGEppKFOKttoupXNLua934s8R36xLfa/qlyIZVmiE17I+yRfuu Mnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZFFWsHhla1OOm2i0FzS7mvd+LPEd+ sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWRRQsH hla1OOm2i0Dml3Ne78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecii78WeI79Ylvtf1S5EMqzRC a9kfZIv3XGTww7EcisiihYPDK1qcdNtFoHNLua934s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5 FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZFFCweGVrU46baLQOaXc17vxZ4jv1iW+1/VL kQyrNEJr2R9ki/dcZPDDsRyKLvxPrOrLFBr+sapqVksqyPbzXrtnHpu3ANgkA4OM9D0rIooWDw0b ctNK21klb07fIOaXc3rzxVciOK08PrJothC4kSG2nbfJICCJZZOC7jAwcBVx8qrk5uXPxE1+6m0p 5tRvZ108Rlorm7eWO4dHZg7KT1wQPXA61ytW73TpbCKzkmZGF5bi4j2k8KWZcHjrlT+lc8svwV4x lBN62vq9d9Xq35vUfNLWx0Nz4vsz4dbQ9PtdXh02a4SSW2n1cSxqisWKxL5ShCSc7iG6Dg1T8Ra3 pGr2dlHYaXe2k1nAtujzX6TK0aljyohQ7st1zjjpXP0VVLLcNSmpwTTTb+KW73b11v53Dnkx8RjW ZDOjPEGG9UbazLnkAkHB98H6V0ep+LIbrxZaa1Y2l3CkF59sNrc3omQSeYHOzEa7AcDsTx1rmaK3 q4WlWmpzV2k1u9nvpe3z3Fd2sddrPxAu9V037LDbmyki1L7ZazwzYa3jVSI4lwB9zcSGGOp4qpq3 jrX9Wt7CKbV9SxaRpnfeyN5kquzLL14YZAB5I2jmucq3e6dLYRWckzIwvLcXEe0nhSzLg8dcqf0r lhluAouMVTV1e3Xffcrnk23f+rly78T6zqyxQa/rGqalZLKsj28167Zx6btwDYJAODjPQ9KfqniJ 7qyGmaTb/wBl6SOTaRysxnb+/M3HmNwOwUfwquTnForpWDw8XFxgly7JbX722v52uTzM6a51ywTV PDd4qvdpptnCs0Ub+UfMSR227ip9Rzg1dXxzZNClpd6NNc2MWppfRI96PNCKJD5DP5eCm+Vm+6D8 zDvkcve6dLYRWckzIwvLcXEe0nhSzLg8dcqf0qpXH/ZuDrQXMnJLS92ur7Na6vXcfM7fd+R2GreO LfXNJvbPU9Mkkaa9F3DNC9tAyHBB3+Xbr5jNk5Y4/h4GDnL8Sa1p2siw/s7TrqyNpbrbHz7xZ96L 908Rpg8nPXPHA74dFbUMtwuHkpUY8tr2Sbtra+l7dO2+u43Uk9yS3uJrS4juLWWSGaJg8csbFWRh yCCOQfet/VvHWv6tb2EU2r6li0jTO+9kbzJVdmWXrwwyADyRtHNc5Vu906Wwis5JmRheW4uI9pPC lmXB465U/pWtbD4apVjKrFOSva6+8lNq9i5c+LvEl6IheeINVuBDKJovNvZG8tx0cZPDDJwRzVjX fGmta/p9pZ32pX8sEMIjljmvHkWZwzN5hB4zhgOc/d61gUUlgcKpRmqcU47aLQfNLuFT3F9d3gxd 3U048xpcSyFvnbG5ue52jJ74HpUUaeZIqblXcQNzHAHua6LxT4Iv/CVvZy6jPbFrqNXWJJ0duQSc BWbKj5fmOM7hjODiqmIw8K0KVSS55X5V1dt7fqJJu9jm6KKK6hBRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAElvcTWlxHcWsskM0TB45Y2KsjDkEEcg+9b+reO tf1a3sIptX1LFpGmd97I3mSq7MsvXhhkAHkjaOa5yiuarhaFacalSCbjs2thptbGvd+LPEd+sS32 v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWRRSWDwyta nHTbRaBzS7mvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyP skX7rjJ4YdiORWRRQsHhla1OOm2i0Dml3Ne78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecii58 XeJL0RC88QarcCGUTRebeyN5bjo4yeGGTgjmsiihYLCq1qcdNtEHNLub+u+NNa1/T7SzvtSv5YIY RHLHNePIszhmbzCDxnDAc5+71rAooq6GHpYeHs6MVFdkDbe4VPcX13eDF3dTTjzGlxLIW+dsbm57 naMnvgelRRp5kipuVdxA3McAe5rpPE3ga/8AC0di2o3NoGvERlQToxGc5PyM3yj5fmOM7uM4OIq4 jD060KdSSU5X5V1dt7fqCTaduhzNFdN4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHB4 m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHGNPM8FV5OSonz35fO29vTqNwkr3WxzNFdN 4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHB4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5 R8vzHGd3GcHBTzPBVeTkqJ89+Xztvb06g4SV7rY5mium8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8 o+X5jjO7jODg8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODgp5ngqvJyVE+e/L523t6d QcJK91sczRXTeJvA1/4WjsW1G5tA14iMqCdGIznJ+Rm+UfL8xxndxnBweJvA1/4WjsW1G5tA14iM qCdGIznJ+Rm+UfL8xxndxnBwU8zwVXk5KifPfl87b29OoOEle62OZorpvE3ga/8AC0di2o3NoGvE RlQToxGc5PyM3yj5fmOM7uM4ODxN4Gv/AAtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODgp5ngq vJyVE+e/L523t6dQcJK91sczRXTeJvA1/wCFo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcHibw Nf8AhaOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHBTzPBVeTkqJ89+Xztvb06g4SV7rY5mium8T eBr/AMLR2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg4PE3ga/wDC0di2o3NoGvERlQToxGc5PyM3 yj5fmOM7uM4OCnmeCq8nJUT578vnbe3p1Bwkr3WxztvcTWlxHcWsskM0TB45Y2KsjDkEEcg+9b+r eOtf1a3sIptX1LFpGmd97I3mSq7MsvXhhkAHkjaOaf4m8DX/AIWjsW1G5tA14iMqCdGIznJ+Rm+U fL8xxndxnBweJvA1/wCFo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcc31nK8XOlUbjJyvyPe9t 7enXsPlnG/pr6FC78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecii78WeI79Ylvtf1S5EMqzRCa 9kfZIv3XGTww7Ecir/ibwNf+Fo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcHibwNf+Fo7FtRub QNeIjKgnRiM5yfkZvlHy/McZ3cZwcTSr5TU9n7PkfNflslrb4radOo3zq9yhd+LPEd+sS32v6pci GVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORV/xN4Gv/C0di2o3 NoGvERlQToxGc5PyM3yj5fmOM7uM4ODxN4Gv/C0di2o3NoGvERlQToxGc5PyM3yj5fmOM7uM4OCl Xymp7P2fI+a/LZLW3xW06dQfOr3KFz4u8SXoiF54g1W4EMomi829kby3HRxk8MMnBHNWNd8aa1r+ n2lnfalfywQwiOWOa8eRZnDM3mEHjOGA5z93rU/ibwNf+Fo7FtRubQNeIjKgnRiM5yfkZvlHy/Mc Z3cZwcHibwNf+Fo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcKlVyipKlOlyXd3CyWtt7enUH7R Xv2/A5mpLe4mtLiO4tZZIZomDxyxsVZGHIII5B966LxN4Gv/AAtHYtqNzaBrxEZUE6MRnOT8jN8o +X5jjO7jODg8TeBr/wALR2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg464Zlgqygo1E/aX5f71t7 d7dSXCSvdbDNW8da/q1vYRTavqWLSNM772RvMlV2ZZevDDIAPJG0c1Tu/FniO/WJb7X9UuRDKs0Q mvZH2SL91xk8MOxHIq/4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHB4m8DX/haOxbUb m0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHHHh6mUNU1R5Pevy2S1t8VvTqU/aK9+i/AoXfizxHfrEt9r +qXIhlWaITXsj7JF+64yeGHYjkUXfizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkVf8TeBr/wAL R2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg4PE3ga/8AC0di2o3NoGvERlQToxGc5PyM3yj5fmOM 7uM4OKpV8pqez9nyPmvy2S1t8VtOnUHzq9yhc+LvEl6IheeINVuBDKJovNvZG8tx0cZPDDJwRzVj XfGmta/p9pZ32pX8sEMIjljmvHkWZwzN5hB4zhgOc/d61P4m8DX/AIWjsW1G5tA14iMqCdGIznJ+ Rm+UfL8xxndxnBweJvA1/wCFo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcKlVyipKlOlyXd3Cy Wtt7enUH7RXv2/A5mium8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODg8TeBr/wtHYtq NzaBrxEZUE6MRnOT8jN8o+X5jjO7jODjsp5ngqvJyVE+e/L523t6dSXCSvdbHM1PcX13eDF3dTTj zGlxLIW+dsbm57naMnvgelb/AIm8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHDfFPgi/8 JW9nLqM9sWuo1dYknR25BJwFZsqPl+Y4zuGM4OFTzHA13TcKibnfl87b29OockldWObooor0SQoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACp7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qCik4ptNrYCe4vru8GLu6mnHmNLi WQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qCipVOCtZbAT3F9d3gxd3U04 8xpcSyFvnbG5ue52jJ74HpRcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelQUUKnBWstgJ7i+u7wYu 7qaceY0uJZC3ztjc3Pc7Rk98D0ouL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKFTgrWWwE9xfX d4MXd1NOPMaXEshb52xubnudoye+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUFFCpwVrLYC e4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qCihU4K 1lsBPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelFxfXd4MXd1NOPMaXEshb52xubnudoye+B6VBR QqcFay2AnuL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSi4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA 9KgooVOCtZbAT3F9d3gxd3U048xpcSyFvnbG5ue52jJ74HpRcX13eDF3dTTjzGlxLIW+dsbm57na MnvgelQUUKnBWstgJ7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0ouL67vBi7uppx5jS4lkLfO2Nz c9ztGT3wPSoKKFTgrWWwE9xfXd4MXd1NOPMaXEshb52xubnudoye+B6UXF9d3gxd3U048xpcSyFv nbG5ue52jJ74HpUFFCpwVrLYCe4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0u JZC3ztjc3Pc7Rk98D0qCihU4K1lsBPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelFxfXd4MXd1NO PMaXEshb52xubnudoye+B6VBRQqcFay2AnuL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSi4vru8GL u6mnHmNLiWQt87Y3Nz3O0ZPfA9KgooVOCtZbAT3F9d3gxd3U048xpcSyFvnbG5ue52jJ74HpRcX1 3eDF3dTTjzGlxLIW+dsbm57naMnvgelQUUKnBWstgJ7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0 ouL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKFTgrWWwE9xfXd4MXd1NOPMaXEshb52xubnudoy e+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUFFCpwVrLYCe4vru8GLu6mnHmNLiWQt87Y3Nz 3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qCihU4K1lsAUUUVYBRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQB//Z --_004_2C5AD5728DB9B24189E3A93140E45786367C79szxeml522mbxchina_-- From prvs=098533321=Nicolas.BOUTHORS@qosmos.com Tue Jan 28 00:02:28 2014 Return-Path: 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 99FC61A01DB for ; Tue, 28 Jan 2014 00:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.551 X-Spam-Level: X-Spam-Status: No, score=0.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001] 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 7qPhqtIvAPhu for ; Tue, 28 Jan 2014 00:02:25 -0800 (PST) Received: from smtp-ft5.fr.colt.net (smtp-ft5.fr.colt.net [213.41.78.197]) by ietfa.amsl.com (Postfix) with ESMTP id B273D1A01DA for ; Tue, 28 Jan 2014 00:02:24 -0800 (PST) Received: from smtp-ex5.fr.colt.net (smtp-ex5.fr.colt.net [213.41.78.121]) by smtp-ft5.fr.colt.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s0S82L6W017198 for ; Tue, 28 Jan 2014 09:02:21 +0100 Received: from mx1.qosmos.fr ([195.68.92.43] helo=mx3.qosmos.com) by smtp-ex5.fr.colt.net with esmtp (Exim) (envelope-from ) id 1W83ci-0004Tg-0a for ; Tue, 28 Jan 2014 09:02:21 +0100 X-IronPort-AV: E=Sophos;i="4.95,734,1384297200"; d="jpg'145?scan'145,208,217,145";a="816485" Received: from unknown (HELO mailbox.jungle.qosmos.com) ([10.12.1.3]) by mx3.qosmos.com with ESMTP; 28 Jan 2014 09:02:16 +0100 Received: from LILAS.jungle.qosmos.com ([fe80::5524:2c18:b2c3:74d4]) by CAROUBIER.jungle.qosmos.com ([169.254.1.72]) with mapi id 14.01.0438.000; Tue, 28 Jan 2014 09:02:16 +0100 From: Nicolas BOUTHORS To: Guanxiaoran Thread-Topic: Note on GI deployment scenario draft-liu-sfc-use-cases-00 Thread-Index: AQHPG0E50IKowRRhXEC5c6zdZjgHZZqZvJyAgAAILtw= Date: Tue, 28 Jan 2014 08:02:15 +0000 Message-ID: <76B41B8FACE1514795D30EC137FF391D3D0967@LILAS.jungle.qosmos.com> References: <76B41B8FACE1514795D30EC137FF391D3D08E0@LILAS.jungle.qosmos.com>, <2C5AD5728DB9B24189E3A93140E45786367C79@szxeml522-mbx.china.huawei.com> In-Reply-To: <2C5AD5728DB9B24189E3A93140E45786367C79@szxeml522-mbx.china.huawei.com> Accept-Language: en-US, fr-FR Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.13.0.22] Content-Type: multipart/related; boundary="_004_76B41B8FACE1514795D30EC137FF391D3D0967LILASjungleqosmos_"; type="multipart/alternative" MIME-Version: 1.0 X-ACL-Warn: 1/1 recipients OK. Cc: "sfc@ietf.org" Subject: Re: [sfc] Note on GI deployment scenario draft-liu-sfc-use-cases-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 08:02:28 -0000 --_004_76B41B8FACE1514795D30EC137FF391D3D0967LILASjungleqosmos_ Content-Type: multipart/alternative; boundary="_000_76B41B8FACE1514795D30EC137FF391D3D0967LILASjungleqosmos_" --_000_76B41B8FACE1514795D30EC137FF391D3D0967LILASjungleqosmos_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RFBJIGRvZXMgbm90IGhhdmUgdG8gYmUgYSBSYWRpdXMgcHJveHkuIEl0IGNhbiBvYnNlcnZlIHRo ZSBSYWRpdXMgdHJhZmZpYyB2aWEgYSBUYXAgb3IgZ2V0IGEgY29weQ0Kb2YgdGhlIFJhZGl1cyB0 cmFmZmljIHVzaW5nIE9wZW5GbG93IHRhYmxlcyBpZiB0aGUgdHJhZmZpYyBydW5zIHRocm91Z2gg YSAodmlydHVhbCkgc3dpdGNoIHRoYXQgaXQgY2FuIGNvbnRyb2wuDQoNCkFjdGluZyBhcyBhIHBy b3h5IGlzIG1vcmUgY29tcGxleCBhcyBpdCBjYW4gaGF2ZSBhbiBlZmZlY3Qgb24gcGVyZm9ybWFu Y2UgYW5kIEhBOiB0aGUgcmFkaXVzIGNhbGxzIGFyZSBvbiB0aGUgY3JpdGljYWwgcGF0aCBvZiBQ RFAgY29udGV4dCBlc3RhYmxpc2htZW50Lg0KDQpJdCBpcyB1c2VmdWxsIG9ubHkgaWYgd2Ugd2Fu dCB0byBpbnN1cmUgdGhhdCB0aGUgSVAvTVNJU0ROIGNvcnJlbGF0aW9uIGlzIHBlcmZvcm1lZCBi ZWZvcmUgYW55IGVuZCB1c2VyIHRyYWZmaWMgaXMgYWxsb3dlZCB0byBnbyB0aHJvdWdoLg0KDQpX YXRjaGluZyBvdmVyIHRoZSBSYWRpdXMgdHJhZmZpYyBhbHNvIGFsbG93cyB0byBjYXB0dXJlIG90 aGVyIHBhcmFtZXRlcnMgc3VjaCBhcyB0aGUgQVBOLiBUaGUgUmFkaXVzIHNlcnZlciBjb3VsZCBh bHNvIGluY2x1ZGUgZXh0ZW5zaW9ucyBzdWNoIGFzIGFuIGluZGljYXRpb24gb2Ygd2hpY2ggcG9s aWNpZXMgc2hvdWxkIGJlIGFwcGxpZWQgdG8gYSBwYXJ0aWN1bGFyIHN1YnNjcmliZXIgdHJhZmZp Yy4NClRoaXMgbGFzdCBwb2ludCBjb21iaW5lZCB0byB0aGUgbWV0YWRhdGEgaXQgY29sbGVjdHMg Y291bGQgYWxsb3cgdGhlIERQIHRvIHNlbGVjdCB0aGUgYXBwcm9wcmlhdGUgc2VydmljZSBjaGFp biB0byBhcHBseSB0byBvdXRnb2luZyBwYWNrZXRzDQoNCg0KDQpOaWNvbGFzDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBHdWFueGlhb3JhbiBbZ3VhbnhpYW9yYW5A aHVhd2VpLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjgsIDIwMTQgODoyMyBBTQ0KVG86 IE5pY29sYXMgQk9VVEhPUlM7IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogtPC4tDogTm90ZSBvbiBH SSBkZXBsb3ltZW50IHNjZW5hcmlvIGRyYWZ0LWxpdS1zZmMtdXNlLWNhc2VzLTAwDQoNCkhpIE5p Y29sYXMsDQoNCkRvIHlvdSBtZWFuIHRoYXQgRFBJIG11c3Qgc3VwcG9ydCBSQURJVVMgcHJveHkg aW4gdGhpcyBjYXNlPw0KDQpSYW4NCg0Kt6K8/sjLOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0Bp ZXRmLm9yZ10gtPqx7SBOaWNvbGFzIEJPVVRIT1JTDQq3osvNyrG85DogMjAxNMTqMdTCMjfI1SAx NzoyMw0KytW8/sjLOiBzZmNAaWV0Zi5vcmcNCtb3zOI6IFtzZmNdIE5vdGUgb24gR0kgZGVwbG95 bWVudCBzY2VuYXJpbyBkcmFmdC1saXUtc2ZjLXVzZS1jYXNlcy0wMA0KDQpIZWxsbywNCg0KT24g R2kgZGVwbG95bWVudHMgdGhlIEdHU04gY29ubmVjdHMgdG8gYSBSYWRpdXMgRnVuY3Rpb24gYXQg UERQIENvbnRleHQgU2V0dXAgVGltZS4gSW4gbW9zdCBjYXNlDQp0aGlzIGlzIHVzZWQgdG8gcGVy Zm9ybSBhbmQgTVNJU0ROIHRvIElQIGFkZHJlc3MgbWFwcGluZywgd2hpY2ggaXMgdGhlbiB1c2Vk IGJ5IHRoZSBHaSBzZXJ2aWNlIGluZnJhc3RydWN0dXJlDQp0byBkZWNpZGUgaG93IHRvIGhhbmRs ZSB0aGUgSVAgZmxvd3MgZm9yIHRoYXQgcGFydGljdWxhciBzdWJzY3JpYmVyLg0KDQpUaGlzIGlu Zm9ybWF0aW9uIGNhbm5vdCBiZSBkZXJpdmVkIGJ5IHRoZSBEUEkgbG9jYXRlZCBhZnRlciB0aGUg R0dTTi4gKEl0IGNvdWxkIGlmIHRoZSBEUEkgd2VyZSB0byBiZSBsb2NhdGVkIG9uIHRoZSBvdGhl ciBzaWRlIG9mIHRoZSBHR1NOLCB0aGUgR24gaW50ZXJmYWNlKS4NCg0KSXQgaXMgY2xlYXIgdGhh dCB3ZSBzaG91bGQgdXBkYXRlIHRoZSBkaWFncmFtIHRvIHNob3cgdGhlIFJhZGl1cyB0cmFmZmlj IGdvIHRocm91Z2ggdGhlIERQSSBzbyB0aGF0IHRoZSBEUEkgY2FuIGV4dHJhY3QgdGhlIGluZm9y bWF0aW9uIGFuZCBhZGQgaXQgdG8gdGhlIG1ldGFkYXRhIHdoaWNoIHdpbGwgYmUgY29sbGVjdGVk IGxhdGVyIGFzIHRoZSBzdWJzY3JpYmVyIHRyYWZmaWMgZ29lcyB0aHJvdWdoLg0KDQpTb21ldGhp bmcgbGlrZToNCg0KQ2hhaW4gMDogR0dTTiBzZW5kIFJhZGl1cyB0cmFmZmljIHRvIFJhZGl1cyBz ZXJ2ZXIgdmlhIHRoZSBEUEkgc28gdGhhdCB0aGUgRFBJIGNhbiBlc3RhYmxpc2ggdGhlIElQL01T SVNETiBjb3JyZWxhdGlvbg0KDQoNCltjaWQ6aW1hZ2UwMDEuanBnQDAxQ0YxQzNDLkU0MTFFRkYw XQ0KDQoNCg0KTmljb2xhcw0KDQo= --_000_76B41B8FACE1514795D30EC137FF391D3D0967LILASjungleqosmos_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
DPI does not have to be a Radius proxy. It can observe the Radius traf= fic via a Tap or get a copy
of the Radius traffic using OpenFlow tables if the traffic runs throug= h a (virtual) switch that it can control.

Acting as a proxy is more complex as it can have an effect on performa= nce and HA: the radius calls are on the critical path of PDP context establ= ishment.

It is usefull only if we want to insure that the IP/MSISDN correlation= is performed before any end user traffic is allowed to go through.

Watching over the Radius traffic also allows to capture other paramete= rs such as the APN. The Radius server could also include extensions such as= an indication of which policies should be applied to a particular subscrib= er traffic. 
This last point combined to the metadata it collects could allow the D= P to select the appropriate service chain to apply to outgoing packets = ;



Nicolas

From: Guanxiaoran [guanxiaoran@huawei.com= ]
Sent: Tuesday, January 28, 2014 8:23 AM
To: Nicolas BOUTHORS; sfc@ietf.org
Subject: =B4=F0=B8=B4: Note on GI deployment scenario draft-liu-sfc-= use-cases-00

Hi Nicol= as,

 

Do you m= ean that DPI must support RADIUS proxy in this case?

 

Ran

 

=B7=A2=BC=FE=C8=CB: sfc [mailto:sfc-bou= nces@ietf.org] =B4=FA=B1=ED= Nicolas BOUTHORS
=B7=A2=CB=CD= =CA=B1=BC=E4: 2014=C4=EA1=D4= =C227=C8=D5 17:23
=CA=D5=BC=FE=C8=CB: sfc@ietf.org
=D6=F7=CC=E2: [sfc] Note on GI deployment scenario draft-liu-sfc-use-cases-00

 

Hello,

 

On Gi deplo= yments the GGSN connects to a Radius Function at PDP Context Setup Time. In= most case

this is use= d to perform and MSISDN to IP address mapping, which is then used by the Gi= service infrastructure

to decide h= ow to handle the IP flows for that particular subscriber.

 

This inform= ation cannot be derived by the DPI located after the GGSN. (It could if the= DPI were to be located on the other side of the GGSN, the Gn interface).

 

It is clear= that we should update the diagram to show the Radius traffic go through th= e DPI so that the DPI can extract the information and add it to the metadata which will be collected later as the subscriber traffic= goes through. 

 

Something l= ike:

 

Chain 0: GG= SN send Radius traffic to Radius server via the DPI so that the DPI can est= ablish the IP/MSISDN correlation

 

 

 

 

 

Nicolas

 

--_000_76B41B8FACE1514795D30EC137FF391D3D0967LILASjungleqosmos_-- --_004_76B41B8FACE1514795D30EC137FF391D3D0967LILASjungleqosmos_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=34434; creation-date="Tue, 28 Jan 2014 07:23:27 GMT"; modification-date="Tue, 28 Jan 2014 07:23:27 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/4RDSRXhpZgAATU0AKgAAAAgABAE7AAIAAAAEZGNoAIdpAAQA AAABAAAISpydAAEAAAAIAAAQwuocAAcAAAgMAAAAPgAAAAAc6gAAAAgAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFkAMAAgAAABQAABCY kAQAAgAAABQAABCskpEAAgAAAAM0OAAAkpIAAgAAAAM0OAAA6hwABwAACAwAAAiMAAAAABzqAAAA CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAMjAxNDowMToyNyAxMDoyMjowOQAyMDE0OjAxOjI3IDEwOjIyOjA5AAAAZABjAGgAAAD/4QsW aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49J++7vycgaWQ9J1c1 TTBNcENlaGlIenJlU3pOVGN6a2M5ZCc/Pg0KPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczpt ZXRhLyI+PHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJk Zi1zeW50YXgtbnMjIj48cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0idXVpZDpmYWY1YmRkNS1i YTNkLTExZGEtYWQzMS1kMzNkNzUxODJmMWIiIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcvZGMv ZWxlbWVudHMvMS4xLyIvPjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSJ1dWlkOmZhZjViZGQ1 LWJhM2QtMTFkYS1hZDMxLWQzM2Q3NTE4MmYxYiIgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUu Y29tL3hhcC8xLjAvIj48eG1wOkNyZWF0ZURhdGU+MjAxNC0wMS0yN1QxMDoyMjowOS40NzU8L3ht cDpDcmVhdGVEYXRlPjwvcmRmOkRlc2NyaXB0aW9uPjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0 PSJ1dWlkOmZhZjViZGQ1LWJhM2QtMTFkYS1hZDMxLWQzM2Q3NTE4MmYxYiIgeG1sbnM6ZGM9Imh0 dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIj48ZGM6Y3JlYXRvcj48cmRmOlNlcSB4bWxu czpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPjxyZGY6 bGk+ZGNoPC9yZGY6bGk+PC9yZGY6U2VxPg0KCQkJPC9kYzpjcmVhdG9yPjwvcmRmOkRlc2NyaXB0 aW9uPjwvcmRmOlJERj48L3g6eG1wbWV0YT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgPD94cGFja2V0IGVuZD0ndyc/Pv/bAEMABwUFBgUEBwYF BggHBwgKEQsKCQkKFQ8QDBEYFRoZGBUYFxseJyEbHSUdFxgiLiIlKCkrLCsaIC8zLyoyJyorKv/b AEMBBwgICgkKFAsLFCocGBwqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKv/AABEIARoCPAMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUG BwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR 8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5 eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj 5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQAC AQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXx FxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqS k5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T1 9vf4+fr/2gAMAwEAAhEDEQA/APn6iiiv0k5AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAop0aeZIqblXcQNzHAHua6TxN4Gv/AAtHYtqNzaBrxEZU E6MRnOT8jN8o+X5jjO7jODjmqYqhSqxozklKV7Lq7b29ASbTfY5mium8TeBr/wALR2Lajc2ga8RG VBOjEZzk/IzfKPl+Y4zu4zg4PE3ga/8AC0di2o3NoGvERlQToxGc5PyM3yj5fmOM7uM4OMKeZ4Kr yclRPnvy+dt7enUpwkr3WxzNFdN4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHB4m8DX /haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHBTzPBVeTkqJ89+Xztvb06g4SV7rY5mium8TeBr /wALR2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg4PE3ga/8AC0di2o3NoGvERlQToxGc5PyM3yj5 fmOM7uM4OCnmeCq8nJUT578vnbe3p1Bwkr3WxzNFdN4m8DX/AIWjsW1G5tA14iMqCdGIznJ+Rm+U fL8xxndxnBweJvA1/wCFo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcFPM8FV5OSonz35fO29vT qDhJXutjmaK6bxN4Gv8AwtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODg8TeBr/AMLR2Lajc2ga 8RGVBOjEZzk/IzfKPl+Y4zu4zg4KeZ4KryclRPnvy+dt7enUHCSvdbHM0V03ibwNf+Fo7FtRubQN eIjKgnRiM5yfkZvlHy/McZ3cZwcHibwNf+Fo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcFPM8F V5OSonz35fO29vTqDhJXutjmaK6bxN4Gv/C0di2o3NoGvERlQToxGc5PyM3yj5fmOM7uM4ODxN4G v/C0di2o3NoGvERlQToxGc5PyM3yj5fmOM7uM4OCnmeCq8nJUT578vnbe3p1Bwkr3WxzNFdN4m8D X/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHB4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vz HGd3GcHBTzPBVeTkqJ89+Xztvb06g4SV7rY5mium8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8o+X5 jjO7jODg8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODgp5ngqvJyVE+e/L523t6dQcJK 91sczRXTeJvA1/4WjsW1G5tA14iMqCdGIznJ+Rm+UfL8xxndxnBweJvA1/4WjsW1G5tA14iMqCdG IznJ+Rm+UfL8xxndxnBwU8zwVXk5KifPfl87b29OoOEle62OZorpvE3ga/8AC0di2o3NoGvERlQT oxGc5PyM3yj5fmOM7uM4ODxN4Gv/AAtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODgp5ngqvJyV E+e/L523t6dQcJK91sczRXTeJvA1/wCFo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcHibwNf8A haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHBTzPBVeTkqJ89+Xztvb06g4SV7rY5mium8TeBr/ AMLR2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg4PE3ga/wDC0di2o3NoGvERlQToxGc5PyM3yj5f mOM7uM4OCnmeCq8nJUT578vnbe3p1Bwkr3WxzNFdN4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8v zHGd3GcHB4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHBTzPBVeTkqJ89+Xztvb06g4S V7rY5mium8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODg8TeBr/wtHYtqNzaBrxEZUE6 MRnOT8jN8o+X5jjO7jODgp5ngqvJyVE+e/L523t6dQcJK91sczRXTeJvA1/4WjsW1G5tA14iMqCd GIznJ+Rm+UfL8xxndxnBweJvA1/4WjsW1G5tA14iMqCdGIznJ+Rm+UfL8xxndxnBwU8zwVXk5Kif Pfl87b29OoOEle62OZorpvE3ga/8LR2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg4b4p8EX/AISt 7OXUZ7YtdRq6xJOjtyCTgKzZUfL8xxncMZwcFLMsHWdNU6ifPfl87b29OockuxzdFFFegSFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAVPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelRRp5kipuVdxA3McAe5rovFPgi/8JW9n LqM9sWuo1dYknR25BJwFZsqPl+Y4zuGM4OOWpiMPCtClUkueV+VdXbe36jSbvYwri+u7wYu7qace Y0uJZC3ztjc3Pc7Rk98D0ouL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKK3VOCtZbCJ7i+u7wYu 7qaceY0uJZC3ztjc3Pc7Rk98D0ouL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKFTgrWWwE9xfX d4MXd1NOPMaXEshb52xubnudoye+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUFFCpwVrLYC e4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qFFDSKr MEBIBZs4X3OOa1fEOkWukXFqLC/a/t7m3E6TNB5WfnZeFJJxlMgnBwRkA8Vk5UYVI07au9tPv1tZ fqPV3KFxfXd4MXd1NOPMaXEshb52xubnudoye+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ74HpU FFaqnBWsthE9xfXd4MXd1NOPMaXEshb52xubnudoye+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ 74HpUFFCpwVrLYCe4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3P c7Rk98D0qCrd7p0thFZyTMjC8txcR7SeFLMuDx1yp/SptTi4xsk9bfrYNWR3F9d3gxd3U048xpcS yFvnbG5ue52jJ74HpRcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelQUVSpwVrLYCe4vru8GLu6mnH mNLiWQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qCihU4K1lsBPcX13eDF3 dTTjzGlxLIW+dsbm57naMnvgelFxfXd4MXd1NOPMaXEshb52xubnudoye+B6VBRQqcFay2AnuL67 vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSi4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KkvdOlsIrOSZ kYXluLiPaTwpZlweOuVP6VUqYKnJKUErLb9Q1J7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0ouL6 7vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKpU4K1lsBPcX13eDF3dTTjzGlxLIW+dsbm57naMnvge lFxfXd4MXd1NOPMaXEshb52xubnudoye+B6VBRQqcFay2AnuL67vBi7uppx5jS4lkLfO2Nzc9ztG T3wPSi4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KgooVOCtZbAT3F9d3gxd3U048xpcSyFvnbG5u e52jJ74HpRcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelQUUKnBWstgJ7i+u7wYu7qaceY0uJZC3z tjc3Pc7Rk98D0ouL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKFTgrWWwE9xfXd4MXd1NOPMaXE shb52xubnudoye+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUUaeZIqblXcQNzHAHua6LxT4 Iv8Awlb2cuoz2xa6jV1iSdHbkEnAVmyo+X5jjO4Yzg4551sNSqwoyaUpX5V1dt7fqNJu9jm6KKK6 xBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFT3F9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUUaeZIqblXcQNzHAHua6LxT4 Iv8Awlb2cuoz2xa6jV1iSdHbkEnAVmyo+X5jjO4Yzg45amIw8K0KVSS55X5V1dt7fqNJu9jm6KKK 6hBRVu906Wwis5JmRheW4uI9pPClmXB465U/pVSpjOM1zRegBRRRVAOjKCVDMrNGGG5VbaSO4Bwc H3wa29f1jSNUsrGLTtMvbSWziECvPfpMrRhnblREnzZfrnGB071hUVhOhCdSNSV7x21a/BOz+YJ2 CiiitwCiinwxrLcRxvKkKuwVpZASqAn7x2gnA68An2NJuyuAtvcTWlxHcWsskM0TB45Y2KsjDkEE cg+9b+reOtf1a3sIptX1LFpGmd97I3mSq7MsvXhhkAHkjaOaztY0C/0OSP7YiPBPuNvdwOJIbgA4 JRxw2MjI6jOCAeKtaX4b+2a7o1he3XkR6sqtHLDH5rJuZkUFSVydy+vQ59q82s8DUjHFVEpWTadr 6Le1r39ClzJtIiu/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIou/FniO/WJb7X9UuRDKs0Qmv ZH2SL91xk8MOxHIrTu/CVjYaK+o3t/fQIXt3t0exjJnt5txWQYmOG2xyHYfQDPORB4m8M2nh+8tR DqUt3ZysY5pDaiOSCRQpkjKbyCyh1/iAJJHbNc9Ktlk5xhTir629x9Em7O1tn8ynz2uynd+LPEd+ sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWn4h8J WGkrqy6dqtzeTaRdLb3Sz2QgUkllyjCR88r0IU457Gue03T5tV1S2sLXb51zKsSbzhQScZJ7CtqH 9n1aXtqcFyx/u2tpfZpNaO4pc8XZsvXfizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkUXPi7xJe iIXniDVbgQyiaLzb2RvLcdHGTwwycEc1raf4a8M6pqVtZWPie6aae6W2CvpO0vu4Dp+9IK5x94qe enaodR8J22neHp9SkvLtHzA9pDNaIouIZt5RyyyttOI5CVwcYHPPGEa+WKcafIlLSydNr4nbS8V1 3/Edp9/xK+u+NNa1/T7SzvtSv5YIYRHLHNePIszhmbzCDxnDAc5+71rAq3e6dLYRWckzIwvLcXEe 0nhSzLg8dcqf0qpXp4WlQo0lHDpKPkQ23a4UUUV0iCiiigAooooAKKKKACiird7p0thFZyTMjC8t xcR7SeFLMuDx1yp/Spc4pqLerAqVPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelRRp5kipuVdxA3 McAe5rovFPgi/wDCVvZy6jPbFrqNXWJJ0duQScBWbKj5fmOM7hjODjnqYjDwrQpVJLnlflXV23t+ o0m72ObooorqEFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAVPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelRRp5kipuVdxA 3McAe5rovFPgi/8ACVvZy6jPbFrqNXWJJ0duQScBWbKj5fmOM7hjODjlqYjDwrQpVJLnlflXV23t +o0m72ObqS3uJrS4juLWWSGaJg8csbFWRhyCCOQfeo6K6WlJWYjo9W8da/q1vYRTavqWLSNM772R vMlV2ZZevDDIAPJG0c1Tu/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIqHVtJ/suPT287zfttm t1jZt2bmYbepz93rx1rOrgw+EwXs4ulTjbW2n3lOUur6fga934s8R36xLfa/qlyIZVmiE17I+yRf uuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZFFbLB4ZWtTjptotBc0u5r3fizx HfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkUXfizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkVkUU LB4ZWtTjptotA5pdzXu/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIou/FniO/WJb7X9UuRDKs 0QmvZH2SL91xk8MOxHIrIooWDwytanHTbRaBzS7mvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4Yd iORRd+J9Z1ZYoNf1jVNSsllWR7ea9ds49N24BsEgHBxnoelZFFCweGjblppW2skrenb5BzS7m9ee KrkRxWnh9ZNFsIXEiQ207b5JAQRLLJwXcYGDgKuPlVcnNyf4ha5d3WjyXl/f3MWnNE7wT3rutw8c pcOwPfkDPJ4rlat3unS2EVnJMyMLy3FxHtJ4Usy4PHXKn9K55ZfgrxjKCvra++u+u7fne4cz1t2/ A62f4iQagsMOq6N59rBqgvY4YrkR4iVSI7fJQ/Ku4845BPTORBqnji11zS7yz1bS5ZfOvhdxSwSW 1u6cENvMduPMZgTljjnbxwc8dRWUclwEJKUadmttXprfTXS/W260ehXtJdzpvGfjKfxZqDTCTU4r ZpGl+x3eom5iick/6sbFCAA4AwfrWHpeoS6Tq1rqFuFaW2lWVVccMQc4Psaq0V20cHQoUFhqcbQt a3l+ZMpOTuztIfHkOm6fBY6Ja6pDaR3sN19lu9V8+FRHIZNqII025bBJOenrzUOs/EC71XTfssNu bKSLUvtlrPDNhreNVIjiXAH3NxIYY6niuRorkjk+BjP2ip63vdtvXzu9fmV7ST/r+u50ereOtf1a 3sIptX1LFpGmd97I3mSq7MsvXhhkAHkjaOap3fizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkVT vdOlsIrOSZkYXluLiPaTwpZlweOuVP6VUrajgsFGC9lTjZXtovmLml36fga934s8R36xLfa/qlyI ZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZFFarB4ZWtTjpto tBc0u5r3fizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkUXfizxHfrEt9r+qXIhlWaITXsj7JF+6 4yeGHYjkVkUULB4ZWtTjptotA5pdzXu/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIou/FniO/ WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIrIooWDwytanHTbRaBzS7mvd+LPEd+sS32v6pciGVZohNe yPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWRRQsHhla1OOm2i0Dml3Ne 58XeJL0RC88QarcCGUTRebeyN5bjo4yeGGTgjmrGu+NNa1/T7SzvtSv5YIYRHLHNePIszhmbzCDx nDAc5+71rArR1bSf7Lj09vO837bZrdY2bdm5mG3qc/d68daxeFwUKsP3cVJX5dPvGpS116fgZ1T3 F9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUUaeZIqblXcQNzHAHua6LxT4Iv/AAlb2cuoz2xa6jV1 iSdHbkEnAVmyo+X5jjO4Yzg42qYjDwrQpVJLnlflXV23t+okm72ObooorqEFFFFABRRWpe6ZDYeH 7C4naT7dfM0qRZG1LcHarEYzlmD456KDzuGM51IwlGL3k7L7r/oCVzLp8M0ttcRz28jxTRMHjkjY qyMDkEEdCD3rRvdMhsPD9hcTtJ9uvmaVIsjaluDtViMZyzB8c9FB53DGXShUhWi2tVqvu0YNWNe7 8WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecii78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Eci siislg8MrWpx020Wg+aXc17vxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKLvxZ4jv1iW+1/VL kQyrNEJr2R9ki/dcZPDDsRyKyKKFg8MrWpx020Wgc0u5r3fizxHfrEt9r+qXIhlWaITXsj7JF+64 yeGHYjkVHqPibXtYthbatreo30AYOIrm7kkUMMgHDEjPJ596zKKccJhoNONOKttotPQOaXcKKltj ALuE3iyNbiRfNWIgOUz8wUkEA4zjIrQ1TTING8TNaXTST2KSq6yQsA01u2GV1JGAWQgjI4zyKuVa MZ8nW1/W2/6feK2lzKorQ13S/wCx9auLNZPNhUh4Jh0liYBo3H+8pU/jWfV06kakFOOz1Q2rOwUU UVYgooooAKKKKACiird7p0thFZyTMjC8txcR7SeFLMuDx1yp/Spc4pqLerAqUUUVQBRRRQAUVbvd OlsIrOSZkYXluLiPaTwpZlweOuVP6VUqYzjNc0XoAUUUVQBRRVu906Wwis5JmRheW4uI9pPClmXB 465U/pUucU1FvVgVKnuL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKbim02tgCiird7p0thFZyT MjC8txcR7SeFLMuDx1yp/Sk5xTUW9WBe8Q39tfQ6MtrJ5httNjgl+Uja4dyRz14I5HFY1aOraT/Z cent53m/bbNbrGzbs3Mw29Tn7vXjrWdWGFVNUYqk7xG76ei/IKKt3unS2EVnJMyMLy3FxHtJ4Usy 4PHXKn9KqVvGcZrmi9BBRRRVAFFFFABRRRQBJb3E1pcR3FrLJDNEweOWNirIw5BBHIPvW/q3jrX9 Wt7CKbV9SxaRpnfeyN5kquzLL14YZAB5I2jmucormq4WhWnGpUgm47NrYabWxr3fizxHfrEt9r+q XIhlWaITXsj7JF+64yeGHYjkUXfizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkVTvdOlsIrOSZk YXluLiPaTwpZlweOuVP6VUqKeFwjSlCnGy20XzHzS7mvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ 4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWRVu906Wwis5JmRheW4uI9pPClmXB46 5U/pR9VwkHGPs4p620XzsHNJ9S5d+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRc+LvEl6Ihe eINVuBDKJovNvZG8tx0cZPDDJwRzWRRVLBYVWtTjptohc0u5v67401rX9PtLO+1K/lghhEcsc148 izOGZvMIPGcMBzn7vWsCiiroYelh4ezoxUV2QNt7hRRVu906Wwis5JmRheW4uI9pPClmXB465U/p WrnFNRb1YipRRRVAFFFFABRRRQAVs+Ib+2vodGW1k8w22mxwS/KRtcO5I568Ecjis2xsptRvobO1 8vzpm2IJJVjUn3ZiAPxNaV74U1bT7G8u7pLVYbG4FtPsvoHZZT/CFVyWPXoD91v7pxx1qmHVeHtJ pSWyutb6bb+nmNX1t/XX9DGqe4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KijTzJFTcq7iBuY4A9 zXReKfBF/wCErezl1Ge2LXUausSTo7cgk4Cs2VHy/McZ3DGcHFVMRh4VoUqklzyvyrq7b2/UEm72 ObooorqEFFFFAEtsIDdwi8aRbcyL5rRKC4TPzFQSATjOMmtDVNTg1nxM13dLJBYvKqLHCoLQ264V UUE4JVAAMnnHJqPVtJ/suPT287zfttmt1jZt2bmYbepz93rx1rOrmjGnXtWi+jSf5/kvuHqlbuaG u6p/bGtXF4sflQsQkEI6RRKAsaD/AHVCj8Kz6KK2pwjTgoR2WiBu7uFFFFWIKKKKACiiigArUvdT hv8Aw/YW86yfbrFmiSTA2vbk7lUnOcqxfHHRgONozl0VnOnGcoye8Xdfdb9QTsal7qcN/wCH7C3n WT7dYs0SSYG17cncqk5zlWL446MBxtGcuitHVtJ/suPT287zfttmt1jZt2bmYbepz93rx1rOHs6D VJdbtfm/zHqzOoooroEFFFFABRRRQBJb3E1pcR3FrLJDNEweOWNirIw5BBHIPvW/q3jrX9Wt7CKb V9SxaRpnfeyN5kquzLL14YZAB5I2jmucrak8NTHUNFsrWZZZtWgjlTeNixl3ZcE5PA25z+lcOJp4 R1I1K8VzK9m1sktRxbV7DLvxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKLvxZ4jv1iW+1/VLk QyrNEJr2R9ki/dcZPDDsRyKujw9ot/JFa6Br8t3fy3KW8cFzYGBZNxx5iuHYbR/tbT7dcQ3ek+Hv s5OleIpJ7gTrEIrqwMCuCceYHDsNo/2tp6cdcckZ5fdJUrNf9O5K1/8At3RPu7J69mU+bq/xILvx Z4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKLnxd4kvRELzxBqtwIZRNF5t7I3luOjjJ4YZOCOa3 9T8B2Wl6hZWl3qOqW8t1fC1UXOjGISL0M0TGTbIgYoOoOGBxVLWPCNto2k6jcTajNJcWl3FbxRpa r5U6SBnSQSeZkAojEjaSDgepGNHFZTUcFTitdvcfV2093a+je3cbU9blXXfGmta/p9pZ32pX8sEM IjljmvHkWZwzN5hB4zhgOc/d61gVbvdOlsIrOSZkYXluLiPaTwpZlweOuVP6VUr1sLSoUaSjh0lH yIbbtcKKKfDGstxHG8qQq7BWlkBKoCfvHaCcDrwCfY10N2VxC29xNaXEdxayyQzRMHjljYqyMOQQ RyD71v6t461/Vrewim1fUsWkaZ33sjeZKrsyy9eGGQAeSNo5rO1jQL/Q5I/tiI8E+4293A4khuAD glHHDYyMjqM4IB4qa50SKzu9HjuLp/K1G3jnd0hBaIM7KQFLDcRtz1GfavOqfUazhWmlJ2dna+29 v6/Ed3G/p+Al34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+ yRfuuMnhh2I5FaWseFNNsZNRFhq9zdjSLryNQWWxWJ0TzPL8yMCVg43cYJU/MvqSH674S03S31NL PV7u5bSbtba882wWIYLMu6MiVtxyp4O3I+hxywr5W3FRgvL3GrXt/d0vzLe17o0caivf8zKufF3i S9EQvPEGq3AhlE0Xm3sjeW46OMnhhk4I5qxrvjTWtf0+0s77Ur+WCGERyxzXjyLM4Zm8wg8ZwwHO fu9aPEeiaVo9rYPp+p3l5LewLcqk9ikKrGSw5Ilf5sr0xjB69qo6tpP9lx6e3neb9ts1usbNuzcz Db1Ofu9eOtbUYZfVdOpTgr68vu29dGlYm809+n4FjxDf219Doy2snmG202OCX5SNrh3JHPXgjkcV lW9xNaXEdxayyQzRMHjljYqyMOQQRyD71an0t7V9P+0zwxR30SzLIdxWNC7JlsAnjaTwDx0yeKk1 jQL/AEOSP7YiPBPuNvdwOJIbgA4JRxw2MjI6jOCAeK6aMsPCEaCle97X69/XzJ1av5I0dW8da/q1 vYRTavqWLSNM772RvMlV2ZZevDDIAPJG0c1Tu/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIps Ph29uNQ0qzhMTS6oivB8xwoZ2T5jjjBUk9eK0l8J22qgr4U1T+05o5lhljuYVtM7jhHRnkIZS3y/ NsbLL8vPHF/wl4ZKPLFJa35dFd9Xa0bu61auVeTW/T8DPu/FniO/WJb7X9UuRDKs0QmvZH2SL91x k8MOxHIou/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIqW+8Ha1ppUXsNvHmcW7kXsDCCQ5wsu HPlHg/f2/dPoaZrnha/8P3ptr2fT5HExhzb6hDL8w7lQ25B7sBWlOWVylGNPkb1tbl+dv1G/aK97 jbvxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKLvxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDs RyKsXHhDUE1yw0i1Ec15fQLJEpuYNjkkjCSLIyMPlwOQSeMdMt1LwXrmk232i/toY4t6puW8hfqS A3yufl3AqW+6GBUnIIpRnlV4Ri6d3rFe7ez7Lz/EXv67kN34s8R36xLfa/qlyIZVmiE17I+yRfuu Mnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FJq3h650rULOybEk11Cki7ZInRixIG 143ZWXI65H0FT6j4L1zS7eGa5t7d0nufskf2a9huGabum2N2ORxnjjI9RVReWLktyK/w/Cr97f8A AD39SG78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecii58XeJL0RC88QarcCGUTRebeyN5bjo4y eGGTgjmlv/C2q6asT3SWpjlm+z+bDewzRxyf3XdHKxnqfmI4BPY4fq3g/W9DtTcanaxxRgK3y3UT sUb7sgVWJKHoHA2k8ZzRF5W3BR9nrfl+HXvb9bB7/mSa7401rX9PtLO+1K/lghhEcsc148izOGZv MIPGcMBzn7vWsCrd7p0thFZyTMjC8txcR7SeFLMuDx1yp/Sq8May3EcbypCrsFaWQEqgJ+8doJwO vAJ9jXXh6dChStQilHXZfeS23a4tvcTWlxHcWsskM0TB45Y2KsjDkEEcg+9b+reOtf1a3sIptX1L FpGmd97I3mSq7MsvXhhkAHkjaOaztY0C/wBDkj+2IjwT7jb3cDiSG4AOCUccNjIyOozggHirEvhq b7fo1nazLLNq0Ecqbl2CMu7LgnJ4G3Of0rnqPA1nCvPllo7PfRb6jXMm0uwy78WeI79Ylvtf1S5E MqzRCa9kfZIv3XGTww7Ecii78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecipr3SdBFpIdJ8QTX l2kgjW3l08w+dkgbkbew29T8209Pl5OK+oeGdU01YWmhhmSeUwxvZ3MVypk4+TMTMA3I+U81FP8A s98qUIxetk48r87KST9bDfP3HXfizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkUXfizxHfrEt9r +qXIhlWaITXsj7JF+64yeGHYjkVfXwLqlvJFJqqpBZfaktbia2nhuXt5GOArRrJkN1+VsHg+lQa3 4M1fRLzyJoFmD3RtY/JljkcyfwqyIxMbEchWwevoazp1cplNQpuF9bW5fnZ7eqWvV7h79m3f+v6Z XufF3iS9EQvPEGq3AhlE0Xm3sjeW46OMnhhk4I5qxrvjTWtf0+0s77Ur+WCGERyxzXjyLM4Zm8wg 8ZwwHOfu9aq6r4a1PRrdbi9jgaEyGIy213FcKj4zsYxswVsZIDYJwcdDVW906Wwis5JmRheW4uI9 pPClmXB465U/pW1Ojl83CpSjF2vytW+drCvNN37fgVKKKK9MkKKKKACiiigArc8QeJ5det7SJ4Fg 8vMtwytk3NwwAeZvchV49cnvWHVu906Wwis5JmRheW4uI9pPClmXB465U/pXPUp0ZVYTmveV7fdq NN7IqVPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelQUVu4ptNrYQUUUUwCinwxrLcRxvKkKuwVpZ ASqAn7x2gnA68An2NX9Y0C/0OSP7YiPBPuNvdwOJIbgA4JRxw2MjI6jOCAeKylWpxmqbdm9l39O4 WZP4hv7a+h0ZbWTzDbabHBL8pG1w7kjnrwRyOKxqt3unS2EVnJMyMLy3FxHtJ4Usy4PHXKn9KqVO HhCFJRpu6B9PRfkFFOjCGVBMzLGWG5lXcQO5AyMn2yK6TVfDFhBJpdvoup3N7d6nGksSXdrFaoqM WAy5mYBsr0OBz17VNXFUqM1Co7Xv0dtN7u1l82hpNnM0Vt6j4P1nSZIkv4baIyT/AGYkXsDCKX+5 IQ5ER/39vQ+ho1nwlqWiaiLKdrK5nac26JZXsU7M+cY2Ixdcn+8BURx2Fm4qNSLvdrVa23t6DcZL dGJRWxf+FtV01YnuktTHLN9n82G9hmjjk/uu6OVjPU/MRwCexxaufAfiGzkiS6tbeJpmQRhr6D5g /wBx/v8A+rJ4D/dJ4znik8wwaSbqx1vb3lrbe2vTqLll2Odorb1LwhrekyRpeWiGSSf7MI7e4inZ Zv8AnmyxsxR/9lsHg+hpt74U1bT/ACTcJaGOWb7OJor+CWOOT+67q5WM9T85HAJ7HFRx2Fkk41Yu +2q1tvbXoDjJboxqK2Nf8MX3hu6eC/msJWSVoj9lvopjkeqqxZf+BAVj1tRrU68FUpSUovqgaadm FbPiG/tr6HRltZPMNtpscEvykbXDuSOevBHI4rGrR1bSf7Lj09vO837bZrdY2bdm5mG3qc/d68da zqKm60HJ+9rb9QV9bdv1RnUUUV0iCiiigAooooAK6S+1+ODUPDl9prrLNpllCrq6kASJI7FT0yME dPWubq3e6dLYRWckzIwvLcXEe0nhSzLg8dcqf0rlrUqVScfaeat3utfwBdbdv1R1Efj5dM0yOx8P 2+pW9ul1HcC3vdU+0QKEcvtWMRptBY5Jyc49eajfxnYxaKuj2dhqn9lPdRTT2N3q5liMauXaNAsa bNxPLcnv15rkKK5P7HwV78mt7/FLfvvq10e66F+0kdXD4p0iwWCDTNHvorNdQivpoZtSWQs0YYIq HyRs++ckhiQB6U3UPGsk+kPYWFvNabNRS9tLk3O6a3CiT93uVVyA8rMCACCT1zxy1FWsrwnNzuN3 5uT++7d/n002Fzv+v68zo9W8da/q1vYRTavqWLSNM772RvMlV2ZZevDDIAPJG0c1Tu/FniO/WJb7 X9UuRDKs0QmvZH2SL91xk8MOxHIqne6dLYRWckzIwvLcXEe0nhSzLg8dcqf0qpV0cFgowXsqcbK9 tF8w5pd+n4Gvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+J9Z1ZYoNf1jVNSsllWR7ea9 ds49N24BsEgHBxnoelZFPhjWW4jjeVIVdgrSyAlUBP3jtBOB14BPsa0+qYaCTVNK21lqvS2v3C5p dzX1TxE91ZDTNJt/7L0kcm0jlZjO39+ZuPMbgdgo/hVcnM2qarYzXPh+Rd9zHZWMUdxGhMbblkdi oYqQDgjnBHPeqOsaBf6HJH9sRHgn3G3u4HEkNwAcEo44bGRkdRnBAPFQXunS2EVnJMyMLy3FxHtJ 4Usy4PHXKn9K56dHCTjB03o72s977tvdvzvcHfVPt+Ghvav4q0y+k1NrHSbu1OsXQmvzLfrKWTzD IY48RLsBYg5O77q++U8X+MpPFeqCaRtVWyaYzNY3Op+ekZJPEXyAIMHA4OP0rl6KqnlmEpzjUjHW N7NtvdJPd9klfdW0KdSTvfqb/iPW9K1i1sE0/TLyzlsoFt1ee+SZWjBY8gRJ82W65xgdO9N1rV0k fQptLupEnsdPijaSPcjRSq7ng8cjIORWFVu906Wwis5JmRheW4uI9pPClmXB465U/pVRwmHpckF0 vZNt3vvvd/iLmbfy/DT/AIBsat411XXbewtNXv8AUrmzgjRLiF752+0EOzF/mBAbDYBIbGB16VFe eKrkRxWnh9ZNFsIXEiQ207b5JAQRLLJwXcYGDgKuPlVcnNLVtJ/suPT287zfttmt1jZt2bmYbepz 93rx1rOqKGDwTpxdKC5Vey6ettr+drg5S69jqrn4i+IrmXS5H1O+k+wKhaO4u3ljnkV2beyk4PDB ec8DrVjR/EWi2+s2Uen2X9i2st9FcX1xc3DXOI43DiNAse5VyOhDsSFy2Ac8xe6dLYRWckzIwvLc XEe0nhSzLg8dcqf0qpWf9l4KpS5aceVNNe7p36bNp6q6dmDk2tex1fibWdGEmqWnh6CQi/uFlmuz dtLG6gl9savDG6jcwzu3H5cZPU1Na13SNXujdf2JNDc3NwJ72U324t/eWIbAIwSSfmEhHy4PBzz9 FbUsvoU1G17rrzSu7pJ3112XkraWHKo5O52a+MNCi1jRNQg0HURJo4jWNX1VCJFQswBxbjncwyfQ YxzkQS+LdLn0lNOl0e88lbZbXK6goYok7Sqc+TjOHKnjng4HSuTorJZRg007PS1vel0ba+13bFzv 9P6+46PXdd0TVYdPW20i/t2sokt8y6ikgeJSxIwIVwx3fezgelXNW8Z2E95YXuiaRcafc6dPFJaL LfCaG3jjJPloixpwzEMzMWYkdckk8hRVrK8LaKs7Rva8pPffd638w5mdZr/jGLXoI4bhvEUkIuFl kgu9dNxFtGchFaLKtg4DEtjuDVPXdfsb/UodR0Wzv9MvYvLAlbUFkx5aKqldsSFW+UHOTz6Vz9FV Ry3C0eX2cWrXW8ra73V7O9utwc5Pc6PVvHWv6tb2EU2r6li0jTO+9kbzJVdmWXrwwyADyRtHNU7v xPrOrLFBr+sapqVksqyPbzXrtnHpu3ANgkA4OM9D0qne6dLYRWckzIwvLcXEe0nhSzLg8dcqf0qp To4PBxgvZQSSvay272e6Dml36fgbWqeInurIaZpNv/Zekjk2kcrMZ2/vzNx5jcDsFH8Krk5s3+vp BfeHb7SpFkn02yhVg6HaJFkdtpBxkYI6cc1zlW73TpbCKzkmZGF5bi4j2k8KWZcHjrlT+lH1PDRc YW76d7rW99W/Nu4ru79P1Rrf214ftbqG50zw24kS5jnZb6+M8YVWyY1UInynod+/gfUnX1X4i/br OzWODVJbuyv0voLnU9V+1bXX+Hb5agLwOFx368AcPRWc8pwlScZzi247Nyk/zf4MfPJbHRDWfDkF 3FPZeHrqMrcJM/manvKKpzsjxEAoJxy4c4AxzkmyfGFrb+fNpum3MF42rJqcEsl4rrGyEkKVEalh 8zc5Hb0OefvdOlsIrOSZkYXluLiPaTwpZlweOuVP6VUoWX4SquZ3kvOUn+bDmf8AXp/kzrde8cTa rDH9lu/EUM0dws8f2vXWuYomGcFFMasCM8NuJAz1zmqOu+NNa1/T7SzvtSv5YIYRHLHNePIszhmb zCDxnDAc5+71rAq3e6dLYRWckzIwvLcXEe0nhSzLg8dcqf0op5fgaDgowV1flvq/PV3Y+eTe/T8C pRRRXpkBRRRQAUUUUASW9xNaXEdxayyQzRMHjljYqyMOQQRyD71v6t461/Vrewim1fUsWkaZ33sj eZKrsyy9eGGQAeSNo5rno4zLKkalQzsFBZgo59SeAPc1ra1o1lp1vHJp+sW+o7X8m4VAEMcoGTsB JMkZ5AkAHIOQMru4a9PCzrw9rFOettL2+drLyvv0HG6vYS78WeI79Ylvtf1S5EMqzRCa9kfZIv3X GTww7Ecii78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7EcisqNPMkVNyruIG5jgD3NdF4p8EX/hK 3s5dRnti11GrrEk6O3IJOArNlR8vzHGdwxnBxnKGX0asKMoxUpX5VZX87afeNOcr2KV34s8R36xL fa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZFFdCweG VrU46baLQXNLua934n1nVlig1/WNU1KyWVZHt5r12zj03bgGwSAcHGeh6VPeeKrkRxWnh9ZNFsIX EiQ207b5JAQRLLJwXcYGDgKuPlVcnODRU/UcNp7istl09bbX87XDmZv67401rX9PtLO+1K/lghhE csc148izOGZvMIPGcMBzn7vWsCtHVtJ/suPT287zfttmt1jZt2bmYbepz93rx1rOqsJTw9Oilhkl HyVgbbtcdGUEqGZWaMMNyq20kdwDg4Pvg109/wCJdEurvR5oNG1CL+zFji2vqSP5saMzAcQDDZbr yMDp3rlqKK2EpV5KVS91dbtb6PZoV7X8zotT8Q6de6XqVrBpl1DLeagL1ZHvVdY+GG0qIhu++3OR 2445kv8AxXaSavDrOl6S1rqwvEvZbiW7Mq+YpzhECrtUtkkMXPQAjnPM0Vl/Z+G7Pr9qXW1766rR aPQpzb3/AK/q51mv+MYtegjhuG8RSQi4WWSC7103EW0ZyEVosq2DgMS2O4NQ6j4h0W816z1ODSL+ FoXi82N9RRxIsaqqhSIRtPyjJO7vxXM0VFPK8JTiowi0kmviltLfr/XQJTctzqz4wtbfz5tN025g vG1ZNTglkvFdY2QkhSojUsPmbnI7ehy3xL4w/wCEgsPs/m6+f3wl8q/1s3cC8HhUMYIIzwSxIGeu c1y1FEcrwkasaqj7y2d2/wA2P2kv6/rzN3xBrmm6y8tzbaO9tf3U3nXNxJdmUbsciNAqhVJJJDbz 0wRznCoorsoUIUKap072Xdt/m2yW29wrZ8Q39tfQ6MtrJ5httNjgl+Uja4dyRz14I5HFY1aOraT/ AGXHp7ed5v22zW6xs27NzMNvU5+71461FRU3Wg5P3tbfqCvrbt+qM6iiiukQUUUUAFFFFAElvcTW lxHcWsskM0TB45Y2KsjDkEEcg+9b+reOtf1a3sIptX1LFpGmd97I3mSq7MsvXhhkAHkjaOa5yiua rhaFacalSCbjs2thptbGvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pci GVZohNeyPskX7rjJ4YdiORWRRSWDwytanHTbRaBzS7mvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ 4YdiORRc+LvEl6IheeINVuBDKJovNvZG8tx0cZPDDJwRzWRRQsFhVa1OOm2iDml3Oj1bx1r+rW9h FNq+pYtI0zvvZG8yVXZll68MMgA8kbRzVO78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecisiio p4DCU0lCnFW20XUfNLua934s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34n1nVlig1/WNU1K yWVZHt5r12zj03bgGwSAcHGeh6VkUVaweGjblppW2skrenb5C5pdzevPFVyI4rTw+smi2ELiRIba dt8kgIIllk4LuMDBwFXHyquTmXVvHWv6tb2EU2r6li0jTO+9kbzJVdmWXrwwyADyRtHNc5Wpe6ZD YeH7C4naT7dfM0qRZG1LcHarEYzlmD456KDzuGOeWDwVOcL005Xdr6u9rttvV+bf5jTlrYfd+LPE d+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWVGn mSKm5V3EDcxwB7mui8U+CL/wlb2cuoz2xa6jV1iSdHbkEnAVmyo+X5jjO4Yzg4JQy+jVhRlGKlK/ KrK/nbT7wTnK9ilc+LvEl6IheeINVuBDKJovNvZG8tx0cZPDDJwRzVjXfGmta/p9pZ32pX8sEMIj ljmvHkWZwzN5hB4zhgOc/d61gUVssDhVKM1TinHbRaBzS7mz4hv7a+h0ZbWTzDbabHBL8pG1w7kj nrwRyOKyre4mtLiO4tZZIZomDxyxsVZGHIII5B96u6tpP9lx6e3neb9ts1usbNuzczDb1Ofu9eOt Z1Vho0vYKMNY+YnfT0X5HR6t461/Vrewim1fUsWkaZ33sjeZKrsyy9eGGQAeSNo5qnd+LPEd+sS3 2v6pciGVZohNeyPskX7rjJ4YdiORWRRUU8BhKaShTirbaLqPml3Ne78WeI79Ylvtf1S5EMqzRCa9 kfZIv3XGTww7Ecii78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7EcisiirWDwytanHTbRaC5pdzX u/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIou/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxH IrIooWDwytanHTbRaBzS7mvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6p ciGVZohNeyPskX7rjJ4YdiORWRRQsHhla1OOm2i0Dml3Ne78WeI79Ylvtf1S5EMqzRCa9kfZIv3X GTww7Ecii58XeJL0RC88QarcCGUTRebeyN5bjo4yeGGTgjmsiihYLCq1qcdNtEHNLub+u+NNa1/T 7SzvtSv5YIYRHLHNePIszhmbzCDxnDAc5+71rAooq6GHpYeHs6MVFdkDbe5Jb3E1pcR3FrLJDNEw eOWNirIw5BBHIPvW/q3jrX9Wt7CKbV9SxaRpnfeyN5kquzLL14YZAB5I2jmucoqauFoVpxqVIJuO za2BNrY17vxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKLnxd4kvRELzxBqtwIZRNF5t7I3luO jjJ4YZOCOayKKSwWFVrU46baIOaXc6PVvHWv6tb2EU2r6li0jTO+9kbzJVdmWXrwwyADyRtHNU7v xZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKj1LRxpx0zddKVv7VLkuyECLczLg4ySBtzkD8Ks6 voum2ulRaho+rSX0LXL2zCe18hiyqrbkG5tyYYcnBGRlRkVxUqeXw9nGnTWt+X3dPPW2nzauVeT6 9PwIrnxd4kvRELzxBqtwIZRNF5t7I3luOjjJ4YZOCOasa7401rX9PtLO+1K/lghhEcsc148izOGZ vMIPGcMBzn7vWsCiutYHCqUZqnFOO2i0FzS7hRRRXYSFFFFABRRRQAUUVo6tpP8AZcent53m/bbN brGzbs3Mw29Tn7vXjrUSqRjJQb1e3yDczqnuL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoo08yRU 3Ku4gbmOAPc10XinwRf+Erezl1Ge2LXUausSTo7cgk4Cs2VHy/McZ3DGcHGFTEYeFaFKpJc8r8q6 u29v1Gk3exzdFFFdQgooooA2fEN/bX0OjLayeYbbTY4JflI2uHckc9eCORxWNUtsYBdwm8WRrcSL 5qxEBymfmCkggHGcZFaGqaZBo3iZrS6aSexSVXWSFgGmt2wyupIwCyEEZHGeRXJT5MOlQjd2Ta89 dfzX3j1av2sZVFaGu6X/AGPrVxZrJ5sKkPBMOksTANG4/wB5Sp/Gs+uinUjUgpx2eqBqzsFFFFWI KKKKACiiigAoorUvdMhsPD9hcTtJ9uvmaVIsjaluDtViMZyzB8c9FB53DGc6kYSjF7ydl91/0BK5 l1s+Ib+2vodGW1k8w22mxwS/KRtcO5I568Ecjior3TIbDw/YXE7Sfbr5mlSLI2pbg7VYjGcswfHP RQedwxl1jFU68o1l9m6/R/kPVfMKKKK6hBRRRQAUUUUAFFFFABRRRQAUUUUAFFS2ltJe3kNrAAZZ 5FjQE4yxOB/OtnWdAsrHT5brS9Skvltbv7HdeZa+SFkIYqU+ZtynY/JCngZUZrnniKVOpGnJ6vyf 4vZX6XtfoCTZg0UUV0AS2wgN3CLxpFtzIvmtEoLhM/MVBIBOM4yat67qn9sa1cXix+VCxCQQjpFE oCxoP91Qo/CpL3TIbDw/YXE7Sfbr5mlSLI2pbg7VYjGcswfHPRQedwxl1zU/Z1Z+2j0uvx1+9r8B 6pWCp7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qKNPMkVNyruIG5jgD3NdF4p8EX/hK3s5dRnti 11GrrEk6O3IJOArNlR8vzHGdwxnBwqmIw8K0KVSS55X5V1dt7fqCTd7HN0UUV1CNnxDf219Doy2s nmG202OCX5SNrh3JHPXgjkcVjVo6tpP9lx6e3neb9ts1usbNuzczDb1Ofu9eOtZ1c2FVNUYqk7xG 76ei/IKKKK6RBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRU9jZTajfQ2dr5fnTNsQSSrGpPuzEA fiamUowi5SdkgNnVdT065uNAZka8gs7GKK6hVjEWKyOWTcRxkEcgHrS+KvEVhr7QGwsLuwSDKxW7 3iSQQxnnZGixJt56kkk9SSear3vhTVtPsby7uktVhsbgW0+y+gdllP8ACFVyWPXoD91v7pxjV52H w+Em4VaUuZwuk1K6V9Xona+va9rFNyWj9Pu0CiiivTJCiiigAooooAKKKKACtnxDf219Doy2snmG 202OCX5SNrh3JHPXgjkcVjVo6tpP9lx6e3neb9ts1usbNuzczDb1Ofu9eOtc1RU3Wg5P3tbfqNX1 t2/VGdU9xfXd4MXd1NOPMaXEshb52xubnudoye+B6VFGnmSKm5V3EDcxwB7mui8U+CL/AMJW9nLq M9sWuo1dYknR25BJwFZsqPl+Y4zuGM4OFUxGHhWhSqSXPK/Kurtvb9QSbvY5uiiiuoQUUUUAFal7 qcN/4fsLedZPt1izRJJgbXtydyqTnOVYvjjowHG0Zy6KznTjOUZPeLuvut+oJ2NS91OG/wDD9hbz rJ9usWaJJMDa9uTuVSc5yrF8cdGA42jOXRRRTpxpR5Y7Xb+93Bu4UUUVoAUUUUAFFFFAEtsIDdwi 8aRbcyL5rRKC4TPzFQSATjOMmtDVNTg1nxM13dLJBYvKqLHCoLQ264VUUE4JVAAMnnHJrKorGVGM p8/W1vS+/wCn3BfSxoa7qn9sa1cXix+VCxCQQjpFEoCxoP8AdUKPwrPooq6cI04KEdloht3dwooo qxBRRRQAUUUUAFFFFABRRVu906Wwis5JmRheW4uI9pPClmXB465U/pUucU1FvVgVKKKKoCW1uZLO 7huYDtlhdZEOM4YHI/UVta14gsr6xltdK02axS6u/tlz510JtzgMFCYRNqje/ByeRzxWBRXPPD0q lSNSS1Xm/wAVs7dL3t0Gm0FS2wgN3CLxpFtzIvmtEoLhM/MVBIBOM4yaioreSumiTQ13VP7Y1q4v Fj8qFiEghHSKJQFjQf7qhR+FZ9W73TpbCKzkmZGF5bi4j2k8KWZcHjrlT+lVKzoqmqajT+FaL5aF Ntu4VPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelRRp5kipuVdxA3McAe5rovFPgi/8ACVvZy6jP bFrqNXWJJ0duQScBWbKj5fmOM7hjODjKpiMPCtClUkueV+VdXbe36gk3exzdFFFdQjZ8Q39tfQ6M trJ5httNjgl+Uja4dyRz14I5HFY1aOraT/Zcent53m/bbNbrGzbs3Mw29Tn7vXjrWdXNhVTVGKpO 8Ru+novyCiiiukQUUU6NQ8qIzrGrMAXbOF9zgE4+gNDdlcBtFdH4g8LRaPo9rqNtd3U0NxIUQ3di bbzxtBEsOWJkj/2iFIyvHPHOVhh8RSxNP2lJ3Xo1to9HZjaa3CiiitxBRRRQAUUVbvdOlsIrOSZk YXluLiPaTwpZlweOuVP6VLnFNRb1YFSiiiqAKKKKANzxB4nl163tIngWDy8y3DK2Tc3DAB5m9yFX j1ye9YdFW73TpbCKzkmZGF5bi4j2k8KWZcHjrlT+lc9KnRw0Y0aastbL8WO7bKlFFFdAgoq3e6dL YRWckzIwvLcXEe0nhSzLg8dcqf0qpUxnGa5ovQAoooqgCiird7p0thFZyTMjC8txcR7SeFLMuDx1 yp/Spc4pqLerAqVs+Ib+2vodGW1k8w22mxwS/KRtcO5I568EcjisatHVtJ/suPT287zfttmt1jZt 2bmYbepz93rx1rCoqbrQcn72tv1Gr627fqjOqe4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KijTz JFTcq7iBuY4A9zXReKfBF/4St7OXUZ7YtdRq6xJOjtyCTgKzZUfL8xxncMZwcKpiMPCtClUkueV+ VdXbe36gk3exzdFFFdQgooooAKKKKACnwzS21xHPbyPFNEweOSNirIwOQQR0IPemUUmk1Zga934s 8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZF FcyweGVrU46baLQfNLua934s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyI ZVmiE17I+yRfuuMnhh2I5FZFFCweGVrU46baLQOaXc17vxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZP DDsRyKj1HxNr2sWwttW1vUb6AMHEVzdySKGGQDhiRnk8+9ZlFOOEw0GnGnFW20WnoHNLuFFFFdIg ooooAKKKKACiiigAooooAKKKKAJLe4mtLiO4tZZIZomDxyxsVZGHIII5B9639W8da/q1vYRTavqW LSNM772RvMlV2ZZevDDIAPJG0c1zlakWildQ0mG9n8qHUlSRZIU8xo0Zyn3SVycqeM/jXFiaWFcl VrxTcb2bV3tqCbV7dh934s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZV miE17I+yRfuuMnhh2I5FX9e8K2unQSS6TqFxeiDUG0+YXFmLc+aAcFCHcMvBzyCPlyPmqhe+FtWs Wtg8EVx9qm8iJrK5iug0vH7vMTMA3I+U8muWjLLJxi4qK3tdKL87JpP10NHzq9wu/FniO/WJb7X9 UuRDKs0QmvZH2SL91xk8MOxHIou/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIq7f+DLvTPDja leTRCUX6WYSGeGaLLIzcypIQrDZyrAYDKc81Vv8Awxd2WrWGmqY3uL2FJEJuIPLYsSBtlWRkK5HU kfQUqVTK529nyaXtounxW8tdXsJ86vcZd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRc+LvE l6IheeINVuBDKJovNvZG8tx0cZPDDJwRzUU+galb2f2mSFDGLk2hWOZHdZRn5SiksM7TgkYOOM1P qnhPV9G0831/Dbi3WcWzvDeQzbJcE7GCOSrYU8EDpWqjlqlGK5L6pL3d+qX62D3/ADJtd8aa1r+n 2lnfalfywQwiOWOa8eRZnDM3mEHjOGA5z93rWBVu906Wwis5JmRheW4uI9pPClmXB465U/pVSurC 0qFGko4dJR8iW27XCp7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qKNPMkVNyruIG5jgD3NdF4p8 EX/hK3s5dRnti11GrrEk6O3IJOArNlR8vzHGdwxnBwqmIw8K0KVSS55X5V1dt7fqCTd7HN0UUV1C NnxDf219Doy2snmG202OCX5SNrh3JHPXgjkcVjVbvdOlsIrOSZkYXluLiPaTwpZlweOuVP6VUrDD whCko03dA+novyCiiitwCnxOscyO8ayqrAmNydrj0OCDg+xB96ZRSaurAb2qa5p02inS9E0u4sbe S6F1L9pvftB3BSqqmEQKuGbOQxPy5PFYNFFZUaEKEeWHrq2397bY22wooorYQUUU+GNZbiON5UhV 2CtLICVQE/eO0E4HXgE+xpN2VwFt7ia0uI7i1lkhmiYPHLGxVkYcggjkH3rf1bx1r+rW9hFNq+pY tI0zvvZG8yVXZll68MMgA8kbRzWdrGgX+hyR/bER4J9xt7uBxJDcAHBKOOGxkZHUZwQDxTovD95N f6VZxNEZdVRHg+YgKGdkG4kccqSevFefUWBrcuInyytez0enUa5otpf0h934s8R36xLfa/qlyIZV miE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FS32l+H0s3fSfEE11d LMIhBcWHkCQH+NX3sAv+9tPI464ra5okuhXFtBcMGea3WfcskUiHJI+V43dWXjrkH2FRSWAnKMYw Setk48r87JpO2u5T5+5Jd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciG VZohNeyPskX7rjJ4YdiORWXEI2mQTsyRFhvZF3Mq55IBIyfbI+tegXXw102x1q202+1jVbWW8nMN o8+joFuSHVcpicnHzAgsACM4JPFZYqpluClGNWCTabVoN6Le1k/V+WoLnkm0cnc+LvEl6IheeINV uBDKJovNvZG8tx0cZPDDJwRzVjXfGmta/p9pZ32pX8sEMIjljmvHkWZwzN5hB4zhgOc/d61Y1Hwn bad4en1KS8u0fMD2kM1oii4hm3lHLLK204jkJXBxgc88Yd7p0thFZyTMjC8txcR7SeFLMuDx1yp/ SroQy6tKM6UY3i3b3ba2u7aLo9/1Buae/T8LlSpLe4mtLiO4tZZIZomDxyxsVZGHIII5B96SGNZb iON5UhV2CtLICVQE/eO0E4HXgE+xq/rGgX+hyR/bER4J9xt7uBxJDcAHBKOOGxkZHUZwQDxXoTqU uZUptXl0fXv6+ZFjR1bx1r+rW9hFNq+pYtI0zvvZG8yVXZll68MMgA8kbRzVO78WeI79Ylvtf1S5 EMqzRCa9kfZIv3XGTww7Ecip18Owpq2h2lzeukerQxSmSOAMYd7soG0sN2COuR1q9qXg+x0iwvZ7 7VLnfa30NuBDZK6SxShmWVWMo/gRjtx97CkjkjyIzyqi4U4wXlaLe7t277/K/Qv32t+35afgZV34 s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5Fa es+E9N0fWLGGTW5Dp07GO4uns8PbSqFLxmJXbJUOnRupPpmotf8AD+iaTpsM1nrl1cXU8MVxFbz6 cIg0b553LK4BGOQfXgmqpVstm6apw+L4f3b72evLp53tbqO09dfxKNz4u8SXoiF54g1W4EMomi82 9kby3HRxk8MMnBHNWNd8aa1r+n2lnfalfywQwiOWOa8eRZnDM3mEHjOGA5z93rWBVu906Wwis5Jm RheW4uI9pPClmXB465U/pXb9TwcakH7OKavy6L52J5pa69PwKlbPiG/tr6HRltZPMNtpscEvykbX DuSOevBHI4rGq3e6dLYRWckzIwvLcXEe0nhSzLg8dcqf0repCDqwlJ6q9v1JXW3b9UVKnuL67vBi 7uppx5jS4lkLfO2Nzc9ztGT3wPSoo08yRU3Ku4gbmOAPc10XinwRf+Erezl1Ge2LXUausSTo7cgk 4Cs2VHy/McZ3DGcHEVMRh4VoUqklzyvyrq7b2/UaTd7HN0UUV1CCiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAJLe4mtLiO4tZZIZomDxyxsVZGHIII5B966W68 e6tqUulLq17qV3aWQj8+3e/ci5ZZC+87gQGwQMkHpXLVbvdOlsIrOSZkYXluLiPaTwpZlweOuVP6 Vx4jC4WvOLrRTlql387ME3ql2Op1X4gjWdQ+0anp81+tvfLeWK3155xgBIMkLHYPMibaMLhdvvyD Pf8AxIF1b2YW21S4uLO+W9im1PVvtXI4Me0RqAhHZdpGTyeMcJRXH/YmAXLan8O2stL6Pr169223 qy/aTbbvudNNr3h7+wJdKs9C1CKOa8iunkk1RHb5Ay7R+4AwVd8HGQSCcgbSmr+I9Kvf7Lk03Sby 1uNNSOKNri/SZGRGZsFRCh3Et1zjA6VzVFbxy3DRlzWd9d5Se6s93rp3E5N38zrtQ8VaDd2ksEXh y5RZ9RW/m8zU9/mEFt0fES4UqxAxhgTkluAE17xzLqlnbw2TasktvdC5iudQ1Q3csBAICxPsQxjn J65Kp0288lRUxyrCRlGXK243teUnvvu2P2kv6/rzN/XfGmta/p9pZ32pX8sEMIjljmvHkWZwzN5h B4zhgOc/d61gVbvdOlsIrOSZkYXluLiPaTwpZlweOuVP6VUrqwtKhRpKOHSUfIltu1wqe4vru8GL u6mnHmNLiWQt87Y3Nz3O0ZPfA9KijTzJFTcq7iBuY4A9zXReKfBF/wCErezl1Ge2LXUausSTo7cg k4Cs2VHy/McZ3DGcHCqYjDwrQpVJLnlflXV23t+oJN3sc3UlvcTWlxHcWsskM0TB45Y2KsjDkEEc g+9R0V0tKSsxHR6t461/Vrewim1fUsWkaZ33sjeZKrsyy9eGGQAeSNo5qnd+LPEd+sS32v6pciGV ZohNeyPskX7rjJ4YdiORWRRXHTwGEppKFOKttoupXNLua934s8R36xLfa/qlyIZVmiE17I+yRfuu Mnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZFFWsHhla1OOm2i0FzS7mvd+LPEd+ sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWRRQsH hla1OOm2i0Dml3Ne78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecii78WeI79Ylvtf1S5EMqzRC a9kfZIv3XGTww7EcisiihYPDK1qcdNtFoHNLua934s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5 FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZFFCweGVrU46baLQOaXc17vxZ4jv1iW+1/VL kQyrNEJr2R9ki/dcZPDDsRyKLvxPrOrLFBr+sapqVksqyPbzXrtnHpu3ANgkA4OM9D0rIooWDw0b ctNK21klb07fIOaXc3rzxVciOK08PrJothC4kSG2nbfJICCJZZOC7jAwcBVx8qrk5uXPxE1+6m0p 5tRvZ108Rlorm7eWO4dHZg7KT1wQPXA61ytW73TpbCKzkmZGF5bi4j2k8KWZcHjrlT+lc8svwV4x lBN62vq9d9Xq35vUfNLWx0Nz4vsz4dbQ9PtdXh02a4SSW2n1cSxqisWKxL5ShCSc7iG6Dg1T8Ra3 pGr2dlHYaXe2k1nAtujzX6TK0aljyohQ7st1zjjpXP0VVLLcNSmpwTTTb+KW73b11v53Dnkx8RjW ZDOjPEGG9UbazLnkAkHB98H6V0ep+LIbrxZaa1Y2l3CkF59sNrc3omQSeYHOzEa7AcDsTx1rmaK3 q4WlWmpzV2k1u9nvpe3z3Fd2sddrPxAu9V037LDbmyki1L7ZazwzYa3jVSI4lwB9zcSGGOp4qpq3 jrX9Wt7CKbV9SxaRpnfeyN5kquzLL14YZAB5I2jmucq3e6dLYRWckzIwvLcXEe0nhSzLg8dcqf0r lhluAouMVTV1e3Xffcrnk23f+rly78T6zqyxQa/rGqalZLKsj28167Zx6btwDYJAODjPQ9KfqniJ 7qyGmaTb/wBl6SOTaRysxnb+/M3HmNwOwUfwquTnForpWDw8XFxgly7JbX722v52uTzM6a51ywTV PDd4qvdpptnCs0Ub+UfMSR227ip9Rzg1dXxzZNClpd6NNc2MWppfRI96PNCKJD5DP5eCm+Vm+6D8 zDvkcve6dLYRWckzIwvLcXEe0nhSzLg8dcqf0qpXH/ZuDrQXMnJLS92ur7Na6vXcfM7fd+R2GreO LfXNJvbPU9Mkkaa9F3DNC9tAyHBB3+Xbr5jNk5Y4/h4GDnL8Sa1p2siw/s7TrqyNpbrbHz7xZ96L 908Rpg8nPXPHA74dFbUMtwuHkpUY8tr2Sbtra+l7dO2+u43Uk9yS3uJrS4juLWWSGaJg8csbFWRh yCCOQfet/VvHWv6tb2EU2r6li0jTO+9kbzJVdmWXrwwyADyRtHNc5Vu906Wwis5JmRheW4uI9pPC lmXB465U/pWtbD4apVjKrFOSva6+8lNq9i5c+LvEl6IheeINVuBDKJovNvZG8tx0cZPDDJwRzVjX fGmta/p9pZ32pX8sEMIjljmvHkWZwzN5hB4zhgOc/d61gUUlgcKpRmqcU47aLQfNLuFT3F9d3gxd 3U048xpcSyFvnbG5ue52jJ74HpUUaeZIqblXcQNzHAHua6LxT4Iv/CVvZy6jPbFrqNXWJJ0duQSc BWbKj5fmOM7hjODiqmIw8K0KVSS55X5V1dt7fqJJu9jm6KKK6hBRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAElvcTWlxHcWsskM0TB45Y2KsjDkEEcg+9b+reO tf1a3sIptX1LFpGmd97I3mSq7MsvXhhkAHkjaOa5yiuarhaFacalSCbjs2thptbGvd+LPEd+sS32 v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWRRSWDwyta nHTbRaBzS7mvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyP skX7rjJ4YdiORWRRQsHhla1OOm2i0Dml3Ne78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecii58 XeJL0RC88QarcCGUTRebeyN5bjo4yeGGTgjmsiihYLCq1qcdNtEHNLub+u+NNa1/T7SzvtSv5YIY RHLHNePIszhmbzCDxnDAc5+71rAooq6GHpYeHs6MVFdkDbe4VPcX13eDF3dTTjzGlxLIW+dsbm57 naMnvgelRRp5kipuVdxA3McAe5rpPE3ga/8AC0di2o3NoGvERlQToxGc5PyM3yj5fmOM7uM4OIq4 jD060KdSSU5X5V1dt7fqCTaduhzNFdN4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHB4 m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHGNPM8FV5OSonz35fO29vTqNwkr3WxzNFdN 4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHB4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5 R8vzHGd3GcHBTzPBVeTkqJ89+Xztvb06g4SV7rY5mium8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8 o+X5jjO7jODg8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODgp5ngqvJyVE+e/L523t6d QcJK91sczRXTeJvA1/4WjsW1G5tA14iMqCdGIznJ+Rm+UfL8xxndxnBweJvA1/4WjsW1G5tA14iM qCdGIznJ+Rm+UfL8xxndxnBwU8zwVXk5KifPfl87b29OoOEle62OZorpvE3ga/8AC0di2o3NoGvE RlQToxGc5PyM3yj5fmOM7uM4ODxN4Gv/AAtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODgp5ngq vJyVE+e/L523t6dQcJK91sczRXTeJvA1/wCFo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcHibw Nf8AhaOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHBTzPBVeTkqJ89+Xztvb06g4SV7rY5mium8T eBr/AMLR2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg4PE3ga/wDC0di2o3NoGvERlQToxGc5PyM3 yj5fmOM7uM4OCnmeCq8nJUT578vnbe3p1Bwkr3WxztvcTWlxHcWsskM0TB45Y2KsjDkEEcg+9b+r eOtf1a3sIptX1LFpGmd97I3mSq7MsvXhhkAHkjaOaf4m8DX/AIWjsW1G5tA14iMqCdGIznJ+Rm+U fL8xxndxnBweJvA1/wCFo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcc31nK8XOlUbjJyvyPe9t 7enXsPlnG/pr6FC78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecii78WeI79Ylvtf1S5EMqzRCa 9kfZIv3XGTww7Ecir/ibwNf+Fo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcHibwNf+Fo7FtRub QNeIjKgnRiM5yfkZvlHy/McZ3cZwcTSr5TU9n7PkfNflslrb4radOo3zq9yhd+LPEd+sS32v6pci GVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORV/xN4Gv/C0di2o3 NoGvERlQToxGc5PyM3yj5fmOM7uM4ODxN4Gv/C0di2o3NoGvERlQToxGc5PyM3yj5fmOM7uM4OCl Xymp7P2fI+a/LZLW3xW06dQfOr3KFz4u8SXoiF54g1W4EMomi829kby3HRxk8MMnBHNWNd8aa1r+ n2lnfalfywQwiOWOa8eRZnDM3mEHjOGA5z93rU/ibwNf+Fo7FtRubQNeIjKgnRiM5yfkZvlHy/Mc Z3cZwcHibwNf+Fo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcKlVyipKlOlyXd3CyWtt7enUH7R Xv2/A5mpLe4mtLiO4tZZIZomDxyxsVZGHIII5B966LxN4Gv/AAtHYtqNzaBrxEZUE6MRnOT8jN8o +X5jjO7jODg8TeBr/wALR2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg464Zlgqygo1E/aX5f71t7 d7dSXCSvdbDNW8da/q1vYRTavqWLSNM772RvMlV2ZZevDDIAPJG0c1Tu/FniO/WJb7X9UuRDKs0Q mvZH2SL91xk8MOxHIq/4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHB4m8DX/haOxbUb m0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHHHh6mUNU1R5Pevy2S1t8VvTqU/aK9+i/AoXfizxHfrEt9r +qXIhlWaITXsj7JF+64yeGHYjkUXfizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkVf8TeBr/wAL R2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg4PE3ga/8AC0di2o3NoGvERlQToxGc5PyM3yj5fmOM 7uM4OKpV8pqez9nyPmvy2S1t8VtOnUHzq9yhc+LvEl6IheeINVuBDKJovNvZG8tx0cZPDDJwRzVj XfGmta/p9pZ32pX8sEMIjljmvHkWZwzN5hB4zhgOc/d61P4m8DX/AIWjsW1G5tA14iMqCdGIznJ+ Rm+UfL8xxndxnBweJvA1/wCFo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcKlVyipKlOlyXd3Cy Wtt7enUH7RXv2/A5mium8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODg8TeBr/wtHYtq NzaBrxEZUE6MRnOT8jN8o+X5jjO7jODjsp5ngqvJyVE+e/L523t6dSXCSvdbHM1PcX13eDF3dTTj zGlxLIW+dsbm57naMnvgelb/AIm8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHDfFPgi/8 JW9nLqM9sWuo1dYknR25BJwFZsqPl+Y4zuGM4OFTzHA13TcKibnfl87b29OockldWObooor0SQoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACp7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qCik4ptNrYCe4vru8GLu6mnHmNLi WQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qCipVOCtZbAT3F9d3gxd3U04 8xpcSyFvnbG5ue52jJ74HpRcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelQUUKnBWstgJ7i+u7wYu 7qaceY0uJZC3ztjc3Pc7Rk98D0ouL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKFTgrWWwE9xfX d4MXd1NOPMaXEshb52xubnudoye+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUFFCpwVrLYC e4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qCihU4K 1lsBPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelFxfXd4MXd1NOPMaXEshb52xubnudoye+B6VBR QqcFay2AnuL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSi4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA 9KgooVOCtZbAT3F9d3gxd3U048xpcSyFvnbG5ue52jJ74HpRcX13eDF3dTTjzGlxLIW+dsbm57na MnvgelQUUKnBWstgJ7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0ouL67vBi7uppx5jS4lkLfO2Nz c9ztGT3wPSoKKFTgrWWwE9xfXd4MXd1NOPMaXEshb52xubnudoye+B6UXF9d3gxd3U048xpcSyFv nbG5ue52jJ74HpUFFCpwVrLYCe4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0u JZC3ztjc3Pc7Rk98D0qCihU4K1lsBPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelFxfXd4MXd1NO PMaXEshb52xubnudoye+B6VBRQqcFay2AnuL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSi4vru8GL u6mnHmNLiWQt87Y3Nz3O0ZPfA9KgooVOCtZbAT3F9d3gxd3U048xpcSyFvnbG5ue52jJ74HpRcX1 3eDF3dTTjzGlxLIW+dsbm57naMnvgelQUUKnBWstgJ7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0 ouL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKFTgrWWwE9xfXd4MXd1NOPMaXEshb52xubnudoy e+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUFFCpwVrLYCe4vru8GLu6mnHmNLiWQt87Y3Nz 3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qCihU4K1lsAUUUVYBRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQB//Z --_004_76B41B8FACE1514795D30EC137FF391D3D0967LILASjungleqosmos_-- From guanxiaoran@huawei.com Tue Jan 28 01:46:44 2014 Return-Path: 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 728901A019D for ; Tue, 28 Jan 2014 01:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.215 X-Spam-Level: * X-Spam-Status: No, score=1.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 KPq_mjiS2x-s for ; Tue, 28 Jan 2014 01:46:42 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EF0871A014C for ; Tue, 28 Jan 2014 01:46:40 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDA02344; Tue, 28 Jan 2014 09:46:37 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 09:46:19 +0000 Received: from SZXEML463-HUB.china.huawei.com (10.82.67.206) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 09:46:36 +0000 Received: from SZXEML522-MBX.china.huawei.com ([169.254.2.227]) by szxeml463-hub.china.huawei.com ([10.82.67.206]) with mapi id 14.03.0158.001; Tue, 28 Jan 2014 17:46:28 +0800 From: Guanxiaoran To: Nicolas BOUTHORS Thread-Topic: Note on GI deployment scenario draft-liu-sfc-use-cases-00 Thread-Index: AQHPG0E50IKowRRhXEC5c6zdZjgHZZqZvJyAgAAILtyAAB4kwA== Date: Tue, 28 Jan 2014 09:46:27 +0000 Message-ID: <2C5AD5728DB9B24189E3A93140E45786367D1F@szxeml522-mbx.china.huawei.com> References: <76B41B8FACE1514795D30EC137FF391D3D08E0@LILAS.jungle.qosmos.com>, <2C5AD5728DB9B24189E3A93140E45786367C79@szxeml522-mbx.china.huawei.com> <76B41B8FACE1514795D30EC137FF391D3D0967@LILAS.jungle.qosmos.com> In-Reply-To: <76B41B8FACE1514795D30EC137FF391D3D0967@LILAS.jungle.qosmos.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.113] Content-Type: multipart/related; boundary="_004_2C5AD5728DB9B24189E3A93140E45786367D1Fszxeml522mbxchina_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "sfc@ietf.org" Subject: [sfc] =?gb2312?b?tPC4tDogTm90ZSBvbiBHSSBkZXBsb3ltZW50IHNjZW5hcmlv?= =?gb2312?b?IGRyYWZ0LWxpdS1zZmMtdXNlLWNhc2VzLTAw?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 09:46:44 -0000 --_004_2C5AD5728DB9B24189E3A93140E45786367D1Fszxeml522mbxchina_ Content-Type: multipart/alternative; boundary="_000_2C5AD5728DB9B24189E3A93140E45786367D1Fszxeml522mbxchina_" --_000_2C5AD5728DB9B24189E3A93140E45786367D1Fszxeml522mbxchina_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgTmljb2xhcywNCg0KVGhlIFJhZGl1cyBzZXJ2ZXIgY291bGQgYWxzbyBpbmNsdWRlIGV4dGVu c2lvbnMgc3VjaCBhcyBhbiBpbmRpY2F0aW9uIG9mIHdoaWNoIHBvbGljaWVzIHNob3VsZCBiZSBh cHBsaWVkIHRvIGEgcGFydGljdWxhciBzdWJzY3JpYmVyIHRyYWZmaWMuDQpSYW4+IERvZXMgdGhl IFJBRElVUyBzZXJ2ZXIgc2VuZCB0aGVzZSBpbmZvcm1hdGlvbiB0byB0aGUgRFBJIG9yIERQSSBj YXB0dXJlIHRoZW0gd2hlbiB0aGUgdHJhZmZpYyBnb2VzIHRocm91Z2ggPw0KDQpUaGFua3MsDQpS YW4NCg0Kt6K8/sjLOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBOaWNv bGFzIEJPVVRIT1JTDQq3osvNyrG85DogMjAxNMTqMdTCMjjI1SAxNjowMg0KytW8/sjLOiBHdWFu eGlhb3Jhbg0Ks63LzTogc2ZjQGlldGYub3JnDQrW98ziOiBSZTogW3NmY10gTm90ZSBvbiBHSSBk ZXBsb3ltZW50IHNjZW5hcmlvIGRyYWZ0LWxpdS1zZmMtdXNlLWNhc2VzLTAwDQoNCkRQSSBkb2Vz IG5vdCBoYXZlIHRvIGJlIGEgUmFkaXVzIHByb3h5LiBJdCBjYW4gb2JzZXJ2ZSB0aGUgUmFkaXVz IHRyYWZmaWMgdmlhIGEgVGFwIG9yIGdldCBhIGNvcHkNCm9mIHRoZSBSYWRpdXMgdHJhZmZpYyB1 c2luZyBPcGVuRmxvdyB0YWJsZXMgaWYgdGhlIHRyYWZmaWMgcnVucyB0aHJvdWdoIGEgKHZpcnR1 YWwpIHN3aXRjaCB0aGF0IGl0IGNhbiBjb250cm9sLg0KDQpBY3RpbmcgYXMgYSBwcm94eSBpcyBt b3JlIGNvbXBsZXggYXMgaXQgY2FuIGhhdmUgYW4gZWZmZWN0IG9uIHBlcmZvcm1hbmNlIGFuZCBI QTogdGhlIHJhZGl1cyBjYWxscyBhcmUgb24gdGhlIGNyaXRpY2FsIHBhdGggb2YgUERQIGNvbnRl eHQgZXN0YWJsaXNobWVudC4NCg0KSXQgaXMgdXNlZnVsbCBvbmx5IGlmIHdlIHdhbnQgdG8gaW5z dXJlIHRoYXQgdGhlIElQL01TSVNETiBjb3JyZWxhdGlvbiBpcyBwZXJmb3JtZWQgYmVmb3JlIGFu eSBlbmQgdXNlciB0cmFmZmljIGlzIGFsbG93ZWQgdG8gZ28gdGhyb3VnaC4NCg0KV2F0Y2hpbmcg b3ZlciB0aGUgUmFkaXVzIHRyYWZmaWMgYWxzbyBhbGxvd3MgdG8gY2FwdHVyZSBvdGhlciBwYXJh bWV0ZXJzIHN1Y2ggYXMgdGhlIEFQTi4gVGhlIFJhZGl1cyBzZXJ2ZXIgY291bGQgYWxzbyBpbmNs dWRlIGV4dGVuc2lvbnMgc3VjaCBhcyBhbiBpbmRpY2F0aW9uIG9mIHdoaWNoIHBvbGljaWVzIHNo b3VsZCBiZSBhcHBsaWVkIHRvIGEgcGFydGljdWxhciBzdWJzY3JpYmVyIHRyYWZmaWMuDQpUaGlz IGxhc3QgcG9pbnQgY29tYmluZWQgdG8gdGhlIG1ldGFkYXRhIGl0IGNvbGxlY3RzIGNvdWxkIGFs bG93IHRoZSBEUCB0byBzZWxlY3QgdGhlIGFwcHJvcHJpYXRlIHNlcnZpY2UgY2hhaW4gdG8gYXBw bHkgdG8gb3V0Z29pbmcgcGFja2V0cw0KDQoNCg0KTmljb2xhcw0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KRnJvbTogR3VhbnhpYW9yYW4gW2d1YW54aWFvcmFuQGh1YXdlaS5j b21dDQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI4LCAyMDE0IDg6MjMgQU0NClRvOiBOaWNvbGFz IEJPVVRIT1JTOyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NClN1YmplY3Q6ILTw uLQ6IE5vdGUgb24gR0kgZGVwbG95bWVudCBzY2VuYXJpbyBkcmFmdC1saXUtc2ZjLXVzZS1jYXNl cy0wMA0KSGkgTmljb2xhcywNCg0KRG8geW91IG1lYW4gdGhhdCBEUEkgbXVzdCBzdXBwb3J0IFJB RElVUyBwcm94eSBpbiB0aGlzIGNhc2U/DQoNClJhbg0KDQq3orz+yMs6IHNmYyBbbWFpbHRvOnNm Yy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIE5pY29sYXMgQk9VVEhPUlMNCreiy83KsbzkOiAyMDE0 xOox1MIyN8jVIDE3OjIzDQrK1bz+yMs6IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3Jn Pg0K1vfM4jogW3NmY10gTm90ZSBvbiBHSSBkZXBsb3ltZW50IHNjZW5hcmlvIGRyYWZ0LWxpdS1z ZmMtdXNlLWNhc2VzLTAwDQoNCkhlbGxvLA0KDQpPbiBHaSBkZXBsb3ltZW50cyB0aGUgR0dTTiBj b25uZWN0cyB0byBhIFJhZGl1cyBGdW5jdGlvbiBhdCBQRFAgQ29udGV4dCBTZXR1cCBUaW1lLiBJ biBtb3N0IGNhc2UNCnRoaXMgaXMgdXNlZCB0byBwZXJmb3JtIGFuZCBNU0lTRE4gdG8gSVAgYWRk cmVzcyBtYXBwaW5nLCB3aGljaCBpcyB0aGVuIHVzZWQgYnkgdGhlIEdpIHNlcnZpY2UgaW5mcmFz dHJ1Y3R1cmUNCnRvIGRlY2lkZSBob3cgdG8gaGFuZGxlIHRoZSBJUCBmbG93cyBmb3IgdGhhdCBw YXJ0aWN1bGFyIHN1YnNjcmliZXIuDQoNClRoaXMgaW5mb3JtYXRpb24gY2Fubm90IGJlIGRlcml2 ZWQgYnkgdGhlIERQSSBsb2NhdGVkIGFmdGVyIHRoZSBHR1NOLiAoSXQgY291bGQgaWYgdGhlIERQ SSB3ZXJlIHRvIGJlIGxvY2F0ZWQgb24gdGhlIG90aGVyIHNpZGUgb2YgdGhlIEdHU04sIHRoZSBH biBpbnRlcmZhY2UpLg0KDQpJdCBpcyBjbGVhciB0aGF0IHdlIHNob3VsZCB1cGRhdGUgdGhlIGRp YWdyYW0gdG8gc2hvdyB0aGUgUmFkaXVzIHRyYWZmaWMgZ28gdGhyb3VnaCB0aGUgRFBJIHNvIHRo YXQgdGhlIERQSSBjYW4gZXh0cmFjdCB0aGUgaW5mb3JtYXRpb24gYW5kIGFkZCBpdCB0byB0aGUg bWV0YWRhdGEgd2hpY2ggd2lsbCBiZSBjb2xsZWN0ZWQgbGF0ZXIgYXMgdGhlIHN1YnNjcmliZXIg dHJhZmZpYyBnb2VzIHRocm91Z2guDQoNClNvbWV0aGluZyBsaWtlOg0KDQpDaGFpbiAwOiBHR1NO IHNlbmQgUmFkaXVzIHRyYWZmaWMgdG8gUmFkaXVzIHNlcnZlciB2aWEgdGhlIERQSSBzbyB0aGF0 IHRoZSBEUEkgY2FuIGVzdGFibGlzaCB0aGUgSVAvTVNJU0ROIGNvcnJlbGF0aW9uDQoNCg0KW2Np ZDppbWFnZTAwMS5qcGdAMDFDRjFDNTAuNjYxRUE3MDBdDQoNCg0KDQpOaWNvbGFzDQoNCg== --_000_2C5AD5728DB9B24189E3A93140E45786367D1Fszxeml522mbxchina_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Nicolas= ,

 = ;

The Radius s= erver could also include extensions such as an indication of which policies= should be applied to a particular subscriber traffic. 

Ran> Do= es the RADIUS server send these information to the DPI or DPI capture them = when the traffic goes through ?

 = ;

Thanks,

Ran=

 = ;

=B7=A2=BC=FE=C8=CB: sfc [ma= ilto:sfc-bounces@ietf.org] =B4=FA= =B1=ED Nicolas BOUTHORS
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C228=C8=D5 16:02
=CA=D5=BC=FE=C8=CB: Guanxiaoran
=B3=AD=CB=CD: sfc@ietf.org
=D6=F7=CC=E2: Re: [sfc] Note on GI deployment scenario draft-liu-sfc-use-cases-00<= /o:p>

 

DPI does not = have to be a Radius proxy. It can observe the Radius traffic via a Tap or g= et a copy

of the Radius= traffic using OpenFlow tables if the traffic runs through a (virtual) swit= ch that it can control.

 

Acting as a p= roxy is more complex as it can have an effect on performance and HA: the ra= dius calls are on the critical path of PDP context establishment.

 

It is usefull= only if we want to insure that the IP/MSISDN correlation is performed befo= re any end user traffic is allowed to go through.

 

Watching over= the Radius traffic also allows to capture other parameters such as the APN= . The Radius server could also include extensions such as an indication of which policies should be applied to a particular subscrib= er traffic. 

This last poi= nt combined to the metadata it collects could allow the DP to select the ap= propriate service chain to apply to outgoing packets 

 

 

 

Nicolas<= /o:p>

 

From: Guanxiaoran [guanxiaoran@huawei.com]
Sent: Tuesday, January 28, 2014 8:23 AM
To: Nicolas BOUTHORS; sfc@ietf.org
Subject: =B4=F0=B8=B4: Note on GI deployment scenario draft-liu-sfc-use-cases-00

Hi Nicolas= ,

 

Do you mea= n that DPI must support RADIUS proxy in this case?

 

Ran=

 

=B7=A2=BC=FE=C8=CB: sfc [mailto:sfc-b= ounces@ietf.org] =B4=FA=B1=ED Nicolas BOUTHORS
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C227= =C8=D5 17:23
=CA=D5=BC=FE=C8=CB: sfc@ietf.org
=D6=F7=CC=E2: [sfc] Note on GI deployment scenario draft-liu-sfc-use-cases-00

 

Hello,=

 =

On Gi deploym= ents the GGSN connects to a Radius Function at PDP Context Setup Time. In m= ost case

this is used = to perform and MSISDN to IP address mapping, which is then used by the Gi s= ervice infrastructure

to decide how= to handle the IP flows for that particular subscriber.

 =

This informat= ion cannot be derived by the DPI located after the GGSN. (It could if the D= PI were to be located on the other side of the GGSN, the Gn interface).

 =

It is clear t= hat we should update the diagram to show the Radius traffic go through the = DPI so that the DPI can extract the information and add it to the metadata which will be collected later as the subscriber traffic go= es through. 

 =

Something lik= e:

 =

Chain 0: GGSN= send Radius traffic to Radius server via the DPI so that the DPI can estab= lish the IP/MSISDN correlation

 =

 =

<= o:p>

 <= o:p>

 <= o:p>

 =

Nicolas

 =

--_000_2C5AD5728DB9B24189E3A93140E45786367D1Fszxeml522mbxchina_-- --_004_2C5AD5728DB9B24189E3A93140E45786367D1Fszxeml522mbxchina_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=34434; creation-date="Tue, 28 Jan 2014 09:46:27 GMT"; modification-date="Tue, 28 Jan 2014 09:46:27 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/4RDSRXhpZgAATU0AKgAAAAgABAE7AAIAAAAEZGNoAIdpAAQA AAABAAAISpydAAEAAAAIAAAQwuocAAcAAAgMAAAAPgAAAAAc6gAAAAgAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFkAMAAgAAABQAABCY kAQAAgAAABQAABCskpEAAgAAAAM0OAAAkpIAAgAAAAM0OAAA6hwABwAACAwAAAiMAAAAABzqAAAA CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAMjAxNDowMToyNyAxMDoyMjowOQAyMDE0OjAxOjI3IDEwOjIyOjA5AAAAZABjAGgAAAD/4QsW aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49J++7vycgaWQ9J1c1 TTBNcENlaGlIenJlU3pOVGN6a2M5ZCc/Pg0KPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczpt ZXRhLyI+PHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJk Zi1zeW50YXgtbnMjIj48cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0idXVpZDpmYWY1YmRkNS1i YTNkLTExZGEtYWQzMS1kMzNkNzUxODJmMWIiIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcvZGMv ZWxlbWVudHMvMS4xLyIvPjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSJ1dWlkOmZhZjViZGQ1 LWJhM2QtMTFkYS1hZDMxLWQzM2Q3NTE4MmYxYiIgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUu Y29tL3hhcC8xLjAvIj48eG1wOkNyZWF0ZURhdGU+MjAxNC0wMS0yN1QxMDoyMjowOS40NzU8L3ht cDpDcmVhdGVEYXRlPjwvcmRmOkRlc2NyaXB0aW9uPjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0 PSJ1dWlkOmZhZjViZGQ1LWJhM2QtMTFkYS1hZDMxLWQzM2Q3NTE4MmYxYiIgeG1sbnM6ZGM9Imh0 dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIj48ZGM6Y3JlYXRvcj48cmRmOlNlcSB4bWxu czpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPjxyZGY6 bGk+ZGNoPC9yZGY6bGk+PC9yZGY6U2VxPg0KCQkJPC9kYzpjcmVhdG9yPjwvcmRmOkRlc2NyaXB0 aW9uPjwvcmRmOlJERj48L3g6eG1wbWV0YT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgPD94cGFja2V0IGVuZD0ndyc/Pv/bAEMABwUFBgUEBwYF BggHBwgKEQsKCQkKFQ8QDBEYFRoZGBUYFxseJyEbHSUdFxgiLiIlKCkrLCsaIC8zLyoyJyorKv/b AEMBBwgICgkKFAsLFCocGBwqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKv/AABEIARoCPAMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUG BwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR 8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5 eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj 5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQAC AQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXx FxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqS k5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T1 9vf4+fr/2gAMAwEAAhEDEQA/APn6iiiv0k5AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAop0aeZIqblXcQNzHAHua6TxN4Gv/AAtHYtqNzaBrxEZU E6MRnOT8jN8o+X5jjO7jODjmqYqhSqxozklKV7Lq7b29ASbTfY5mium8TeBr/wALR2Lajc2ga8RG VBOjEZzk/IzfKPl+Y4zu4zg4PE3ga/8AC0di2o3NoGvERlQToxGc5PyM3yj5fmOM7uM4OMKeZ4Kr yclRPnvy+dt7enUpwkr3WxzNFdN4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHB4m8DX /haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHBTzPBVeTkqJ89+Xztvb06g4SV7rY5mium8TeBr /wALR2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg4PE3ga/8AC0di2o3NoGvERlQToxGc5PyM3yj5 fmOM7uM4OCnmeCq8nJUT578vnbe3p1Bwkr3WxzNFdN4m8DX/AIWjsW1G5tA14iMqCdGIznJ+Rm+U fL8xxndxnBweJvA1/wCFo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcFPM8FV5OSonz35fO29vT qDhJXutjmaK6bxN4Gv8AwtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODg8TeBr/AMLR2Lajc2ga 8RGVBOjEZzk/IzfKPl+Y4zu4zg4KeZ4KryclRPnvy+dt7enUHCSvdbHM0V03ibwNf+Fo7FtRubQN eIjKgnRiM5yfkZvlHy/McZ3cZwcHibwNf+Fo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcFPM8F V5OSonz35fO29vTqDhJXutjmaK6bxN4Gv/C0di2o3NoGvERlQToxGc5PyM3yj5fmOM7uM4ODxN4G v/C0di2o3NoGvERlQToxGc5PyM3yj5fmOM7uM4OCnmeCq8nJUT578vnbe3p1Bwkr3WxzNFdN4m8D X/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHB4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vz HGd3GcHBTzPBVeTkqJ89+Xztvb06g4SV7rY5mium8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8o+X5 jjO7jODg8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODgp5ngqvJyVE+e/L523t6dQcJK 91sczRXTeJvA1/4WjsW1G5tA14iMqCdGIznJ+Rm+UfL8xxndxnBweJvA1/4WjsW1G5tA14iMqCdG IznJ+Rm+UfL8xxndxnBwU8zwVXk5KifPfl87b29OoOEle62OZorpvE3ga/8AC0di2o3NoGvERlQT oxGc5PyM3yj5fmOM7uM4ODxN4Gv/AAtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODgp5ngqvJyV E+e/L523t6dQcJK91sczRXTeJvA1/wCFo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcHibwNf8A haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHBTzPBVeTkqJ89+Xztvb06g4SV7rY5mium8TeBr/ AMLR2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg4PE3ga/wDC0di2o3NoGvERlQToxGc5PyM3yj5f mOM7uM4OCnmeCq8nJUT578vnbe3p1Bwkr3WxzNFdN4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8v zHGd3GcHB4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHBTzPBVeTkqJ89+Xztvb06g4S V7rY5mium8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODg8TeBr/wtHYtqNzaBrxEZUE6 MRnOT8jN8o+X5jjO7jODgp5ngqvJyVE+e/L523t6dQcJK91sczRXTeJvA1/4WjsW1G5tA14iMqCd GIznJ+Rm+UfL8xxndxnBweJvA1/4WjsW1G5tA14iMqCdGIznJ+Rm+UfL8xxndxnBwU8zwVXk5Kif Pfl87b29OoOEle62OZorpvE3ga/8LR2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg4b4p8EX/AISt 7OXUZ7YtdRq6xJOjtyCTgKzZUfL8xxncMZwcFLMsHWdNU6ifPfl87b29OockuxzdFFFegSFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAVPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelRRp5kipuVdxA3McAe5rovFPgi/8JW9n LqM9sWuo1dYknR25BJwFZsqPl+Y4zuGM4OOWpiMPCtClUkueV+VdXbe36jSbvYwri+u7wYu7qace Y0uJZC3ztjc3Pc7Rk98D0ouL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKK3VOCtZbCJ7i+u7wYu 7qaceY0uJZC3ztjc3Pc7Rk98D0ouL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKFTgrWWwE9xfX d4MXd1NOPMaXEshb52xubnudoye+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUFFCpwVrLYC e4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qFFDSKr MEBIBZs4X3OOa1fEOkWukXFqLC/a/t7m3E6TNB5WfnZeFJJxlMgnBwRkA8Vk5UYVI07au9tPv1tZ fqPV3KFxfXd4MXd1NOPMaXEshb52xubnudoye+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ74HpU FFaqnBWsthE9xfXd4MXd1NOPMaXEshb52xubnudoye+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ 74HpUFFCpwVrLYCe4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3P c7Rk98D0qCrd7p0thFZyTMjC8txcR7SeFLMuDx1yp/SptTi4xsk9bfrYNWR3F9d3gxd3U048xpcS yFvnbG5ue52jJ74HpRcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelQUVSpwVrLYCe4vru8GLu6mnH mNLiWQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qCihU4K1lsBPcX13eDF3 dTTjzGlxLIW+dsbm57naMnvgelFxfXd4MXd1NOPMaXEshb52xubnudoye+B6VBRQqcFay2AnuL67 vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSi4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KkvdOlsIrOSZ kYXluLiPaTwpZlweOuVP6VUqYKnJKUErLb9Q1J7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0ouL6 7vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKpU4K1lsBPcX13eDF3dTTjzGlxLIW+dsbm57naMnvge lFxfXd4MXd1NOPMaXEshb52xubnudoye+B6VBRQqcFay2AnuL67vBi7uppx5jS4lkLfO2Nzc9ztG T3wPSi4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KgooVOCtZbAT3F9d3gxd3U048xpcSyFvnbG5u e52jJ74HpRcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelQUUKnBWstgJ7i+u7wYu7qaceY0uJZC3z tjc3Pc7Rk98D0ouL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKFTgrWWwE9xfXd4MXd1NOPMaXE shb52xubnudoye+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUUaeZIqblXcQNzHAHua6LxT4 Iv8Awlb2cuoz2xa6jV1iSdHbkEnAVmyo+X5jjO4Yzg4551sNSqwoyaUpX5V1dt7fqNJu9jm6KKK6 xBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFT3F9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUUaeZIqblXcQNzHAHua6LxT4 Iv8Awlb2cuoz2xa6jV1iSdHbkEnAVmyo+X5jjO4Yzg45amIw8K0KVSS55X5V1dt7fqNJu9jm6KKK 6hBRVu906Wwis5JmRheW4uI9pPClmXB465U/pVSpjOM1zRegBRRRVAOjKCVDMrNGGG5VbaSO4Bwc H3wa29f1jSNUsrGLTtMvbSWziECvPfpMrRhnblREnzZfrnGB071hUVhOhCdSNSV7x21a/BOz+YJ2 CiiitwCiinwxrLcRxvKkKuwVpZASqAn7x2gnA68An2NJuyuAtvcTWlxHcWsskM0TB45Y2KsjDkEE cg+9b+reOtf1a3sIptX1LFpGmd97I3mSq7MsvXhhkAHkjaOaztY0C/0OSP7YiPBPuNvdwOJIbgA4 JRxw2MjI6jOCAeKtaX4b+2a7o1he3XkR6sqtHLDH5rJuZkUFSVydy+vQ59q82s8DUjHFVEpWTadr 6Le1r39ClzJtIiu/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIou/FniO/WJb7X9UuRDKs0Qmv ZH2SL91xk8MOxHIrTu/CVjYaK+o3t/fQIXt3t0exjJnt5txWQYmOG2xyHYfQDPORB4m8M2nh+8tR DqUt3ZysY5pDaiOSCRQpkjKbyCyh1/iAJJHbNc9Ktlk5xhTir629x9Em7O1tn8ynz2uynd+LPEd+ sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWn4h8J WGkrqy6dqtzeTaRdLb3Sz2QgUkllyjCR88r0IU457Gue03T5tV1S2sLXb51zKsSbzhQScZJ7CtqH 9n1aXtqcFyx/u2tpfZpNaO4pc8XZsvXfizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkUXPi7xJe iIXniDVbgQyiaLzb2RvLcdHGTwwycEc1raf4a8M6pqVtZWPie6aae6W2CvpO0vu4Dp+9IK5x94qe enaodR8J22neHp9SkvLtHzA9pDNaIouIZt5RyyyttOI5CVwcYHPPGEa+WKcafIlLSydNr4nbS8V1 3/Edp9/xK+u+NNa1/T7SzvtSv5YIYRHLHNePIszhmbzCDxnDAc5+71rAq3e6dLYRWckzIwvLcXEe 0nhSzLg8dcqf0qpXp4WlQo0lHDpKPkQ23a4UUUV0iCiiigAooooAKKKKACiird7p0thFZyTMjC8t xcR7SeFLMuDx1yp/Spc4pqLerAqVPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelRRp5kipuVdxA3 McAe5rovFPgi/wDCVvZy6jPbFrqNXWJJ0duQScBWbKj5fmOM7hjODjnqYjDwrQpVJLnlflXV23t+ o0m72ObooorqEFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAVPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelRRp5kipuVdxA 3McAe5rovFPgi/8ACVvZy6jPbFrqNXWJJ0duQScBWbKj5fmOM7hjODjlqYjDwrQpVJLnlflXV23t +o0m72ObqS3uJrS4juLWWSGaJg8csbFWRhyCCOQfeo6K6WlJWYjo9W8da/q1vYRTavqWLSNM772R vMlV2ZZevDDIAPJG0c1Tu/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIqHVtJ/suPT287zfttm t1jZt2bmYbepz93rx1rOrgw+EwXs4ulTjbW2n3lOUur6fga934s8R36xLfa/qlyIZVmiE17I+yRf uuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZFFbLB4ZWtTjptotBc0u5r3fizx HfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkUXfizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkVkUU LB4ZWtTjptotA5pdzXu/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIou/FniO/WJb7X9UuRDKs 0QmvZH2SL91xk8MOxHIrIooWDwytanHTbRaBzS7mvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4Yd iORRd+J9Z1ZYoNf1jVNSsllWR7ea9ds49N24BsEgHBxnoelZFFCweGjblppW2skrenb5BzS7m9ee KrkRxWnh9ZNFsIXEiQ207b5JAQRLLJwXcYGDgKuPlVcnNyf4ha5d3WjyXl/f3MWnNE7wT3rutw8c pcOwPfkDPJ4rlat3unS2EVnJMyMLy3FxHtJ4Usy4PHXKn9K55ZfgrxjKCvra++u+u7fne4cz1t2/ A62f4iQagsMOq6N59rBqgvY4YrkR4iVSI7fJQ/Ku4845BPTORBqnji11zS7yz1bS5ZfOvhdxSwSW 1u6cENvMduPMZgTljjnbxwc8dRWUclwEJKUadmttXprfTXS/W260ehXtJdzpvGfjKfxZqDTCTU4r ZpGl+x3eom5iick/6sbFCAA4AwfrWHpeoS6Tq1rqFuFaW2lWVVccMQc4Psaq0V20cHQoUFhqcbQt a3l+ZMpOTuztIfHkOm6fBY6Ja6pDaR3sN19lu9V8+FRHIZNqII025bBJOenrzUOs/EC71XTfssNu bKSLUvtlrPDNhreNVIjiXAH3NxIYY6niuRorkjk+BjP2ip63vdtvXzu9fmV7ST/r+u50ereOtf1a 3sIptX1LFpGmd97I3mSq7MsvXhhkAHkjaOap3fizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkVT vdOlsIrOSZkYXluLiPaTwpZlweOuVP6VUrajgsFGC9lTjZXtovmLml36fga934s8R36xLfa/qlyI ZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZFFarB4ZWtTjpto tBc0u5r3fizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkUXfizxHfrEt9r+qXIhlWaITXsj7JF+6 4yeGHYjkVkUULB4ZWtTjptotA5pdzXu/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIou/FniO/ WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIrIooWDwytanHTbRaBzS7mvd+LPEd+sS32v6pciGVZohNe yPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWRRQsHhla1OOm2i0Dml3Ne 58XeJL0RC88QarcCGUTRebeyN5bjo4yeGGTgjmrGu+NNa1/T7SzvtSv5YIYRHLHNePIszhmbzCDx nDAc5+71rArR1bSf7Lj09vO837bZrdY2bdm5mG3qc/d68daxeFwUKsP3cVJX5dPvGpS116fgZ1T3 F9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUUaeZIqblXcQNzHAHua6LxT4Iv/AAlb2cuoz2xa6jV1 iSdHbkEnAVmyo+X5jjO4Yzg42qYjDwrQpVJLnlflXV23t+okm72ObooorqEFFFFABRRWpe6ZDYeH 7C4naT7dfM0qRZG1LcHarEYzlmD456KDzuGM51IwlGL3k7L7r/oCVzLp8M0ttcRz28jxTRMHjkjY qyMDkEEdCD3rRvdMhsPD9hcTtJ9uvmaVIsjaluDtViMZyzB8c9FB53DGXShUhWi2tVqvu0YNWNe7 8WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecii78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Eci siislg8MrWpx020Wg+aXc17vxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKLvxZ4jv1iW+1/VL kQyrNEJr2R9ki/dcZPDDsRyKyKKFg8MrWpx020Wgc0u5r3fizxHfrEt9r+qXIhlWaITXsj7JF+64 yeGHYjkVHqPibXtYthbatreo30AYOIrm7kkUMMgHDEjPJ596zKKccJhoNONOKttotPQOaXcKKltj ALuE3iyNbiRfNWIgOUz8wUkEA4zjIrQ1TTING8TNaXTST2KSq6yQsA01u2GV1JGAWQgjI4zyKuVa MZ8nW1/W2/6feK2lzKorQ13S/wCx9auLNZPNhUh4Jh0liYBo3H+8pU/jWfV06kakFOOz1Q2rOwUU UVYgooooAKKKKACiird7p0thFZyTMjC8txcR7SeFLMuDx1yp/Spc4pqLerAqUUUVQBRRRQAUVbvd OlsIrOSZkYXluLiPaTwpZlweOuVP6VUqYzjNc0XoAUUUVQBRRVu906Wwis5JmRheW4uI9pPClmXB 465U/pUucU1FvVgVKnuL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKbim02tgCiird7p0thFZyT MjC8txcR7SeFLMuDx1yp/Sk5xTUW9WBe8Q39tfQ6MtrJ5httNjgl+Uja4dyRz14I5HFY1aOraT/Z cent53m/bbNbrGzbs3Mw29Tn7vXjrWdWGFVNUYqk7xG76ei/IKKt3unS2EVnJMyMLy3FxHtJ4Usy 4PHXKn9KqVvGcZrmi9BBRRRVAFFFFABRRRQBJb3E1pcR3FrLJDNEweOWNirIw5BBHIPvW/q3jrX9 Wt7CKbV9SxaRpnfeyN5kquzLL14YZAB5I2jmucormq4WhWnGpUgm47NrYabWxr3fizxHfrEt9r+q XIhlWaITXsj7JF+64yeGHYjkUXfizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkVTvdOlsIrOSZk YXluLiPaTwpZlweOuVP6VUqKeFwjSlCnGy20XzHzS7mvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ 4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWRVu906Wwis5JmRheW4uI9pPClmXB46 5U/pR9VwkHGPs4p620XzsHNJ9S5d+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRc+LvEl6Ihe eINVuBDKJovNvZG8tx0cZPDDJwRzWRRVLBYVWtTjptohc0u5v67401rX9PtLO+1K/lghhEcsc148 izOGZvMIPGcMBzn7vWsCiiroYelh4ezoxUV2QNt7hRRVu906Wwis5JmRheW4uI9pPClmXB465U/p WrnFNRb1YipRRRVAFFFFABRRRQAVs+Ib+2vodGW1k8w22mxwS/KRtcO5I568Ecjis2xsptRvobO1 8vzpm2IJJVjUn3ZiAPxNaV74U1bT7G8u7pLVYbG4FtPsvoHZZT/CFVyWPXoD91v7pxx1qmHVeHtJ pSWyutb6bb+nmNX1t/XX9DGqe4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KijTzJFTcq7iBuY4A9 zXReKfBF/wCErezl1Ge2LXUausSTo7cgk4Cs2VHy/McZ3DGcHFVMRh4VoUqklzyvyrq7b2/UEm72 ObooorqEFFFFAEtsIDdwi8aRbcyL5rRKC4TPzFQSATjOMmtDVNTg1nxM13dLJBYvKqLHCoLQ264V UUE4JVAAMnnHJqPVtJ/suPT287zfttmt1jZt2bmYbepz93rx1rOrmjGnXtWi+jSf5/kvuHqlbuaG u6p/bGtXF4sflQsQkEI6RRKAsaD/AHVCj8Kz6KK2pwjTgoR2WiBu7uFFFFWIKKKKACiiigArUvdT hv8Aw/YW86yfbrFmiSTA2vbk7lUnOcqxfHHRgONozl0VnOnGcoye8Xdfdb9QTsal7qcN/wCH7C3n WT7dYs0SSYG17cncqk5zlWL446MBxtGcuitHVtJ/suPT287zfttmt1jZt2bmYbepz93rx1rOHs6D VJdbtfm/zHqzOoooroEFFFFABRRRQBJb3E1pcR3FrLJDNEweOWNirIw5BBHIPvW/q3jrX9Wt7CKb V9SxaRpnfeyN5kquzLL14YZAB5I2jmucrak8NTHUNFsrWZZZtWgjlTeNixl3ZcE5PA25z+lcOJp4 R1I1K8VzK9m1sktRxbV7DLvxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKLvxZ4jv1iW+1/VLk QyrNEJr2R9ki/dcZPDDsRyKujw9ot/JFa6Br8t3fy3KW8cFzYGBZNxx5iuHYbR/tbT7dcQ3ek+Hv s5OleIpJ7gTrEIrqwMCuCceYHDsNo/2tp6cdcckZ5fdJUrNf9O5K1/8At3RPu7J69mU+bq/xILvx Z4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKLnxd4kvRELzxBqtwIZRNF5t7I3luOjjJ4YZOCOa3 9T8B2Wl6hZWl3qOqW8t1fC1UXOjGISL0M0TGTbIgYoOoOGBxVLWPCNto2k6jcTajNJcWl3FbxRpa r5U6SBnSQSeZkAojEjaSDgepGNHFZTUcFTitdvcfV2093a+je3cbU9blXXfGmta/p9pZ32pX8sEM IjljmvHkWZwzN5hB4zhgOc/d61gVbvdOlsIrOSZkYXluLiPaTwpZlweOuVP6VUr1sLSoUaSjh0lH yIbbtcKKKfDGstxHG8qQq7BWlkBKoCfvHaCcDrwCfY10N2VxC29xNaXEdxayyQzRMHjljYqyMOQQ RyD71v6t461/Vrewim1fUsWkaZ33sjeZKrsyy9eGGQAeSNo5rO1jQL/Q5I/tiI8E+4293A4khuAD glHHDYyMjqM4IB4qa50SKzu9HjuLp/K1G3jnd0hBaIM7KQFLDcRtz1GfavOqfUazhWmlJ2dna+29 v6/Ed3G/p+Al34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+ yRfuuMnhh2I5FaWseFNNsZNRFhq9zdjSLryNQWWxWJ0TzPL8yMCVg43cYJU/MvqSH674S03S31NL PV7u5bSbtba882wWIYLMu6MiVtxyp4O3I+hxywr5W3FRgvL3GrXt/d0vzLe17o0caivf8zKufF3i S9EQvPEGq3AhlE0Xm3sjeW46OMnhhk4I5qxrvjTWtf0+0s77Ur+WCGERyxzXjyLM4Zm8wg8ZwwHO fu9aPEeiaVo9rYPp+p3l5LewLcqk9ikKrGSw5Ilf5sr0xjB69qo6tpP9lx6e3neb9ts1usbNuzcz Db1Ofu9eOtbUYZfVdOpTgr68vu29dGlYm809+n4FjxDf219Doy2snmG202OCX5SNrh3JHPXgjkcV lW9xNaXEdxayyQzRMHjljYqyMOQQRyD71an0t7V9P+0zwxR30SzLIdxWNC7JlsAnjaTwDx0yeKk1 jQL/AEOSP7YiPBPuNvdwOJIbgA4JRxw2MjI6jOCAeK6aMsPCEaCle97X69/XzJ1av5I0dW8da/q1 vYRTavqWLSNM772RvMlV2ZZevDDIAPJG0c1Tu/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIps Ph29uNQ0qzhMTS6oivB8xwoZ2T5jjjBUk9eK0l8J22qgr4U1T+05o5lhljuYVtM7jhHRnkIZS3y/ NsbLL8vPHF/wl4ZKPLFJa35dFd9Xa0bu61auVeTW/T8DPu/FniO/WJb7X9UuRDKs0QmvZH2SL91x k8MOxHIou/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIqW+8Ha1ppUXsNvHmcW7kXsDCCQ5wsu HPlHg/f2/dPoaZrnha/8P3ptr2fT5HExhzb6hDL8w7lQ25B7sBWlOWVylGNPkb1tbl+dv1G/aK97 jbvxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKLvxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDs RyKsXHhDUE1yw0i1Ec15fQLJEpuYNjkkjCSLIyMPlwOQSeMdMt1LwXrmk232i/toY4t6puW8hfqS A3yufl3AqW+6GBUnIIpRnlV4Ri6d3rFe7ez7Lz/EXv67kN34s8R36xLfa/qlyIZVmiE17I+yRfuu Mnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FJq3h650rULOybEk11Cki7ZInRixIG 143ZWXI65H0FT6j4L1zS7eGa5t7d0nufskf2a9huGabum2N2ORxnjjI9RVReWLktyK/w/Cr97f8A AD39SG78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecii58XeJL0RC88QarcCGUTRebeyN5bjo4y eGGTgjmlv/C2q6asT3SWpjlm+z+bDewzRxyf3XdHKxnqfmI4BPY4fq3g/W9DtTcanaxxRgK3y3UT sUb7sgVWJKHoHA2k8ZzRF5W3BR9nrfl+HXvb9bB7/mSa7401rX9PtLO+1K/lghhEcsc148izOGZv MIPGcMBzn7vWsCrd7p0thFZyTMjC8txcR7SeFLMuDx1yp/Sq8May3EcbypCrsFaWQEqgJ+8doJwO vAJ9jXXh6dChStQilHXZfeS23a4tvcTWlxHcWsskM0TB45Y2KsjDkEEcg+9b+reOtf1a3sIptX1L FpGmd97I3mSq7MsvXhhkAHkjaOaztY0C/wBDkj+2IjwT7jb3cDiSG4AOCUccNjIyOozggHirEvhq b7fo1nazLLNq0Ecqbl2CMu7LgnJ4G3Of0rnqPA1nCvPllo7PfRb6jXMm0uwy78WeI79Ylvtf1S5E MqzRCa9kfZIv3XGTww7Ecii78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecipr3SdBFpIdJ8QTX l2kgjW3l08w+dkgbkbew29T8209Pl5OK+oeGdU01YWmhhmSeUwxvZ3MVypk4+TMTMA3I+U81FP8A s98qUIxetk48r87KST9bDfP3HXfizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkUXfizxHfrEt9r +qXIhlWaITXsj7JF+64yeGHYjkVfXwLqlvJFJqqpBZfaktbia2nhuXt5GOArRrJkN1+VsHg+lQa3 4M1fRLzyJoFmD3RtY/JljkcyfwqyIxMbEchWwevoazp1cplNQpuF9bW5fnZ7eqWvV7h79m3f+v6Z XufF3iS9EQvPEGq3AhlE0Xm3sjeW46OMnhhk4I5qxrvjTWtf0+0s77Ur+WCGERyxzXjyLM4Zm8wg 8ZwwHOfu9aq6r4a1PRrdbi9jgaEyGIy213FcKj4zsYxswVsZIDYJwcdDVW906Wwis5JmRheW4uI9 pPClmXB465U/pW1Ojl83CpSjF2vytW+drCvNN37fgVKKKK9MkKKKKACiiigArc8QeJ5det7SJ4Fg 8vMtwytk3NwwAeZvchV49cnvWHVu906Wwis5JmRheW4uI9pPClmXB465U/pXPUp0ZVYTmveV7fdq NN7IqVPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelQUVu4ptNrYQUUUUwCinwxrLcRxvKkKuwVpZ ASqAn7x2gnA68An2NX9Y0C/0OSP7YiPBPuNvdwOJIbgA4JRxw2MjI6jOCAeKylWpxmqbdm9l39O4 WZP4hv7a+h0ZbWTzDbabHBL8pG1w7kjnrwRyOKxqt3unS2EVnJMyMLy3FxHtJ4Usy4PHXKn9KqVO HhCFJRpu6B9PRfkFFOjCGVBMzLGWG5lXcQO5AyMn2yK6TVfDFhBJpdvoup3N7d6nGksSXdrFaoqM WAy5mYBsr0OBz17VNXFUqM1Co7Xv0dtN7u1l82hpNnM0Vt6j4P1nSZIkv4baIyT/AGYkXsDCKX+5 IQ5ER/39vQ+ho1nwlqWiaiLKdrK5nac26JZXsU7M+cY2Ixdcn+8BURx2Fm4qNSLvdrVa23t6DcZL dGJRWxf+FtV01YnuktTHLN9n82G9hmjjk/uu6OVjPU/MRwCexxaufAfiGzkiS6tbeJpmQRhr6D5g /wBx/v8A+rJ4D/dJ4znik8wwaSbqx1vb3lrbe2vTqLll2Odorb1LwhrekyRpeWiGSSf7MI7e4inZ Zv8AnmyxsxR/9lsHg+hpt74U1bT/ACTcJaGOWb7OJor+CWOOT+67q5WM9T85HAJ7HFRx2Fkk41Yu +2q1tvbXoDjJboxqK2Nf8MX3hu6eC/msJWSVoj9lvopjkeqqxZf+BAVj1tRrU68FUpSUovqgaadm FbPiG/tr6HRltZPMNtpscEvykbXDuSOevBHI4rGrR1bSf7Lj09vO837bZrdY2bdm5mG3qc/d68da zqKm60HJ+9rb9QV9bdv1RnUUUV0iCiiigAooooAK6S+1+ODUPDl9prrLNpllCrq6kASJI7FT0yME dPWubq3e6dLYRWckzIwvLcXEe0nhSzLg8dcqf0rlrUqVScfaeat3utfwBdbdv1R1Efj5dM0yOx8P 2+pW9ul1HcC3vdU+0QKEcvtWMRptBY5Jyc49eajfxnYxaKuj2dhqn9lPdRTT2N3q5liMauXaNAsa bNxPLcnv15rkKK5P7HwV78mt7/FLfvvq10e66F+0kdXD4p0iwWCDTNHvorNdQivpoZtSWQs0YYIq HyRs++ckhiQB6U3UPGsk+kPYWFvNabNRS9tLk3O6a3CiT93uVVyA8rMCACCT1zxy1FWsrwnNzuN3 5uT++7d/n002Fzv+v68zo9W8da/q1vYRTavqWLSNM772RvMlV2ZZevDDIAPJG0c1Tu/FniO/WJb7 X9UuRDKs0QmvZH2SL91xk8MOxHIqne6dLYRWckzIwvLcXEe0nhSzLg8dcqf0qpV0cFgowXsqcbK9 tF8w5pd+n4Gvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+J9Z1ZYoNf1jVNSsllWR7ea9 ds49N24BsEgHBxnoelZFPhjWW4jjeVIVdgrSyAlUBP3jtBOB14BPsa0+qYaCTVNK21lqvS2v3C5p dzX1TxE91ZDTNJt/7L0kcm0jlZjO39+ZuPMbgdgo/hVcnM2qarYzXPh+Rd9zHZWMUdxGhMbblkdi oYqQDgjnBHPeqOsaBf6HJH9sRHgn3G3u4HEkNwAcEo44bGRkdRnBAPFQXunS2EVnJMyMLy3FxHtJ 4Usy4PHXKn9K56dHCTjB03o72s977tvdvzvcHfVPt+Ghvav4q0y+k1NrHSbu1OsXQmvzLfrKWTzD IY48RLsBYg5O77q++U8X+MpPFeqCaRtVWyaYzNY3Op+ekZJPEXyAIMHA4OP0rl6KqnlmEpzjUjHW N7NtvdJPd9klfdW0KdSTvfqb/iPW9K1i1sE0/TLyzlsoFt1ee+SZWjBY8gRJ82W65xgdO9N1rV0k fQptLupEnsdPijaSPcjRSq7ng8cjIORWFVu906Wwis5JmRheW4uI9pPClmXB465U/pVRwmHpckF0 vZNt3vvvd/iLmbfy/DT/AIBsat411XXbewtNXv8AUrmzgjRLiF752+0EOzF/mBAbDYBIbGB16VFe eKrkRxWnh9ZNFsIXEiQ207b5JAQRLLJwXcYGDgKuPlVcnNLVtJ/suPT287zfttmt1jZt2bmYbepz 93rx1rOqKGDwTpxdKC5Vey6ettr+drg5S69jqrn4i+IrmXS5H1O+k+wKhaO4u3ljnkV2beyk4PDB ec8DrVjR/EWi2+s2Uen2X9i2st9FcX1xc3DXOI43DiNAse5VyOhDsSFy2Ac8xe6dLYRWckzIwvLc XEe0nhSzLg8dcqf0qpWf9l4KpS5aceVNNe7p36bNp6q6dmDk2tex1fibWdGEmqWnh6CQi/uFlmuz dtLG6gl9savDG6jcwzu3H5cZPU1Na13SNXujdf2JNDc3NwJ72U324t/eWIbAIwSSfmEhHy4PBzz9 FbUsvoU1G17rrzSu7pJ3112XkraWHKo5O52a+MNCi1jRNQg0HURJo4jWNX1VCJFQswBxbjncwyfQ YxzkQS+LdLn0lNOl0e88lbZbXK6goYok7Sqc+TjOHKnjng4HSuTorJZRg007PS1vel0ba+13bFzv 9P6+46PXdd0TVYdPW20i/t2sokt8y6ikgeJSxIwIVwx3fezgelXNW8Z2E95YXuiaRcafc6dPFJaL LfCaG3jjJPloixpwzEMzMWYkdckk8hRVrK8LaKs7Rva8pPffd638w5mdZr/jGLXoI4bhvEUkIuFl kgu9dNxFtGchFaLKtg4DEtjuDVPXdfsb/UodR0Wzv9MvYvLAlbUFkx5aKqldsSFW+UHOTz6Vz9FV Ry3C0eX2cWrXW8ra73V7O9utwc5Pc6PVvHWv6tb2EU2r6li0jTO+9kbzJVdmWXrwwyADyRtHNU7v xPrOrLFBr+sapqVksqyPbzXrtnHpu3ANgkA4OM9D0qne6dLYRWckzIwvLcXEe0nhSzLg8dcqf0qp To4PBxgvZQSSvay272e6Dml36fgbWqeInurIaZpNv/Zekjk2kcrMZ2/vzNx5jcDsFH8Krk5s3+vp BfeHb7SpFkn02yhVg6HaJFkdtpBxkYI6cc1zlW73TpbCKzkmZGF5bi4j2k8KWZcHjrlT+lH1PDRc YW76d7rW99W/Nu4ru79P1Rrf214ftbqG50zw24kS5jnZb6+M8YVWyY1UInynod+/gfUnX1X4i/br OzWODVJbuyv0voLnU9V+1bXX+Hb5agLwOFx368AcPRWc8pwlScZzi247Nyk/zf4MfPJbHRDWfDkF 3FPZeHrqMrcJM/manvKKpzsjxEAoJxy4c4AxzkmyfGFrb+fNpum3MF42rJqcEsl4rrGyEkKVEalh 8zc5Hb0OefvdOlsIrOSZkYXluLiPaTwpZlweOuVP6VUoWX4SquZ3kvOUn+bDmf8AXp/kzrde8cTa rDH9lu/EUM0dws8f2vXWuYomGcFFMasCM8NuJAz1zmqOu+NNa1/T7SzvtSv5YIYRHLHNePIszhmb zCDxnDAc5+71rAq3e6dLYRWckzIwvLcXEe0nhSzLg8dcqf0op5fgaDgowV1flvq/PV3Y+eTe/T8C pRRRXpkBRRRQAUUUUASW9xNaXEdxayyQzRMHjljYqyMOQQRyD71v6t461/Vrewim1fUsWkaZ33sj eZKrsyy9eGGQAeSNo5rno4zLKkalQzsFBZgo59SeAPc1ra1o1lp1vHJp+sW+o7X8m4VAEMcoGTsB JMkZ5AkAHIOQMru4a9PCzrw9rFOettL2+drLyvv0HG6vYS78WeI79Ylvtf1S5EMqzRCa9kfZIv3X GTww7Ecii78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7EcisqNPMkVNyruIG5jgD3NdF4p8EX/hK 3s5dRnti11GrrEk6O3IJOArNlR8vzHGdwxnBxnKGX0asKMoxUpX5VZX87afeNOcr2KV34s8R36xL fa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZFFdCweG VrU46baLQXNLua934n1nVlig1/WNU1KyWVZHt5r12zj03bgGwSAcHGeh6VPeeKrkRxWnh9ZNFsIX EiQ207b5JAQRLLJwXcYGDgKuPlVcnODRU/UcNp7istl09bbX87XDmZv67401rX9PtLO+1K/lghhE csc148izOGZvMIPGcMBzn7vWsCtHVtJ/suPT287zfttmt1jZt2bmYbepz93rx1rOqsJTw9Oilhkl HyVgbbtcdGUEqGZWaMMNyq20kdwDg4Pvg109/wCJdEurvR5oNG1CL+zFji2vqSP5saMzAcQDDZbr yMDp3rlqKK2EpV5KVS91dbtb6PZoV7X8zotT8Q6de6XqVrBpl1DLeagL1ZHvVdY+GG0qIhu++3OR 2445kv8AxXaSavDrOl6S1rqwvEvZbiW7Mq+YpzhECrtUtkkMXPQAjnPM0Vl/Z+G7Pr9qXW1766rR aPQpzb3/AK/q51mv+MYtegjhuG8RSQi4WWSC7103EW0ZyEVosq2DgMS2O4NQ6j4h0W816z1ODSL+ FoXi82N9RRxIsaqqhSIRtPyjJO7vxXM0VFPK8JTiowi0kmviltLfr/XQJTctzqz4wtbfz5tN025g vG1ZNTglkvFdY2QkhSojUsPmbnI7ehy3xL4w/wCEgsPs/m6+f3wl8q/1s3cC8HhUMYIIzwSxIGeu c1y1FEcrwkasaqj7y2d2/wA2P2kv6/rzN3xBrmm6y8tzbaO9tf3U3nXNxJdmUbsciNAqhVJJJDbz 0wRznCoorsoUIUKap072Xdt/m2yW29wrZ8Q39tfQ6MtrJ5httNjgl+Uja4dyRz14I5HFY1aOraT/ AGXHp7ed5v22zW6xs27NzMNvU5+71461FRU3Wg5P3tbfqCvrbt+qM6iiiukQUUUUAFFFFAElvcTW lxHcWsskM0TB45Y2KsjDkEEcg+9b+reOtf1a3sIptX1LFpGmd97I3mSq7MsvXhhkAHkjaOa5yiua rhaFacalSCbjs2thptbGvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pci GVZohNeyPskX7rjJ4YdiORWRRSWDwytanHTbRaBzS7mvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ 4YdiORRc+LvEl6IheeINVuBDKJovNvZG8tx0cZPDDJwRzWRRQsFhVa1OOm2iDml3Oj1bx1r+rW9h FNq+pYtI0zvvZG8yVXZll68MMgA8kbRzVO78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecisiio p4DCU0lCnFW20XUfNLua934s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34n1nVlig1/WNU1K yWVZHt5r12zj03bgGwSAcHGeh6VkUVaweGjblppW2skrenb5C5pdzevPFVyI4rTw+smi2ELiRIba dt8kgIIllk4LuMDBwFXHyquTmXVvHWv6tb2EU2r6li0jTO+9kbzJVdmWXrwwyADyRtHNc5Wpe6ZD YeH7C4naT7dfM0qRZG1LcHarEYzlmD456KDzuGOeWDwVOcL005Xdr6u9rttvV+bf5jTlrYfd+LPE d+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWVGn mSKm5V3EDcxwB7mui8U+CL/wlb2cuoz2xa6jV1iSdHbkEnAVmyo+X5jjO4Yzg4JQy+jVhRlGKlK/ KrK/nbT7wTnK9ilc+LvEl6IheeINVuBDKJovNvZG8tx0cZPDDJwRzVjXfGmta/p9pZ32pX8sEMIj ljmvHkWZwzN5hB4zhgOc/d61gUVssDhVKM1TinHbRaBzS7mz4hv7a+h0ZbWTzDbabHBL8pG1w7kj nrwRyOKyre4mtLiO4tZZIZomDxyxsVZGHIII5B96u6tpP9lx6e3neb9ts1usbNuzczDb1Ofu9eOt Z1Vho0vYKMNY+YnfT0X5HR6t461/Vrewim1fUsWkaZ33sjeZKrsyy9eGGQAeSNo5qnd+LPEd+sS3 2v6pciGVZohNeyPskX7rjJ4YdiORWRRUU8BhKaShTirbaLqPml3Ne78WeI79Ylvtf1S5EMqzRCa9 kfZIv3XGTww7Ecii78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7EcisiirWDwytanHTbRaC5pdzX u/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIou/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxH IrIooWDwytanHTbRaBzS7mvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6p ciGVZohNeyPskX7rjJ4YdiORWRRQsHhla1OOm2i0Dml3Ne78WeI79Ylvtf1S5EMqzRCa9kfZIv3X GTww7Ecii58XeJL0RC88QarcCGUTRebeyN5bjo4yeGGTgjmsiihYLCq1qcdNtEHNLub+u+NNa1/T 7SzvtSv5YIYRHLHNePIszhmbzCDxnDAc5+71rAooq6GHpYeHs6MVFdkDbe5Jb3E1pcR3FrLJDNEw eOWNirIw5BBHIPvW/q3jrX9Wt7CKbV9SxaRpnfeyN5kquzLL14YZAB5I2jmucoqauFoVpxqVIJuO za2BNrY17vxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKLnxd4kvRELzxBqtwIZRNF5t7I3luO jjJ4YZOCOayKKSwWFVrU46baIOaXc6PVvHWv6tb2EU2r6li0jTO+9kbzJVdmWXrwwyADyRtHNU7v xZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKj1LRxpx0zddKVv7VLkuyECLczLg4ySBtzkD8Ks6 voum2ulRaho+rSX0LXL2zCe18hiyqrbkG5tyYYcnBGRlRkVxUqeXw9nGnTWt+X3dPPW2nzauVeT6 9PwIrnxd4kvRELzxBqtwIZRNF5t7I3luOjjJ4YZOCOasa7401rX9PtLO+1K/lghhEcsc148izOGZ vMIPGcMBzn7vWsCiutYHCqUZqnFOO2i0FzS7hRRRXYSFFFFABRRRQAUUVo6tpP8AZcent53m/bbN brGzbs3Mw29Tn7vXjrUSqRjJQb1e3yDczqnuL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoo08yRU 3Ku4gbmOAPc10XinwRf+Erezl1Ge2LXUausSTo7cgk4Cs2VHy/McZ3DGcHGFTEYeFaFKpJc8r8q6 u29v1Gk3exzdFFFdQgooooA2fEN/bX0OjLayeYbbTY4JflI2uHckc9eCORxWNUtsYBdwm8WRrcSL 5qxEBymfmCkggHGcZFaGqaZBo3iZrS6aSexSVXWSFgGmt2wyupIwCyEEZHGeRXJT5MOlQjd2Ta89 dfzX3j1av2sZVFaGu6X/AGPrVxZrJ5sKkPBMOksTANG4/wB5Sp/Gs+uinUjUgpx2eqBqzsFFFFWI KKKKACiiigAoorUvdMhsPD9hcTtJ9uvmaVIsjaluDtViMZyzB8c9FB53DGc6kYSjF7ydl91/0BK5 l1s+Ib+2vodGW1k8w22mxwS/KRtcO5I568Ecjior3TIbDw/YXE7Sfbr5mlSLI2pbg7VYjGcswfHP RQedwxl1jFU68o1l9m6/R/kPVfMKKKK6hBRRRQAUUUUAFFFFABRRRQAUUUUAFFS2ltJe3kNrAAZZ 5FjQE4yxOB/OtnWdAsrHT5brS9Skvltbv7HdeZa+SFkIYqU+ZtynY/JCngZUZrnniKVOpGnJ6vyf 4vZX6XtfoCTZg0UUV0AS2wgN3CLxpFtzIvmtEoLhM/MVBIBOM4yat67qn9sa1cXix+VCxCQQjpFE oCxoP91Qo/CpL3TIbDw/YXE7Sfbr5mlSLI2pbg7VYjGcswfHPRQedwxl1zU/Z1Z+2j0uvx1+9r8B 6pWCp7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qKNPMkVNyruIG5jgD3NdF4p8EX/hK3s5dRnti 11GrrEk6O3IJOArNlR8vzHGdwxnBwqmIw8K0KVSS55X5V1dt7fqCTd7HN0UUV1CNnxDf219Doy2s nmG202OCX5SNrh3JHPXgjkcVjVo6tpP9lx6e3neb9ts1usbNuzczDb1Ofu9eOtZ1c2FVNUYqk7xG 76ei/IKKKK6RBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRU9jZTajfQ2dr5fnTNsQSSrGpPuzEA fiamUowi5SdkgNnVdT065uNAZka8gs7GKK6hVjEWKyOWTcRxkEcgHrS+KvEVhr7QGwsLuwSDKxW7 3iSQQxnnZGixJt56kkk9SSear3vhTVtPsby7uktVhsbgW0+y+gdllP8ACFVyWPXoD91v7pxjV52H w+Em4VaUuZwuk1K6V9Xona+va9rFNyWj9Pu0CiiivTJCiiigAooooAKKKKACtnxDf219Doy2snmG 202OCX5SNrh3JHPXgjkcVjVo6tpP9lx6e3neb9ts1usbNuzczDb1Ofu9eOtc1RU3Wg5P3tbfqNX1 t2/VGdU9xfXd4MXd1NOPMaXEshb52xubnudoye+B6VFGnmSKm5V3EDcxwB7mui8U+CL/AMJW9nLq M9sWuo1dYknR25BJwFZsqPl+Y4zuGM4OFUxGHhWhSqSXPK/Kurtvb9QSbvY5uiiiuoQUUUUAFal7 qcN/4fsLedZPt1izRJJgbXtydyqTnOVYvjjowHG0Zy6KznTjOUZPeLuvut+oJ2NS91OG/wDD9hbz rJ9usWaJJMDa9uTuVSc5yrF8cdGA42jOXRRRTpxpR5Y7Xb+93Bu4UUUVoAUUUUAFFFFAEtsIDdwi 8aRbcyL5rRKC4TPzFQSATjOMmtDVNTg1nxM13dLJBYvKqLHCoLQ264VUUE4JVAAMnnHJrKorGVGM p8/W1vS+/wCn3BfSxoa7qn9sa1cXix+VCxCQQjpFEoCxoP8AdUKPwrPooq6cI04KEdloht3dwooo qxBRRRQAUUUUAFFFFABRRVu906Wwis5JmRheW4uI9pPClmXB465U/pUucU1FvVgVKKKKoCW1uZLO 7huYDtlhdZEOM4YHI/UVta14gsr6xltdK02axS6u/tlz510JtzgMFCYRNqje/ByeRzxWBRXPPD0q lSNSS1Xm/wAVs7dL3t0Gm0FS2wgN3CLxpFtzIvmtEoLhM/MVBIBOM4yaioreSumiTQ13VP7Y1q4v Fj8qFiEghHSKJQFjQf7qhR+FZ9W73TpbCKzkmZGF5bi4j2k8KWZcHjrlT+lVKzoqmqajT+FaL5aF Ntu4VPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelRRp5kipuVdxA3McAe5rovFPgi/8ACVvZy6jP bFrqNXWJJ0duQScBWbKj5fmOM7hjODjKpiMPCtClUkueV+VdXbe36gk3exzdFFFdQjZ8Q39tfQ6M trJ5httNjgl+Uja4dyRz14I5HFY1aOraT/Zcent53m/bbNbrGzbs3Mw29Tn7vXjrWdXNhVTVGKpO 8Ru+novyCiiiukQUUU6NQ8qIzrGrMAXbOF9zgE4+gNDdlcBtFdH4g8LRaPo9rqNtd3U0NxIUQ3di bbzxtBEsOWJkj/2iFIyvHPHOVhh8RSxNP2lJ3Xo1to9HZjaa3CiiitxBRRRQAUUVbvdOlsIrOSZk YXluLiPaTwpZlweOuVP6VLnFNRb1YFSiiiqAKKKKANzxB4nl163tIngWDy8y3DK2Tc3DAB5m9yFX j1ye9YdFW73TpbCKzkmZGF5bi4j2k8KWZcHjrlT+lc9KnRw0Y0aastbL8WO7bKlFFFdAgoq3e6dL YRWckzIwvLcXEe0nhSzLg8dcqf0qpUxnGa5ovQAoooqgCiird7p0thFZyTMjC8txcR7SeFLMuDx1 yp/Spc4pqLerAqVs+Ib+2vodGW1k8w22mxwS/KRtcO5I568EcjisatHVtJ/suPT287zfttmt1jZt 2bmYbepz93rx1rCoqbrQcn72tv1Gr627fqjOqe4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KijTz JFTcq7iBuY4A9zXReKfBF/4St7OXUZ7YtdRq6xJOjtyCTgKzZUfL8xxncMZwcKpiMPCtClUkueV+ VdXbe36gk3exzdFFFdQgooooAKKKKACnwzS21xHPbyPFNEweOSNirIwOQQR0IPemUUmk1Zga934s 8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZF FcyweGVrU46baLQfNLua934s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyI ZVmiE17I+yRfuuMnhh2I5FZFFCweGVrU46baLQOaXc17vxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZP DDsRyKj1HxNr2sWwttW1vUb6AMHEVzdySKGGQDhiRnk8+9ZlFOOEw0GnGnFW20WnoHNLuFFFFdIg ooooAKKKKACiiigAooooAKKKKAJLe4mtLiO4tZZIZomDxyxsVZGHIII5B9639W8da/q1vYRTavqW LSNM772RvMlV2ZZevDDIAPJG0c1zlakWildQ0mG9n8qHUlSRZIU8xo0Zyn3SVycqeM/jXFiaWFcl VrxTcb2bV3tqCbV7dh934s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZV miE17I+yRfuuMnhh2I5FX9e8K2unQSS6TqFxeiDUG0+YXFmLc+aAcFCHcMvBzyCPlyPmqhe+FtWs Wtg8EVx9qm8iJrK5iug0vH7vMTMA3I+U8muWjLLJxi4qK3tdKL87JpP10NHzq9wu/FniO/WJb7X9 UuRDKs0QmvZH2SL91xk8MOxHIou/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIq7f+DLvTPDja leTRCUX6WYSGeGaLLIzcypIQrDZyrAYDKc81Vv8Awxd2WrWGmqY3uL2FJEJuIPLYsSBtlWRkK5HU kfQUqVTK529nyaXtounxW8tdXsJ86vcZd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRc+LvE l6IheeINVuBDKJovNvZG8tx0cZPDDJwRzUU+galb2f2mSFDGLk2hWOZHdZRn5SiksM7TgkYOOM1P qnhPV9G0831/Dbi3WcWzvDeQzbJcE7GCOSrYU8EDpWqjlqlGK5L6pL3d+qX62D3/ADJtd8aa1r+n 2lnfalfywQwiOWOa8eRZnDM3mEHjOGA5z93rWBVu906Wwis5JmRheW4uI9pPClmXB465U/pVSurC 0qFGko4dJR8iW27XCp7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qKNPMkVNyruIG5jgD3NdF4p8 EX/hK3s5dRnti11GrrEk6O3IJOArNlR8vzHGdwxnBwqmIw8K0KVSS55X5V1dt7fqCTd7HN0UUV1C NnxDf219Doy2snmG202OCX5SNrh3JHPXgjkcVjVbvdOlsIrOSZkYXluLiPaTwpZlweOuVP6VUrDD whCko03dA+novyCiiitwCnxOscyO8ayqrAmNydrj0OCDg+xB96ZRSaurAb2qa5p02inS9E0u4sbe S6F1L9pvftB3BSqqmEQKuGbOQxPy5PFYNFFZUaEKEeWHrq2397bY22wooorYQUUU+GNZbiON5UhV 2CtLICVQE/eO0E4HXgE+xpN2VwFt7ia0uI7i1lkhmiYPHLGxVkYcggjkH3rf1bx1r+rW9hFNq+pY tI0zvvZG8yVXZll68MMgA8kbRzWdrGgX+hyR/bER4J9xt7uBxJDcAHBKOOGxkZHUZwQDxTovD95N f6VZxNEZdVRHg+YgKGdkG4kccqSevFefUWBrcuInyytez0enUa5otpf0h934s8R36xLfa/qlyIZV miE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FS32l+H0s3fSfEE11d LMIhBcWHkCQH+NX3sAv+9tPI464ra5okuhXFtBcMGea3WfcskUiHJI+V43dWXjrkH2FRSWAnKMYw Setk48r87JpO2u5T5+5Jd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciG VZohNeyPskX7rjJ4YdiORWXEI2mQTsyRFhvZF3Mq55IBIyfbI+tegXXw102x1q202+1jVbWW8nMN o8+joFuSHVcpicnHzAgsACM4JPFZYqpluClGNWCTabVoN6Le1k/V+WoLnkm0cnc+LvEl6IheeINV uBDKJovNvZG8tx0cZPDDJwRzVjXfGmta/p9pZ32pX8sEMIjljmvHkWZwzN5hB4zhgOc/d61Y1Hwn bad4en1KS8u0fMD2kM1oii4hm3lHLLK204jkJXBxgc88Yd7p0thFZyTMjC8txcR7SeFLMuDx1yp/ SroQy6tKM6UY3i3b3ba2u7aLo9/1Buae/T8LlSpLe4mtLiO4tZZIZomDxyxsVZGHIII5B96SGNZb iON5UhV2CtLICVQE/eO0E4HXgE+xq/rGgX+hyR/bER4J9xt7uBxJDcAHBKOOGxkZHUZwQDxXoTqU uZUptXl0fXv6+ZFjR1bx1r+rW9hFNq+pYtI0zvvZG8yVXZll68MMgA8kbRzVO78WeI79Ylvtf1S5 EMqzRCa9kfZIv3XGTww7Ecip18Owpq2h2lzeukerQxSmSOAMYd7soG0sN2COuR1q9qXg+x0iwvZ7 7VLnfa30NuBDZK6SxShmWVWMo/gRjtx97CkjkjyIzyqi4U4wXlaLe7t277/K/Qv32t+35afgZV34 s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5Fa es+E9N0fWLGGTW5Dp07GO4uns8PbSqFLxmJXbJUOnRupPpmotf8AD+iaTpsM1nrl1cXU8MVxFbz6 cIg0b553LK4BGOQfXgmqpVstm6apw+L4f3b72evLp53tbqO09dfxKNz4u8SXoiF54g1W4EMomi82 9kby3HRxk8MMnBHNWNd8aa1r+n2lnfalfywQwiOWOa8eRZnDM3mEHjOGA5z93rWBVu906Wwis5Jm RheW4uI9pPClmXB465U/pXb9TwcakH7OKavy6L52J5pa69PwKlbPiG/tr6HRltZPMNtpscEvykbX DuSOevBHI4rGq3e6dLYRWckzIwvLcXEe0nhSzLg8dcqf0repCDqwlJ6q9v1JXW3b9UVKnuL67vBi 7uppx5jS4lkLfO2Nzc9ztGT3wPSoo08yRU3Ku4gbmOAPc10XinwRf+Erezl1Ge2LXUausSTo7cgk 4Cs2VHy/McZ3DGcHEVMRh4VoUqklzyvyrq7b2/UaTd7HN0UUV1CCiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAJLe4mtLiO4tZZIZomDxyxsVZGHIII5B966W68 e6tqUulLq17qV3aWQj8+3e/ci5ZZC+87gQGwQMkHpXLVbvdOlsIrOSZkYXluLiPaTwpZlweOuVP6 Vx4jC4WvOLrRTlql387ME3ql2Op1X4gjWdQ+0anp81+tvfLeWK3155xgBIMkLHYPMibaMLhdvvyD Pf8AxIF1b2YW21S4uLO+W9im1PVvtXI4Me0RqAhHZdpGTyeMcJRXH/YmAXLan8O2stL6Pr169223 qy/aTbbvudNNr3h7+wJdKs9C1CKOa8iunkk1RHb5Ay7R+4AwVd8HGQSCcgbSmr+I9Kvf7Lk03Sby 1uNNSOKNri/SZGRGZsFRCh3Et1zjA6VzVFbxy3DRlzWd9d5Se6s93rp3E5N38zrtQ8VaDd2ksEXh y5RZ9RW/m8zU9/mEFt0fES4UqxAxhgTkluAE17xzLqlnbw2TasktvdC5iudQ1Q3csBAICxPsQxjn J65Kp0288lRUxyrCRlGXK243teUnvvu2P2kv6/rzN/XfGmta/p9pZ32pX8sEMIjljmvHkWZwzN5h B4zhgOc/d61gVbvdOlsIrOSZkYXluLiPaTwpZlweOuVP6VUrqwtKhRpKOHSUfIltu1wqe4vru8GL u6mnHmNLiWQt87Y3Nz3O0ZPfA9KijTzJFTcq7iBuY4A9zXReKfBF/wCErezl1Ge2LXUausSTo7cg k4Cs2VHy/McZ3DGcHCqYjDwrQpVJLnlflXV23t+oJN3sc3UlvcTWlxHcWsskM0TB45Y2KsjDkEEc g+9R0V0tKSsxHR6t461/Vrewim1fUsWkaZ33sjeZKrsyy9eGGQAeSNo5qnd+LPEd+sS32v6pciGV ZohNeyPskX7rjJ4YdiORWRRXHTwGEppKFOKttoupXNLua934s8R36xLfa/qlyIZVmiE17I+yRfuu Mnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZFFWsHhla1OOm2i0FzS7mvd+LPEd+ sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWRRQsH hla1OOm2i0Dml3Ne78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecii78WeI79Ylvtf1S5EMqzRC a9kfZIv3XGTww7EcisiihYPDK1qcdNtFoHNLua934s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5 FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZFFCweGVrU46baLQOaXc17vxZ4jv1iW+1/VL kQyrNEJr2R9ki/dcZPDDsRyKLvxPrOrLFBr+sapqVksqyPbzXrtnHpu3ANgkA4OM9D0rIooWDw0b ctNK21klb07fIOaXc3rzxVciOK08PrJothC4kSG2nbfJICCJZZOC7jAwcBVx8qrk5uXPxE1+6m0p 5tRvZ108Rlorm7eWO4dHZg7KT1wQPXA61ytW73TpbCKzkmZGF5bi4j2k8KWZcHjrlT+lc8svwV4x lBN62vq9d9Xq35vUfNLWx0Nz4vsz4dbQ9PtdXh02a4SSW2n1cSxqisWKxL5ShCSc7iG6Dg1T8Ra3 pGr2dlHYaXe2k1nAtujzX6TK0aljyohQ7st1zjjpXP0VVLLcNSmpwTTTb+KW73b11v53Dnkx8RjW ZDOjPEGG9UbazLnkAkHB98H6V0ep+LIbrxZaa1Y2l3CkF59sNrc3omQSeYHOzEa7AcDsTx1rmaK3 q4WlWmpzV2k1u9nvpe3z3Fd2sddrPxAu9V037LDbmyki1L7ZazwzYa3jVSI4lwB9zcSGGOp4qpq3 jrX9Wt7CKbV9SxaRpnfeyN5kquzLL14YZAB5I2jmucq3e6dLYRWckzIwvLcXEe0nhSzLg8dcqf0r lhluAouMVTV1e3Xffcrnk23f+rly78T6zqyxQa/rGqalZLKsj28167Zx6btwDYJAODjPQ9KfqniJ 7qyGmaTb/wBl6SOTaRysxnb+/M3HmNwOwUfwquTnForpWDw8XFxgly7JbX722v52uTzM6a51ywTV PDd4qvdpptnCs0Ub+UfMSR227ip9Rzg1dXxzZNClpd6NNc2MWppfRI96PNCKJD5DP5eCm+Vm+6D8 zDvkcve6dLYRWckzIwvLcXEe0nhSzLg8dcqf0qpXH/ZuDrQXMnJLS92ur7Na6vXcfM7fd+R2GreO LfXNJvbPU9Mkkaa9F3DNC9tAyHBB3+Xbr5jNk5Y4/h4GDnL8Sa1p2siw/s7TrqyNpbrbHz7xZ96L 908Rpg8nPXPHA74dFbUMtwuHkpUY8tr2Sbtra+l7dO2+u43Uk9yS3uJrS4juLWWSGaJg8csbFWRh yCCOQfet/VvHWv6tb2EU2r6li0jTO+9kbzJVdmWXrwwyADyRtHNc5Vu906Wwis5JmRheW4uI9pPC lmXB465U/pWtbD4apVjKrFOSva6+8lNq9i5c+LvEl6IheeINVuBDKJovNvZG8tx0cZPDDJwRzVjX fGmta/p9pZ32pX8sEMIjljmvHkWZwzN5hB4zhgOc/d61gUUlgcKpRmqcU47aLQfNLuFT3F9d3gxd 3U048xpcSyFvnbG5ue52jJ74HpUUaeZIqblXcQNzHAHua6LxT4Iv/CVvZy6jPbFrqNXWJJ0duQSc BWbKj5fmOM7hjODiqmIw8K0KVSS55X5V1dt7fqJJu9jm6KKK6hBRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAElvcTWlxHcWsskM0TB45Y2KsjDkEEcg+9b+reO tf1a3sIptX1LFpGmd97I3mSq7MsvXhhkAHkjaOa5yiuarhaFacalSCbjs2thptbGvd+LPEd+sS32 v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWRRSWDwyta nHTbRaBzS7mvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyP skX7rjJ4YdiORWRRQsHhla1OOm2i0Dml3Ne78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecii58 XeJL0RC88QarcCGUTRebeyN5bjo4yeGGTgjmsiihYLCq1qcdNtEHNLub+u+NNa1/T7SzvtSv5YIY RHLHNePIszhmbzCDxnDAc5+71rAooq6GHpYeHs6MVFdkDbe4VPcX13eDF3dTTjzGlxLIW+dsbm57 naMnvgelRRp5kipuVdxA3McAe5rpPE3ga/8AC0di2o3NoGvERlQToxGc5PyM3yj5fmOM7uM4OIq4 jD060KdSSU5X5V1dt7fqCTaduhzNFdN4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHB4 m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHGNPM8FV5OSonz35fO29vTqNwkr3WxzNFdN 4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHB4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5 R8vzHGd3GcHBTzPBVeTkqJ89+Xztvb06g4SV7rY5mium8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8 o+X5jjO7jODg8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODgp5ngqvJyVE+e/L523t6d QcJK91sczRXTeJvA1/4WjsW1G5tA14iMqCdGIznJ+Rm+UfL8xxndxnBweJvA1/4WjsW1G5tA14iM qCdGIznJ+Rm+UfL8xxndxnBwU8zwVXk5KifPfl87b29OoOEle62OZorpvE3ga/8AC0di2o3NoGvE RlQToxGc5PyM3yj5fmOM7uM4ODxN4Gv/AAtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODgp5ngq vJyVE+e/L523t6dQcJK91sczRXTeJvA1/wCFo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcHibw Nf8AhaOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHBTzPBVeTkqJ89+Xztvb06g4SV7rY5mium8T eBr/AMLR2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg4PE3ga/wDC0di2o3NoGvERlQToxGc5PyM3 yj5fmOM7uM4OCnmeCq8nJUT578vnbe3p1Bwkr3WxztvcTWlxHcWsskM0TB45Y2KsjDkEEcg+9b+r eOtf1a3sIptX1LFpGmd97I3mSq7MsvXhhkAHkjaOaf4m8DX/AIWjsW1G5tA14iMqCdGIznJ+Rm+U fL8xxndxnBweJvA1/wCFo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcc31nK8XOlUbjJyvyPe9t 7enXsPlnG/pr6FC78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecii78WeI79Ylvtf1S5EMqzRCa 9kfZIv3XGTww7Ecir/ibwNf+Fo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcHibwNf+Fo7FtRub QNeIjKgnRiM5yfkZvlHy/McZ3cZwcTSr5TU9n7PkfNflslrb4radOo3zq9yhd+LPEd+sS32v6pci GVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORV/xN4Gv/C0di2o3 NoGvERlQToxGc5PyM3yj5fmOM7uM4ODxN4Gv/C0di2o3NoGvERlQToxGc5PyM3yj5fmOM7uM4OCl Xymp7P2fI+a/LZLW3xW06dQfOr3KFz4u8SXoiF54g1W4EMomi829kby3HRxk8MMnBHNWNd8aa1r+ n2lnfalfywQwiOWOa8eRZnDM3mEHjOGA5z93rU/ibwNf+Fo7FtRubQNeIjKgnRiM5yfkZvlHy/Mc Z3cZwcHibwNf+Fo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcKlVyipKlOlyXd3CyWtt7enUH7R Xv2/A5mpLe4mtLiO4tZZIZomDxyxsVZGHIII5B966LxN4Gv/AAtHYtqNzaBrxEZUE6MRnOT8jN8o +X5jjO7jODg8TeBr/wALR2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg464Zlgqygo1E/aX5f71t7 d7dSXCSvdbDNW8da/q1vYRTavqWLSNM772RvMlV2ZZevDDIAPJG0c1Tu/FniO/WJb7X9UuRDKs0Q mvZH2SL91xk8MOxHIq/4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHB4m8DX/haOxbUb m0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHHHh6mUNU1R5Pevy2S1t8VvTqU/aK9+i/AoXfizxHfrEt9r +qXIhlWaITXsj7JF+64yeGHYjkUXfizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkVf8TeBr/wAL R2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg4PE3ga/8AC0di2o3NoGvERlQToxGc5PyM3yj5fmOM 7uM4OKpV8pqez9nyPmvy2S1t8VtOnUHzq9yhc+LvEl6IheeINVuBDKJovNvZG8tx0cZPDDJwRzVj XfGmta/p9pZ32pX8sEMIjljmvHkWZwzN5hB4zhgOc/d61P4m8DX/AIWjsW1G5tA14iMqCdGIznJ+ Rm+UfL8xxndxnBweJvA1/wCFo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcKlVyipKlOlyXd3Cy Wtt7enUH7RXv2/A5mium8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODg8TeBr/wtHYtq NzaBrxEZUE6MRnOT8jN8o+X5jjO7jODjsp5ngqvJyVE+e/L523t6dSXCSvdbHM1PcX13eDF3dTTj zGlxLIW+dsbm57naMnvgelb/AIm8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHDfFPgi/8 JW9nLqM9sWuo1dYknR25BJwFZsqPl+Y4zuGM4OFTzHA13TcKibnfl87b29OockldWObooor0SQoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACp7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qCik4ptNrYCe4vru8GLu6mnHmNLi WQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qCipVOCtZbAT3F9d3gxd3U04 8xpcSyFvnbG5ue52jJ74HpRcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelQUUKnBWstgJ7i+u7wYu 7qaceY0uJZC3ztjc3Pc7Rk98D0ouL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKFTgrWWwE9xfX d4MXd1NOPMaXEshb52xubnudoye+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUFFCpwVrLYC e4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qCihU4K 1lsBPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelFxfXd4MXd1NOPMaXEshb52xubnudoye+B6VBR QqcFay2AnuL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSi4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA 9KgooVOCtZbAT3F9d3gxd3U048xpcSyFvnbG5ue52jJ74HpRcX13eDF3dTTjzGlxLIW+dsbm57na MnvgelQUUKnBWstgJ7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0ouL67vBi7uppx5jS4lkLfO2Nz c9ztGT3wPSoKKFTgrWWwE9xfXd4MXd1NOPMaXEshb52xubnudoye+B6UXF9d3gxd3U048xpcSyFv nbG5ue52jJ74HpUFFCpwVrLYCe4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0u JZC3ztjc3Pc7Rk98D0qCihU4K1lsBPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelFxfXd4MXd1NO PMaXEshb52xubnudoye+B6VBRQqcFay2AnuL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSi4vru8GL u6mnHmNLiWQt87Y3Nz3O0ZPfA9KgooVOCtZbAT3F9d3gxd3U048xpcSyFvnbG5ue52jJ74HpRcX1 3eDF3dTTjzGlxLIW+dsbm57naMnvgelQUUKnBWstgJ7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0 ouL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKFTgrWWwE9xfXd4MXd1NOPMaXEshb52xubnudoy e+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUFFCpwVrLYCe4vru8GLu6mnHmNLiWQt87Y3Nz 3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qCihU4K1lsAUUUVYBRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQB//Z --_004_2C5AD5728DB9B24189E3A93140E45786367D1Fszxeml522mbxchina_-- From prvs=098533321=Nicolas.BOUTHORS@qosmos.com Tue Jan 28 01:54:07 2014 Return-Path: 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 181911A0348 for ; Tue, 28 Jan 2014 01:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.051 X-Spam-Level: **** X-Spam-Status: No, score=4.051 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 Nu_4K7BfcJ2n for ; Tue, 28 Jan 2014 01:54:04 -0800 (PST) Received: from smtp-ft4.fr.colt.net (smtp-ft4.fr.colt.net [213.41.78.208]) by ietfa.amsl.com (Postfix) with ESMTP id 62AF91A014C for ; Tue, 28 Jan 2014 01:54:04 -0800 (PST) Received: from smtp-ex3.fr.colt.net (smtp-ex3.fr.colt.net [213.41.78.196]) by smtp-ft4.fr.colt.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s0S9s0Oa026071 for ; Tue, 28 Jan 2014 10:54:00 +0100 Received: from mx1.qosmos.net ([195.68.92.43] helo=mx3.qosmos.com) by smtp-ex3.fr.colt.net with esmtp (Exim) (envelope-from ) id 1W85Mk-0007BI-06 for ; Tue, 28 Jan 2014 10:54:00 +0100 X-IronPort-AV: E=Sophos;i="4.95,735,1384297200"; d="scan'208,217";a="816820" Received: from unknown (HELO mailbox.jungle.qosmos.com) ([10.12.1.3]) by mx3.qosmos.com with ESMTP; 28 Jan 2014 10:53:57 +0100 Received: from LILAS.jungle.qosmos.com ([fe80::5524:2c18:b2c3:74d4]) by CAROUBIER.jungle.qosmos.com ([169.254.1.72]) with mapi id 14.01.0438.000; Tue, 28 Jan 2014 10:53:57 +0100 From: Nicolas BOUTHORS To: Leejun , Zhuangyuxin , Ron Parker , "sfc@ietf.org" , Melinda Shore Thread-Topic: =?gb2312?B?W3NmY10gtPC4tDogU2VydmljZXMgZWxpZ2libGUgZm9yIGNoYWluaW5n?= Thread-Index: AQHPG87tQWtvxQjgO0CiCLvrqfOxEJqZ0GxE Date: Tue, 28 Jan 2014 09:53:56 +0000 Message-ID: <76B41B8FACE1514795D30EC137FF391D3D098B@LILAS.jungle.qosmos.com> References: <9C2DE4B8FE85984BA1B0581235F6B2ED0F633EAB@SZXEMA502-MBS.china.huawei.com> <9C2DE4B8FE85984BA1B0581235F6B2ED0F633F22@SZXEMA502-MBS.china.huawei.com> <9C2DE4B8FE85984BA1B0581235F6B2ED0F6350D1@SZXEMA502-MBS.china.huawei.com>, <81126FE293D58240BD872F99F2606543368E3E75@szxema507-mbs.china.huawei.com> In-Reply-To: <81126FE293D58240BD872F99F2606543368E3E75@szxema507-mbs.china.huawei.com> Accept-Language: en-US, fr-FR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.0.22] Content-Type: multipart/alternative; boundary="_000_76B41B8FACE1514795D30EC137FF391D3D098BLILASjungleqosmos_" MIME-Version: 1.0 X-ACL-Warn: 1/1 recipients OK. Subject: Re: [sfc] =?gb2312?b?tPC4tDogU2VydmljZXMgZWxpZ2libGUgZm9yIGNoYWluaW5n?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 09:54:07 -0000 --_000_76B41B8FACE1514795D30EC137FF391D3D098BLILASjungleqosmos_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 c2ZjIGNoYWluIGVkZ2Ugbm9kZXMgaGF2ZSB0aGUgcmVzcG9uc2liaWxpdHkgdG8gaW5zZXJ0L2V4 dHJhY3QgdGhlIHRyYWZmaWMgaW50byB0aGUgY2hhaW4uICBBbiBlZGdlIG5vZGUgdmlydHVhbCBz d2l0Y2ggZm9yIGV4YW1wbGUgd2lsbCBoYXZlIHRoZSByZXNwb25zaWJpbGl0eSB0byByZWNlaXZl IGluY29taW5nDQpwYWNrZXRzIGFuZCB0aWUgdGhlbSB0byBjb3JyZXNwb25kaW5nIHNlcnZpY2Ug Y2hhaW5zLiBGcm9tIHRoYXQgcG9pbnQgaXQgY2FuIHNlbGVjdCB0aGUgbmV4dCBsb2NhbCBzZXJ2 aWNlIGZ1bmN0aW9uIG9yIHNlcnZpY2UgSG9wIHRoYXQgc2hvdWxkIHByb2Nlc3MgdGhlIHBhY2tl dHMuDQoNCkxldCdzIGFzc3VtZSB0aGUgU2VydmljZSBOb2RlIGlzIGEgTkFULiBUaGUgTkFUIHRh a2VzIHRoZSBpbmNvbWluZyBwYWNrZXQgZnJvbSB0aGlzIGludGVybmV0LCBkb2VzIGl0cyBqb2Ig YW5kIHNlbmRzIHRoZSB0cmFmZmljIHRvIHRoZSBuZXcgZGVzdGluYXRpb24gSVAvcG9ydC4gIFNv bWVob3csICB0aGUgU2VydmljZSBOb2RlIG11c3QgYXNzb2NpYXRlIHRoaXMgcGFja2V0IHRvIGEg c2VydmljZSBjaGFpbiBhbmQgZW5jYXBzdWxhdGUgdGhlIHBhY2tldCBzbyB0aGF0IGl0IGdvZXMg dG8gdGhlIG5leHQgU2VydmljZSBIb3AuIEkgZG9uJ3Qgc2VlIGhvdyB0aGUgU2VydmljZSBOb2Rl IHZpcnR1YWwgc3dpdGNoIGNhbiBkbyB0aGF0IHdpdGhvdXQgc29tZSBraW5kIG9mIGhpbnQgZnJv bSB0aGUgTkFUIFNlcnZpY2UgRnVuY3Rpb246IHRoZSBOQVQgY291bGQgZm9yIGV4YW1wbGUgY29u ZmlndXJlIHRoZSB2aXJ0dWFsIHN3aXRjaCB3aGVuIGl0IGNyZWF0ZSBhIG1hcCBlbnRyeSBmb3Ig YSBUQ1Agb3IgVURQIGZsb3cuICBBIGxlZ2FjeSBOQVQgcnVubmluZyBpbiBhIFZNIGFuZCByZWx5 aW5nIG9ubHkgb24gc29ja2V0IGNvbm5lY3Rpb25zIGNvdWxkIG5vdCBkbyB0aGUgam9iLg0KDQpX ZSBjb3VsZCBkZWNpZGUgbm90IHRvIGluY2x1ZGUgdGhlIE5BVCBpbiB0aGUgc2VydmljZSBjaGFp biwgdXNlIGl0IGFzIGEgZGVmYXVsdCBnYXRld2F5IGFuZCBkaXN0cmlidXRlIGl0cyBmdW5jdGlv biB2aWEgdmlydHVhbGl6YXRpb24gaW5kZXBlbmRlbnRseS4gIEl0IG1ha2VzIHNlbnNlIGlmIHdl IGRvbid0IGV4cGVjdCBpdCB0byBhcHBseSBhIHNwZWNpZmljIHBvbGljeSBkZXBlbmRpbmcgb24g dGhlIHNlcnZpY2UgY2hhaW4gYXNzb2NpYXRlZCB0byB0aGUgdHJhZmZpYy4gIFRoZSBkcmF3IGJh Y2sgaGVyZSBpcyB0aGF0IHdlIG1haW50YWluIGEgTkFUIGNvbmZpZ3VyYXRpb24gYW5kIG1hbmFn ZW1lbnQgc2lsbyBpbiB0aGUgaW5mcmFzdHJ1Y3R1cmUuDQoNCg0KVGhlIExCIGNhc2UgaXMgZGlm ZmVyZW50IGFuZCBjb3ZlcnMgZGlmZmVyZW50IGNhc2VzIGFzIGl0cyBzZXJ2ZXJzIGNhbiBiZSAi dmlzaWJsZSIgb3Igbm90IGZyb20gdGhlIHNlcnZpY2UgY2hhaW5pbmcgcG9pbnQgb2Ygdmlldy4g SW4gYWxsIGNhc2VzICB0aGUgTEIgaXRzZWxmIHNob3VsZCBiZSB2aXNpYmxlIGluIG9yZGVyIHRv IHJlY2VpdmUgIHRoZSB0cmFmZmljIHNvIHRoYXQgaXQgY2FuIGxvYWQgYmFsYW5jZSB0aGUgdHJh ZmZpYzogaXQgbXVzdCBiZSBhIFNlcnZpY2UgSG9wIGluIGEgU2VydmljZSBDaGFpbi4NCg0KTG9h ZCBiYWxhbmNpbmcgY2FuIGJlIGFjaGlldmVkIHdpdGhvdXQgYSBzcGVjaWZpYyBMQiBTZXJ2aWNl IEZ1bmN0aW9uOiBpZiB0aGUgc2VydmljZSBjaGFpbnMgY29udGFpbnMgdGhlIHNlbGVjdGVkIHNl cnZlciBpbnN0ZWFkIG9mIHRoZSBMQiBhcyBhIFNlcnZpY2UgSG9wLiBUaGlzIHRlY2huaWNhbGx5 IGZlYXNpYmxlIGF0IHRoZSBDbGFzc2lmaWVyIHBvaW50ICh0aGUgRWRnZSBOb2RlKSB3aGVuIHRo ZSBsb2FkIGJhbGFuY2luZyBjcml0ZXJpYSBpcyBhIGhhc2ggb24gSVAgc291cmNlIGZvciBleGFt cGxlLiAgSW4gZmFjdCB0aGUgTG9hZCBiYWxhbmNpbmcgcmVzcG9uc2liaWxpdHkgaXMgdGhlbiB0 cmFuc2ZlcnJlZCB0byB0aGUgQ2xhc3NpZmllci4gVGhpcyBwdXRzIGEgbG90IG9mIEhBIHJlc3Bv bnNpYmlsaXR5IG9uIHRoZSBjZW50cmFsIFNETiBjb250cm9sbGVyIHdoaWNoIG11c3QgdGhlbiBt b25pdG9yIHRoZSBzZXJ2ZXIgc3RhdHVzLg0KDQpBbHRob3VnaCB3ZSBjYW4gZG8gd2l0aG91dCBp biBzb21lIGNhc2VzLCBJIGJlbGlldmUgYXMgUm9uICB0aGF0IE5BVCBhbmQgTEIgYXJlIFNGQyBh d2FyZW5lc3MgY2FuZGlkYXRlIGFuZCBzaG91bGQgYXBwZWFyIGluIHRoZSB1c2UgY2FzZXMuDQoN Ck5pY29sYXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBMZWVqdW4g W2p1bi5sZWVAaHVhd2VpLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjgsIDIwMTQgMzox NSBBTQ0KVG86IFpodWFuZ3l1eGluOyBaaHVhbmd5dXhpbjsgUm9uIFBhcmtlcjsgc2ZjQGlldGYu b3JnOyBNZWxpbmRhIFNob3JlDQpTdWJqZWN0OiBbc2ZjXSC08Li0OiBTZXJ2aWNlcyBlbGlnaWJs ZSBmb3IgY2hhaW5pbmcNCg0KV2l0aG91dCBTRkMsIHBhY2tldHMgY2FuIGFscmVhZHkgYmUgZm9y d2FyZGVkIHRvIHNlcnZpY2UgZnVuY3Rpb25zIHdpdGggTDMgYWRkcmVzcy4gIEluIHRoaXMgcmVn YXJkLCAgc2VydmljZSBmdW5jdGlvbnMgd2l0aCBMMyBhZGRyZXNzIGFyZSBxdWl0ZSBkaWZmZXJl bnQgdG8gdGhvc2Ugoa50cmFuc3BhcmVudCBtaWRib3ihry4NClNvLCBJIHdvbmRlciB3aHkgU0ZD IHNob3VsZCBjb3ZlciBOQVQgYW5kIExCLg0KDQpSZWdhcmRzDQpMaSBqdW4NCg0KDQoNCreivP7I yzogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gWmh1YW5neXV4aW4NCrei y83KsbzkOiAyMDE0xOox1MIyOMjVIDg6NDgNCsrVvP7IyzogWmh1YW5neXV4aW47IFJvbiBQYXJr ZXI7IHNmY0BpZXRmLm9yZzsgTWVsaW5kYSBTaG9yZQ0K1vfM4jogW3NmY10gtPC4tDogU2Vydmlj ZXMgZWxpZ2libGUgZm9yIGNoYWluaW5nDQoNCkFjdHVhbGx5LCB3aXRoIHRoZXNlIHF1ZXN0aW9u cywgSaGvbSB0cnlpbmcgdG8gZmlndXJlIG91dCB3aGVuIHdlIHB1dCBhbnkgc2VydmljZSAoZS5n LiBOQVQvTEIvVlBOKSB3aXRoIEwzIGFkZHJlc3MgaW4gdGhlIGNoYWluLCBhKSBob3cgdGhlIHBv c3NpYmxlIEFSUCBwYWNrZXRzIGFyZSBoYW5kbGVkLCBiKSBob3cgdGhlIHJvdXRpbmcgdGFibGUg aXMgY29uZmlndXJlZCBmb3IgdGhlIHJvdXRlcnMgd2hpY2ggYXJlIG5vdCBpbiB0aGUgY2hhaW4s IGJ1dCB0aGUgdHJhZmZpYyBjb21pbmcgb3V0IG9mIHRoZSBjaGFpbiB3aWxsIGdvIHRocnUuDQoN Cg0KVGhhbmtzLA0KWXV4aW4NCg0Kt6K8/sjLOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRm Lm9yZ10gtPqx7SBaaHVhbmd5dXhpbg0Kt6LLzcqxvOQ6IDIwMTTE6jHUwjI3yNUgMTA6MzINCsrV vP7IyzogUm9uIFBhcmtlcjsgc2ZjQGlldGYub3JnDQrW98ziOiBbc2ZjXSC08Li0OiBTZXJ2aWNl cyBlbGlnaWJsZSBmb3IgY2hhaW5pbmcNCg0KSGksIFJvbiwNCg0KVGhhbmtzIGZvciB0aGUgcmVw bHkuDQoNCldoZW4gd2UgY29uc2lkZXIgaW5zZXJ0aW5nIExCL05BVCBpbiB0aGUgY2hhaW4sIEkg aGF2ZSBzb21lIGZ1cnRoZXIgcXVlc3Rpb25zIGhlcmUuDQoNCi0gICAgICAgIExldKGvcyB0YWtl IGEgY2hhaW4gd2l0aCBOQVQgc2VydmljZSBmdW5jdGlvbiBhcyBhbiBleGFtcGxlLCB1c2VyIGlz IHVzaW5nIHRoaXMgY2hhaW4gdG8gcHJvY2VzcyB0cmFmZmljIHByb2R1Y2VkIGJ5IFZNMSBhY2Nl c3NpbmcgSW50ZXJuZXQuIEkgYXNzdW1lIHRoZSB0b3BvbG9neSBpcyBsaWtlIHRoaXM6DQogICAg ICAgICBWTTEgIC0tLSAoY2hhaW4gaW5jbHVkaW5nIE5BVCkgLS0tIFJvdXRlciAtLS0gSW50ZXJu ZXQNCiAgICAgICAgIFdoZW4gdHJhZmZpYyBmcm9tIEludGVybmV0IGFycml2ZXMgYXQgdGhlIHJv dXRlciwgaXRzIGRlc3RJUCBwb2ludHMgYXQgTkFULiBIb3cgZG9lcyB0aGUgcm91dGVyIGRlY2lk ZSB0aGUgbmV4dCBob3A/DQotICAgICAgICBBcyB0aGUgcGFja2V0IGlzIGRpcmVjdGx5IGFkZHJl c3NlZCB0byB0aGUgTkFULCBkb2VzIGl0IGNvbmZsaWN0IHdpdGggdGhlIKGudHJhbnNwYXJlbnQg bWlkYm94oa8gY29uY2VwdCBpbiBkcmFmdC1wYXJrZXItc2ZjLWNoYWluLXRvLXBhdGgtMDA/DQot ICAgICAgICBJcyBpdCBwb3NzaWJsZSBmb3IgdGhlIFJvdXRlciB0byBzZW5kIG91dCBBUlAgdG8g cXVlcnkgZm9yIHRoZSBJUCBhZGRyZXNzIG9uIE5BVD8gSG93IGRvZXMgTkFUIHJlYWN0IHRvIEFS UCByZXF1ZXN0IGVzcGVjaWFsbHkgd2hlbiBOQVQgaXMgU0ZDLWF3YXJlPw0KDQpUaGFua3MsDQpZ dXhpbg0KDQq3orz+yMs6IFJvbiBQYXJrZXIgW21haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0 d29ya3MuY29tXQ0Kt6LLzcqxvOQ6IDIwMTTE6jHUwjI3yNUgOToyOQ0KytW8/sjLOiBaaHVhbmd5 dXhpbjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQrW98ziOiBSRTogU2Vydmlj ZXMgZWxpZ2libGUgZm9yIGNoYWluaW5nDQoNCll1eGluLA0KDQpCb3RoIGxvYWQgYmFsYW5jZXIg YW5kIE5BVCBhcmUgZGVmaW5pdGVseSBjYW5kaWRhdGVzIGZvciBTRkMgc2VydmljZSBmdW5jdGlv bnMuDQoNCiAgIFJvbg0KDQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgWmh1YW5neXV4aW4NClNlbnQ6IFN1bmRheSwgSmFudWFyeSAyNiwgMjAx NCA4OjA2IFBNDQpUbzogc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBbc2ZjXSBTZXJ2aWNlcyBlbGlnaWJsZSBmb3IgY2hhaW5pbmcNCg0KSGVsbG8sIEZvbGtzLA0K DQpGb3IgU0ZDLCBkbyB5b3UgaGF2ZSBhbnkgY29uY3JldGUgc2VydmljZSBjYW5kaWRhdGVzIHdo aWNoIGFyZSBlbGlnaWJsZSBmb3IgY2hhaW5pbmc/IEhvdyBhYm91dCBsb2FkIGJhbGFuY2VyIGFu ZCBOQVQsIHdoaWNoIHVzdWFsbHkgY3Jvc3Mgc3VibmV0cyBhbmQgY2hhbmdlIHBhY2tldCBoZWFk ZXI/IEFyZSB0aGV5IHN1aXRhYmxlIGZvciB0aGUgY2hhaW4gd2UgYXJlIGRpc2N1c3NpbmcgaGVy ZT8NCg0KVGhhbmtzLA0KWXV4aW4NCg== --_000_76B41B8FACE1514795D30EC137FF391D3D098BLILASjungleqosmos_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
sfc chain edge nodes have the responsibility to insert/extract the t= raffic into the chain.  An edge node = virtual switch for example will have the responsibility to receive incoming 
packets and tie them to corresponding= service chains. From that point it can select the next local service function or service Hop that should= process the packets.

Let's assume the Service Node is a NAT. The NAT takes the incoming pac= ket from this internet, does its job and sends the traffic to the new destination IP/port.  Somehow,  = the Service Node must associate this packet to a service chain and encapsulate the packet s= o that it goes to the next Ser= vice Hop. I don't see how the Service Node virtual switch can do that without some kind of hint from the NAT Service Function: the NAT could for example= configure the virtual switch when it create a map entry for a TCP or UDP flow.  A legacy NAT runnin= g in a VM and relying only on socket connections could not do the job.

We could decide not to include the NAT in the service= chain, use it as a default gateway and distribute its function via vi= rtualization independently.  It makes sen= se if we don't expect it to apply a specific policy depending on the service chain associated to the traffic.  The draw b= ack here is that we maintain a NAT configuration and management silo in the= infrastructure.


The LB case is different and covers different cases as its servers can= be "visible" or not from the service chaining point of view. In = all cases  the LB itself should = be visible in order to receive  the traffic so that it can load balance the traffic: it must be a Service Hop in a Service Chain.=  

Load balancing can be achieved without a specific LB Service Function:= if the service chains contains the selected server instead of the LB as a = Service Hop. This technically feasible at the Classifier point (the Edge Node) wh= en the load balancing criteria is a hash on IP source for example.  In f= act the Load balancing responsibility is then transferred to the Classifier. This puts a lot of HA = responsibility on the central SDN controller which must then monitor the server status.  

Although we can do without in some cases, I believe as Ron  that = NAT and LB are SFC awareness candidate and should appear in the use cases.<= /div>

Nicolas
From: Leejun [jun.lee@huawei.com]
Sent: Tuesday, January 28, 2014 3:15 AM
To: Zhuangyuxin; Zhuangyuxin; Ron Parker; sfc@ietf.org; Melinda Shor= e
Subject: [sfc] =B4=F0=B8=B4: Services eligible for chaining

Without= SFC, packets can already be forwarded to service functions with L3 address= .  In this regard,  service functions with L3 address are quite d= ifferent to those =A1=AEtransparent midbo= x=A1=AF.

So, I w= onder why SFC should cover NAT and LB.

 <= /span>

Regards=

Li jun<= /span>

 <= /span>

 <= /span>

 <= /span>

=B7=A2=BC=FE=C8=CB: sfc [mailto:sfc-bounces@ietf.org] =B4=FA= =B1=ED Zhuangyuxin
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C228=C8=D5 8:48
=CA=D5=BC=FE=C8=CB: Zhuangyuxin; Ron Parker; sfc@ietf.org; Melinda Shore
=D6=F7=CC=E2: [sfc] =B4=F0=B8=B4: Services eligible for cha= ining

 

Actuall= y, with these questions, I=A1=AFm trying to figure out when we put any serv= ice (e.g. NAT/LB/VPN) with L3 address in the chain, a) how the possible ARP= packets are handled, b) how the routing table is configured for the routers which are not in the chain, but the traffic = coming out of the chain will go thru.

 <= /span>

 <= /span>

Thanks,=

Yuxin

 <= /span>

=B7=A2=BC=FE=C8=CB: sfc [mailto:sfc-bounces@ietf.org] =B4=FA= =B1=ED Zhuangyuxin
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C227=C8=D5 10:32
=CA=D5=BC=FE=C8=CB: Ron Parker; sfc@ietf.org
=D6=F7=CC=E2: [sfc] =B4=F0=B8=B4: Services eligible for cha= ining

 

Hi, Ron= ,

 <= /span>

Thanks = for the reply.

 <= /span>

When we= consider inserting LB/NAT in the chain, I have some further questions here= .

 <= /span>

- =        Let=A1=AFs take a chain with NAT servi= ce function as an example, user is using this chain to process traffic prod= uced by VM1 accessing Internet. I assume the topology is like this:<= /p>

 &= nbsp;       VM1  --- (chain including NA= T) --- Router --- Internet

   &n= bsp;     When traffic from Internet arrives at the rout= er, its destIP points at NAT. How does the router decide the next hop?

-   &= nbsp;    As the packet is directly addressed to the NAT, doe= s it conflict with the =A1=AEtransparent midbox=A1=AF concept in draft-park= er-sfc-chain-to-path-00?

-   &= nbsp;    Is it possible for the Router to send out ARP to qu= ery for the IP address on NAT? How does NAT react to ARP request especially= when NAT is SFC-aware?

 <= /span>

Thanks,=

Yuxin

 <= /span>

=B7=A2=BC=FE=C8=CB: Ron Parker [mailto:Ron_Parker@affirmednetworks.= com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C227=C8=D5 9:29
=CA=D5=BC=FE=C8=CB: Zhuangyuxin; sfc@ietf.org
=D6=F7=CC=E2: RE: Services eligible for chaining

 

Yuxin,

 

Both load balancer and NAT are definitely candidates for SFC ser= vice functions.

 

   Ron

 

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Zhuangyuxin
Sent: Sunday, January 26, 2014 8:06 PM
To: sfc@ietf.org
Subject: [sfc] Services eligible for chaining

 

Hello, Folks,

 

For SFC, do you have any concre= te service candidates which are eligible for chaining? How about load balan= cer and NAT, which usually cross subnets and change packet header? Are they= suitable for the chain we are discussing here?

 

Thanks,

Yuxin

--_000_76B41B8FACE1514795D30EC137FF391D3D098BLILASjungleqosmos_-- From prvs=098533321=Nicolas.BOUTHORS@qosmos.com Tue Jan 28 02:14:02 2014 Return-Path: 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 086101A01ED for ; Tue, 28 Jan 2014 02:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.051 X-Spam-Level: **** X-Spam-Status: No, score=4.051 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 pJkOgl9tpeBp for ; Tue, 28 Jan 2014 02:13:58 -0800 (PST) Received: from smtp-ft5.fr.colt.net (smtp-ft5.fr.colt.net [213.41.78.197]) by ietfa.amsl.com (Postfix) with ESMTP id 52A021A0167 for ; Tue, 28 Jan 2014 02:13:57 -0800 (PST) Received: from smtp-ex1.fr.colt.net (smtp-ex1.fr.colt.net [213.41.78.194]) by smtp-ft5.fr.colt.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s0SADsq3010271 for ; Tue, 28 Jan 2014 11:13:54 +0100 Received: from smtp.qosmos.eu ([195.68.92.43] helo=mx3.qosmos.com) by smtp-ex1.fr.colt.net with esmtp (Exim) (envelope-from ) id 1W85g0-0008RP-1s for ; Tue, 28 Jan 2014 11:13:53 +0100 X-IronPort-AV: E=Sophos;i="4.95,735,1384297200"; d="jpg'145?scan'145,208,217,145";a="816886" Received: from unknown (HELO mailbox.jungle.qosmos.com) ([10.12.1.3]) by mx3.qosmos.com with ESMTP; 28 Jan 2014 11:13:52 +0100 Received: from LILAS.jungle.qosmos.com ([fe80::5524:2c18:b2c3:74d4]) by CAROUBIER.jungle.qosmos.com ([169.254.1.72]) with mapi id 14.01.0438.000; Tue, 28 Jan 2014 11:13:51 +0100 From: Nicolas BOUTHORS To: Guanxiaoran Thread-Topic: =?gb2312?B?W3NmY10gtPC4tDogTm90ZSBvbiBHSSBkZXBsb3ltZW50IHNjZW5hcmlvIGRy?= =?gb2312?Q?aft-liu-sfc-use-cases-00?= Thread-Index: AQHPG0E50IKowRRhXEC5c6zdZjgHZZqZvJyAgAAILtyAAB4kwIAABJHn Date: Tue, 28 Jan 2014 10:13:51 +0000 Message-ID: <76B41B8FACE1514795D30EC137FF391D3D09B3@LILAS.jungle.qosmos.com> References: <76B41B8FACE1514795D30EC137FF391D3D08E0@LILAS.jungle.qosmos.com>, <2C5AD5728DB9B24189E3A93140E45786367C79@szxeml522-mbx.china.huawei.com> <76B41B8FACE1514795D30EC137FF391D3D0967@LILAS.jungle.qosmos.com>, <2C5AD5728DB9B24189E3A93140E45786367D1F@szxeml522-mbx.china.huawei.com> In-Reply-To: <2C5AD5728DB9B24189E3A93140E45786367D1F@szxeml522-mbx.china.huawei.com> Accept-Language: en-US, fr-FR Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.13.0.22] Content-Type: multipart/related; boundary="_004_76B41B8FACE1514795D30EC137FF391D3D09B3LILASjungleqosmos_"; type="multipart/alternative" MIME-Version: 1.0 X-ACL-Warn: 1/1 recipients OK. Cc: "sfc@ietf.org" Subject: Re: [sfc] =?gb2312?b?tPC4tDogTm90ZSBvbiBHSSBkZXBsb3ltZW50IHNjZW5hcmlv?= =?gb2312?b?IGRyYWZ0LWxpdS1zZmMtdXNlLWNhc2VzLTAw?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 10:14:02 -0000 --_004_76B41B8FACE1514795D30EC137FF391D3D09B3LILASjungleqosmos_ Content-Type: multipart/alternative; boundary="_000_76B41B8FACE1514795D30EC137FF391D3D09B3LILASjungleqosmos_" --_000_76B41B8FACE1514795D30EC137FF391D3D09B3LILASjungleqosmos_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VGhlIGdvYWwgaGVyZSBpcyB0byBnZXQgYWxsIHRoZSBpbmZvcm1hdGlvbiBpbiB0aGUgUmFkaXVz IG1lc3NhZ2UsIGFzIHRoZSB0cmFmZmljIGdvZXMgdGhyb3VnaC4gSXQgaXMgaG93ZXZlciBub3Qg cGFydCBvZiB0aGUgc3RhbmRhcmRzLA0KYW5kIHJlbGllcyBvbiB0aGUgYWJpbGl0eSBvZiBSYWRp dXMgdG8gdHJhbnNwb3J0IGFkZGl0aW9uYWwgcGFyYW1ldGVycy4NCg0KSXQgaXMgaW50ZXJlc3Rp bmcgdG8gbm90ZSB0aGF0IHNmYyBpcyBub3QgdGhhdCBmYXIgZnJvbSB3aGF0IHRha2VzIHBsYWNl IGluIHRoZSBFUEMsIG9yIHRoZSBHbiBzaWRlIG9mIHRoZSBHR1NOLCB0cmFmZmljIGlzIGVuY2Fw c3VsYXRlZA0KYW5kIHR1bm5lbGVkIHRocm91Z2ggdG8gZ2V0IHRvIHRoZSBJbnRlcm5ldC4gUERQ IGVzdGFibGlzaG1lbnQgcHJvY2VkdXJlIGlzIHNpbWlsYXIgdG8gd2hhdCBhIENsYXNzaWZpZXIg aGFzIHRvIGRvIHdoZW4NCml0IGVzdGFibGlzaGVzIGEgc2VydmljZSBwYXRoLiBPbmUgaW1wb3J0 YW50IHN0ZXAgaXMgYSBpZGVudGlmeSB0aGUgc3Vic2NyaWJlciBhbmQgcmV0cmlldmUgdGhlIGds b2JhbCBwb2xpY3kgaWRlbnRpZmllcnMgdGhhdCBzaG91bGQgYXBwbHkNCmF0IHRoYXQgcG9pbnQg aW4gdGltZS4NCg0KVG8gZ2l2ZSBhbmQgZXhhbXBsZSwgSSBjYW4gc2F5ICB0aGF0IGNsb3Npbmcg YSBQRFAgY29udGV4dCBpbiBhIEdpIGVudmlyb25tZW50LCBzaG91bGQgYmUgZGV0ZWN0ZWQgdG8g cHJldmVudCByZXR1cm4gdHJhZmZpYw0Kc3VjaCBhcyB2aWRlbyBzdHJlYW1zIHRvIGJlIGNoYXJn ZWQgZm9yLCBvciBoYXZlIGxhZ2dpbmcgcGFyZW50YWwgY29udHJvbCBwb2xpY2llcyBlZmZlY3Qg ZHVlIHRvIHJhcGlkIElQIHJlYWxsb2NhdGlvbi4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KRnJvbTogR3VhbnhpYW9yYW4gW2d1YW54aWFvcmFuQGh1YXdlaS5jb21dDQpT ZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI4LCAyMDE0IDEwOjQ2IEFNDQpUbzogTmljb2xhcyBCT1VU SE9SUw0KQ2M6IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogW3NmY10gtPC4tDogTm90ZSBvbiBHSSBk ZXBsb3ltZW50IHNjZW5hcmlvIGRyYWZ0LWxpdS1zZmMtdXNlLWNhc2VzLTAwDQoNCkhpIE5pY29s YXMsDQoNClRoZSBSYWRpdXMgc2VydmVyIGNvdWxkIGFsc28gaW5jbHVkZSBleHRlbnNpb25zIHN1 Y2ggYXMgYW4gaW5kaWNhdGlvbiBvZiB3aGljaCBwb2xpY2llcyBzaG91bGQgYmUgYXBwbGllZCB0 byBhIHBhcnRpY3VsYXIgc3Vic2NyaWJlciB0cmFmZmljLg0KUmFuPiBEb2VzIHRoZSBSQURJVVMg c2VydmVyIHNlbmQgdGhlc2UgaW5mb3JtYXRpb24gdG8gdGhlIERQSSBvciBEUEkgY2FwdHVyZSB0 aGVtIHdoZW4gdGhlIHRyYWZmaWMgZ29lcyB0aHJvdWdoID8NCg0KVGhhbmtzLA0KUmFuDQoNCrei vP7Iyzogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gTmljb2xhcyBCT1VU SE9SUw0Kt6LLzcqxvOQ6IDIwMTTE6jHUwjI4yNUgMTY6MDINCsrVvP7IyzogR3VhbnhpYW9yYW4N CrOty806IHNmY0BpZXRmLm9yZw0K1vfM4jogUmU6IFtzZmNdIE5vdGUgb24gR0kgZGVwbG95bWVu dCBzY2VuYXJpbyBkcmFmdC1saXUtc2ZjLXVzZS1jYXNlcy0wMA0KDQpEUEkgZG9lcyBub3QgaGF2 ZSB0byBiZSBhIFJhZGl1cyBwcm94eS4gSXQgY2FuIG9ic2VydmUgdGhlIFJhZGl1cyB0cmFmZmlj IHZpYSBhIFRhcCBvciBnZXQgYSBjb3B5DQpvZiB0aGUgUmFkaXVzIHRyYWZmaWMgdXNpbmcgT3Bl bkZsb3cgdGFibGVzIGlmIHRoZSB0cmFmZmljIHJ1bnMgdGhyb3VnaCBhICh2aXJ0dWFsKSBzd2l0 Y2ggdGhhdCBpdCBjYW4gY29udHJvbC4NCg0KQWN0aW5nIGFzIGEgcHJveHkgaXMgbW9yZSBjb21w bGV4IGFzIGl0IGNhbiBoYXZlIGFuIGVmZmVjdCBvbiBwZXJmb3JtYW5jZSBhbmQgSEE6IHRoZSBy YWRpdXMgY2FsbHMgYXJlIG9uIHRoZSBjcml0aWNhbCBwYXRoIG9mIFBEUCBjb250ZXh0IGVzdGFi bGlzaG1lbnQuDQoNCkl0IGlzIHVzZWZ1bGwgb25seSBpZiB3ZSB3YW50IHRvIGluc3VyZSB0aGF0 IHRoZSBJUC9NU0lTRE4gY29ycmVsYXRpb24gaXMgcGVyZm9ybWVkIGJlZm9yZSBhbnkgZW5kIHVz ZXIgdHJhZmZpYyBpcyBhbGxvd2VkIHRvIGdvIHRocm91Z2guDQoNCldhdGNoaW5nIG92ZXIgdGhl IFJhZGl1cyB0cmFmZmljIGFsc28gYWxsb3dzIHRvIGNhcHR1cmUgb3RoZXIgcGFyYW1ldGVycyBz dWNoIGFzIHRoZSBBUE4uIFRoZSBSYWRpdXMgc2VydmVyIGNvdWxkIGFsc28gaW5jbHVkZSBleHRl bnNpb25zIHN1Y2ggYXMgYW4gaW5kaWNhdGlvbiBvZiB3aGljaCBwb2xpY2llcyBzaG91bGQgYmUg YXBwbGllZCB0byBhIHBhcnRpY3VsYXIgc3Vic2NyaWJlciB0cmFmZmljLg0KVGhpcyBsYXN0IHBv aW50IGNvbWJpbmVkIHRvIHRoZSBtZXRhZGF0YSBpdCBjb2xsZWN0cyBjb3VsZCBhbGxvdyB0aGUg RFAgdG8gc2VsZWN0IHRoZSBhcHByb3ByaWF0ZSBzZXJ2aWNlIGNoYWluIHRvIGFwcGx5IHRvIG91 dGdvaW5nIHBhY2tldHMNCg0KDQoNCk5pY29sYXMNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkZyb206IEd1YW54aWFvcmFuIFtndWFueGlhb3JhbkBodWF3ZWkuY29tXQ0KU2Vu dDogVHVlc2RheSwgSmFudWFyeSAyOCwgMjAxNCA4OjIzIEFNDQpUbzogTmljb2xhcyBCT1VUSE9S Uzsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiC08Li0OiBOb3Rl IG9uIEdJIGRlcGxveW1lbnQgc2NlbmFyaW8gZHJhZnQtbGl1LXNmYy11c2UtY2FzZXMtMDANCkhp IE5pY29sYXMsDQoNCkRvIHlvdSBtZWFuIHRoYXQgRFBJIG11c3Qgc3VwcG9ydCBSQURJVVMgcHJv eHkgaW4gdGhpcyBjYXNlPw0KDQpSYW4NCg0Kt6K8/sjLOiBzZmMgW21haWx0bzpzZmMtYm91bmNl c0BpZXRmLm9yZ10gtPqx7SBOaWNvbGFzIEJPVVRIT1JTDQq3osvNyrG85DogMjAxNMTqMdTCMjfI 1SAxNzoyMw0KytW8/sjLOiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCtb3zOI6 IFtzZmNdIE5vdGUgb24gR0kgZGVwbG95bWVudCBzY2VuYXJpbyBkcmFmdC1saXUtc2ZjLXVzZS1j YXNlcy0wMA0KDQpIZWxsbywNCg0KT24gR2kgZGVwbG95bWVudHMgdGhlIEdHU04gY29ubmVjdHMg dG8gYSBSYWRpdXMgRnVuY3Rpb24gYXQgUERQIENvbnRleHQgU2V0dXAgVGltZS4gSW4gbW9zdCBj YXNlDQp0aGlzIGlzIHVzZWQgdG8gcGVyZm9ybSBhbmQgTVNJU0ROIHRvIElQIGFkZHJlc3MgbWFw cGluZywgd2hpY2ggaXMgdGhlbiB1c2VkIGJ5IHRoZSBHaSBzZXJ2aWNlIGluZnJhc3RydWN0dXJl DQp0byBkZWNpZGUgaG93IHRvIGhhbmRsZSB0aGUgSVAgZmxvd3MgZm9yIHRoYXQgcGFydGljdWxh ciBzdWJzY3JpYmVyLg0KDQpUaGlzIGluZm9ybWF0aW9uIGNhbm5vdCBiZSBkZXJpdmVkIGJ5IHRo ZSBEUEkgbG9jYXRlZCBhZnRlciB0aGUgR0dTTi4gKEl0IGNvdWxkIGlmIHRoZSBEUEkgd2VyZSB0 byBiZSBsb2NhdGVkIG9uIHRoZSBvdGhlciBzaWRlIG9mIHRoZSBHR1NOLCB0aGUgR24gaW50ZXJm YWNlKS4NCg0KSXQgaXMgY2xlYXIgdGhhdCB3ZSBzaG91bGQgdXBkYXRlIHRoZSBkaWFncmFtIHRv IHNob3cgdGhlIFJhZGl1cyB0cmFmZmljIGdvIHRocm91Z2ggdGhlIERQSSBzbyB0aGF0IHRoZSBE UEkgY2FuIGV4dHJhY3QgdGhlIGluZm9ybWF0aW9uIGFuZCBhZGQgaXQgdG8gdGhlIG1ldGFkYXRh IHdoaWNoIHdpbGwgYmUgY29sbGVjdGVkIGxhdGVyIGFzIHRoZSBzdWJzY3JpYmVyIHRyYWZmaWMg Z29lcyB0aHJvdWdoLg0KDQpTb21ldGhpbmcgbGlrZToNCg0KQ2hhaW4gMDogR0dTTiBzZW5kIFJh ZGl1cyB0cmFmZmljIHRvIFJhZGl1cyBzZXJ2ZXIgdmlhIHRoZSBEUEkgc28gdGhhdCB0aGUgRFBJ IGNhbiBlc3RhYmxpc2ggdGhlIElQL01TSVNETiBjb3JyZWxhdGlvbg0KDQoNCltjaWQ6aW1hZ2Uw MDEuanBnQDAxQ0YxQzUwLjY2MUVBNzAwXQ0KDQoNCg0KTmljb2xhcw0KDQo= --_000_76B41B8FACE1514795D30EC137FF391D3D09B3LILASjungleqosmos_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
The goal here is to get all the information in the Radius message, a= s the traffic goes through. It is however not part of the standards,
and relies on the ability of Radius to transport additional parameters= .

It is interesting to note that sfc is not that far from what takes pla= ce in the EPC, or the Gn side of the GGSN, traffic is encapsulated 
and tunneled through to get to the Internet. PDP establishment procedu= re is similar to what a Classifier has to do when
it establishes a service path. One important step is a identify the su= bscriber and retrieve the global policy identifiers that should apply
at that point in time.

To give and example, I can say  that closing a PDP context in a G= i environment, should be detected to prevent return traffic
such as video streams to be charged for, or have lagging parental cont= rol policies effect due to rapid IP reallocation.


From: Guanxiaoran [guanxiaoran@huawei.com]=
Sent: Tuesday, January 28, 2014 10:46 AM
To: Nicolas BOUTHORS
Cc: sfc@ietf.org
Subject: [sfc] =B4=F0=B8=B4: Note on GI deployment scenario draft-li= u-sfc-use-cases-00

Hi Nicol= as,

 

The Radius= server could also include extensions such as an indication of which polici= es should be applied to a particular subscriber traffic. 

Ran> = Does the RADIUS server send these information to the DPI or DPI capture the= m when the traffic goes through ?

 

Thanks,<= /span>

Ran

 

=B7=A2=BC=FE=C8=CB: sfc [m= ailto:sfc-bounces@ietf.org] =B4=FA= =B1=ED Nicolas BOUTHORS
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C228=C8=D5 16:02
=CA=D5=BC=FE=C8=CB: Guanxiaoran
=B3=AD=CB=CD: sfc@ietf.org
=D6=F7=CC=E2: Re: [sfc] Note on GI deployment scenario draft-liu-sfc-use-cases-00

 

DPI does no= t have to be a Radius proxy. It can observe the Radius traffic via a Tap or= get a copy

of the Radi= us traffic using OpenFlow tables if the traffic runs through a (virtual) sw= itch that it can control.

 

Acting as a= proxy is more complex as it can have an effect on performance and HA: the = radius calls are on the critical path of PDP context establishment.<= /p>

 

It is usefu= ll only if we want to insure that the IP/MSISDN correlation is performed be= fore any end user traffic is allowed to go through.

 

Watching ov= er the Radius traffic also allows to capture other parameters such as the A= PN. The Radius server could also include extensions such as an indication of which policies should be applied to a particular subscrib= er traffic. 

This last p= oint combined to the metadata it collects could allow the DP to select the = appropriate service chain to apply to outgoing packets 

 

 

 

Nicolas

 

From: Guanxiaoran [guanxiaoran@huawei.com]
Sent: Tuesday, January 28, 2014 8:23 AM
To: Nicolas BOUTHORS; sfc@ietf.org
Subject: =B4=F0=B8=B4: Note on GI deployment scenario draft-liu-sfc-use-cases-00

Hi Nicol= as,

 

Do you m= ean that DPI must support RADIUS proxy in this case?

 

Ran

 

=B7=A2=BC=FE=C8=CB: sfc [mailto:sfc-bounces@ietf.org] =B4=FA=B1=ED Nicolas BOUTHORS
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C227=C8=D5 17:23
=CA=D5=BC=FE=C8=CB: sfc@ietf.org
=D6=F7=CC=E2: [sfc] Note on GI deployment scenario draft-liu-sfc-use-cases-00

 

Hello,

 

On Gi deplo= yments the GGSN connects to a Radius Function at PDP Context Setup Time. In= most case

this is use= d to perform and MSISDN to IP address mapping, which is then used by the Gi= service infrastructure

to decide h= ow to handle the IP flows for that particular subscriber.

 

This inform= ation cannot be derived by the DPI located after the GGSN. (It could if the= DPI were to be located on the other side of the GGSN, the Gn interface).

 

It is clear= that we should update the diagram to show the Radius traffic go through th= e DPI so that the DPI can extract the information and add it to the metadata which will be collected later as the subscriber traffic= goes through. 

 

Something l= ike:

 

Chain 0: GG= SN send Radius traffic to Radius server via the DPI so that the DPI can est= ablish the IP/MSISDN correlation

 

 

<= /span>

 

 

 

Nicolas

 

--_000_76B41B8FACE1514795D30EC137FF391D3D09B3LILASjungleqosmos_-- --_004_76B41B8FACE1514795D30EC137FF391D3D09B3LILASjungleqosmos_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=34434; creation-date="Tue, 28 Jan 2014 09:46:27 GMT"; modification-date="Tue, 28 Jan 2014 09:46:27 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/4RDSRXhpZgAATU0AKgAAAAgABAE7AAIAAAAEZGNoAIdpAAQA AAABAAAISpydAAEAAAAIAAAQwuocAAcAAAgMAAAAPgAAAAAc6gAAAAgAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFkAMAAgAAABQAABCY kAQAAgAAABQAABCskpEAAgAAAAM0OAAAkpIAAgAAAAM0OAAA6hwABwAACAwAAAiMAAAAABzqAAAA CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAMjAxNDowMToyNyAxMDoyMjowOQAyMDE0OjAxOjI3IDEwOjIyOjA5AAAAZABjAGgAAAD/4QsW aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49J++7vycgaWQ9J1c1 TTBNcENlaGlIenJlU3pOVGN6a2M5ZCc/Pg0KPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczpt ZXRhLyI+PHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJk Zi1zeW50YXgtbnMjIj48cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0idXVpZDpmYWY1YmRkNS1i YTNkLTExZGEtYWQzMS1kMzNkNzUxODJmMWIiIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcvZGMv ZWxlbWVudHMvMS4xLyIvPjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSJ1dWlkOmZhZjViZGQ1 LWJhM2QtMTFkYS1hZDMxLWQzM2Q3NTE4MmYxYiIgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUu Y29tL3hhcC8xLjAvIj48eG1wOkNyZWF0ZURhdGU+MjAxNC0wMS0yN1QxMDoyMjowOS40NzU8L3ht cDpDcmVhdGVEYXRlPjwvcmRmOkRlc2NyaXB0aW9uPjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0 PSJ1dWlkOmZhZjViZGQ1LWJhM2QtMTFkYS1hZDMxLWQzM2Q3NTE4MmYxYiIgeG1sbnM6ZGM9Imh0 dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIj48ZGM6Y3JlYXRvcj48cmRmOlNlcSB4bWxu czpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPjxyZGY6 bGk+ZGNoPC9yZGY6bGk+PC9yZGY6U2VxPg0KCQkJPC9kYzpjcmVhdG9yPjwvcmRmOkRlc2NyaXB0 aW9uPjwvcmRmOlJERj48L3g6eG1wbWV0YT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgPD94cGFja2V0IGVuZD0ndyc/Pv/bAEMABwUFBgUEBwYF BggHBwgKEQsKCQkKFQ8QDBEYFRoZGBUYFxseJyEbHSUdFxgiLiIlKCkrLCsaIC8zLyoyJyorKv/b AEMBBwgICgkKFAsLFCocGBwqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKv/AABEIARoCPAMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUG BwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR 8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5 eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj 5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQAC AQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXx FxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqS k5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T1 9vf4+fr/2gAMAwEAAhEDEQA/APn6iiiv0k5AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAop0aeZIqblXcQNzHAHua6TxN4Gv/AAtHYtqNzaBrxEZU E6MRnOT8jN8o+X5jjO7jODjmqYqhSqxozklKV7Lq7b29ASbTfY5mium8TeBr/wALR2Lajc2ga8RG VBOjEZzk/IzfKPl+Y4zu4zg4PE3ga/8AC0di2o3NoGvERlQToxGc5PyM3yj5fmOM7uM4OMKeZ4Kr yclRPnvy+dt7enUpwkr3WxzNFdN4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHB4m8DX /haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHBTzPBVeTkqJ89+Xztvb06g4SV7rY5mium8TeBr /wALR2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg4PE3ga/8AC0di2o3NoGvERlQToxGc5PyM3yj5 fmOM7uM4OCnmeCq8nJUT578vnbe3p1Bwkr3WxzNFdN4m8DX/AIWjsW1G5tA14iMqCdGIznJ+Rm+U fL8xxndxnBweJvA1/wCFo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcFPM8FV5OSonz35fO29vT qDhJXutjmaK6bxN4Gv8AwtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODg8TeBr/AMLR2Lajc2ga 8RGVBOjEZzk/IzfKPl+Y4zu4zg4KeZ4KryclRPnvy+dt7enUHCSvdbHM0V03ibwNf+Fo7FtRubQN eIjKgnRiM5yfkZvlHy/McZ3cZwcHibwNf+Fo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcFPM8F V5OSonz35fO29vTqDhJXutjmaK6bxN4Gv/C0di2o3NoGvERlQToxGc5PyM3yj5fmOM7uM4ODxN4G v/C0di2o3NoGvERlQToxGc5PyM3yj5fmOM7uM4OCnmeCq8nJUT578vnbe3p1Bwkr3WxzNFdN4m8D X/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHB4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vz HGd3GcHBTzPBVeTkqJ89+Xztvb06g4SV7rY5mium8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8o+X5 jjO7jODg8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODgp5ngqvJyVE+e/L523t6dQcJK 91sczRXTeJvA1/4WjsW1G5tA14iMqCdGIznJ+Rm+UfL8xxndxnBweJvA1/4WjsW1G5tA14iMqCdG IznJ+Rm+UfL8xxndxnBwU8zwVXk5KifPfl87b29OoOEle62OZorpvE3ga/8AC0di2o3NoGvERlQT oxGc5PyM3yj5fmOM7uM4ODxN4Gv/AAtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODgp5ngqvJyV E+e/L523t6dQcJK91sczRXTeJvA1/wCFo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcHibwNf8A haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHBTzPBVeTkqJ89+Xztvb06g4SV7rY5mium8TeBr/ AMLR2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg4PE3ga/wDC0di2o3NoGvERlQToxGc5PyM3yj5f mOM7uM4OCnmeCq8nJUT578vnbe3p1Bwkr3WxzNFdN4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8v zHGd3GcHB4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHBTzPBVeTkqJ89+Xztvb06g4S V7rY5mium8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODg8TeBr/wtHYtqNzaBrxEZUE6 MRnOT8jN8o+X5jjO7jODgp5ngqvJyVE+e/L523t6dQcJK91sczRXTeJvA1/4WjsW1G5tA14iMqCd GIznJ+Rm+UfL8xxndxnBweJvA1/4WjsW1G5tA14iMqCdGIznJ+Rm+UfL8xxndxnBwU8zwVXk5Kif Pfl87b29OoOEle62OZorpvE3ga/8LR2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg4b4p8EX/AISt 7OXUZ7YtdRq6xJOjtyCTgKzZUfL8xxncMZwcFLMsHWdNU6ifPfl87b29OockuxzdFFFegSFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAVPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelRRp5kipuVdxA3McAe5rovFPgi/8JW9n LqM9sWuo1dYknR25BJwFZsqPl+Y4zuGM4OOWpiMPCtClUkueV+VdXbe36jSbvYwri+u7wYu7qace Y0uJZC3ztjc3Pc7Rk98D0ouL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKK3VOCtZbCJ7i+u7wYu 7qaceY0uJZC3ztjc3Pc7Rk98D0ouL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKFTgrWWwE9xfX d4MXd1NOPMaXEshb52xubnudoye+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUFFCpwVrLYC e4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qFFDSKr MEBIBZs4X3OOa1fEOkWukXFqLC/a/t7m3E6TNB5WfnZeFJJxlMgnBwRkA8Vk5UYVI07au9tPv1tZ fqPV3KFxfXd4MXd1NOPMaXEshb52xubnudoye+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ74HpU FFaqnBWsthE9xfXd4MXd1NOPMaXEshb52xubnudoye+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ 74HpUFFCpwVrLYCe4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3P c7Rk98D0qCrd7p0thFZyTMjC8txcR7SeFLMuDx1yp/SptTi4xsk9bfrYNWR3F9d3gxd3U048xpcS yFvnbG5ue52jJ74HpRcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelQUVSpwVrLYCe4vru8GLu6mnH mNLiWQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qCihU4K1lsBPcX13eDF3 dTTjzGlxLIW+dsbm57naMnvgelFxfXd4MXd1NOPMaXEshb52xubnudoye+B6VBRQqcFay2AnuL67 vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSi4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KkvdOlsIrOSZ kYXluLiPaTwpZlweOuVP6VUqYKnJKUErLb9Q1J7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0ouL6 7vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKpU4K1lsBPcX13eDF3dTTjzGlxLIW+dsbm57naMnvge lFxfXd4MXd1NOPMaXEshb52xubnudoye+B6VBRQqcFay2AnuL67vBi7uppx5jS4lkLfO2Nzc9ztG T3wPSi4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KgooVOCtZbAT3F9d3gxd3U048xpcSyFvnbG5u e52jJ74HpRcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelQUUKnBWstgJ7i+u7wYu7qaceY0uJZC3z tjc3Pc7Rk98D0ouL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKFTgrWWwE9xfXd4MXd1NOPMaXE shb52xubnudoye+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUUaeZIqblXcQNzHAHua6LxT4 Iv8Awlb2cuoz2xa6jV1iSdHbkEnAVmyo+X5jjO4Yzg4551sNSqwoyaUpX5V1dt7fqNJu9jm6KKK6 xBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFT3F9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUUaeZIqblXcQNzHAHua6LxT4 Iv8Awlb2cuoz2xa6jV1iSdHbkEnAVmyo+X5jjO4Yzg45amIw8K0KVSS55X5V1dt7fqNJu9jm6KKK 6hBRVu906Wwis5JmRheW4uI9pPClmXB465U/pVSpjOM1zRegBRRRVAOjKCVDMrNGGG5VbaSO4Bwc H3wa29f1jSNUsrGLTtMvbSWziECvPfpMrRhnblREnzZfrnGB071hUVhOhCdSNSV7x21a/BOz+YJ2 CiiitwCiinwxrLcRxvKkKuwVpZASqAn7x2gnA68An2NJuyuAtvcTWlxHcWsskM0TB45Y2KsjDkEE cg+9b+reOtf1a3sIptX1LFpGmd97I3mSq7MsvXhhkAHkjaOaztY0C/0OSP7YiPBPuNvdwOJIbgA4 JRxw2MjI6jOCAeKtaX4b+2a7o1he3XkR6sqtHLDH5rJuZkUFSVydy+vQ59q82s8DUjHFVEpWTadr 6Le1r39ClzJtIiu/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIou/FniO/WJb7X9UuRDKs0Qmv ZH2SL91xk8MOxHIrTu/CVjYaK+o3t/fQIXt3t0exjJnt5txWQYmOG2xyHYfQDPORB4m8M2nh+8tR DqUt3ZysY5pDaiOSCRQpkjKbyCyh1/iAJJHbNc9Ktlk5xhTir629x9Em7O1tn8ynz2uynd+LPEd+ sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWn4h8J WGkrqy6dqtzeTaRdLb3Sz2QgUkllyjCR88r0IU457Gue03T5tV1S2sLXb51zKsSbzhQScZJ7CtqH 9n1aXtqcFyx/u2tpfZpNaO4pc8XZsvXfizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkUXPi7xJe iIXniDVbgQyiaLzb2RvLcdHGTwwycEc1raf4a8M6pqVtZWPie6aae6W2CvpO0vu4Dp+9IK5x94qe enaodR8J22neHp9SkvLtHzA9pDNaIouIZt5RyyyttOI5CVwcYHPPGEa+WKcafIlLSydNr4nbS8V1 3/Edp9/xK+u+NNa1/T7SzvtSv5YIYRHLHNePIszhmbzCDxnDAc5+71rAq3e6dLYRWckzIwvLcXEe 0nhSzLg8dcqf0qpXp4WlQo0lHDpKPkQ23a4UUUV0iCiiigAooooAKKKKACiird7p0thFZyTMjC8t xcR7SeFLMuDx1yp/Spc4pqLerAqVPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelRRp5kipuVdxA3 McAe5rovFPgi/wDCVvZy6jPbFrqNXWJJ0duQScBWbKj5fmOM7hjODjnqYjDwrQpVJLnlflXV23t+ o0m72ObooorqEFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAVPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelRRp5kipuVdxA 3McAe5rovFPgi/8ACVvZy6jPbFrqNXWJJ0duQScBWbKj5fmOM7hjODjlqYjDwrQpVJLnlflXV23t +o0m72ObqS3uJrS4juLWWSGaJg8csbFWRhyCCOQfeo6K6WlJWYjo9W8da/q1vYRTavqWLSNM772R vMlV2ZZevDDIAPJG0c1Tu/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIqHVtJ/suPT287zfttm t1jZt2bmYbepz93rx1rOrgw+EwXs4ulTjbW2n3lOUur6fga934s8R36xLfa/qlyIZVmiE17I+yRf uuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZFFbLB4ZWtTjptotBc0u5r3fizx HfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkUXfizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkVkUU LB4ZWtTjptotA5pdzXu/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIou/FniO/WJb7X9UuRDKs 0QmvZH2SL91xk8MOxHIrIooWDwytanHTbRaBzS7mvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4Yd iORRd+J9Z1ZYoNf1jVNSsllWR7ea9ds49N24BsEgHBxnoelZFFCweGjblppW2skrenb5BzS7m9ee KrkRxWnh9ZNFsIXEiQ207b5JAQRLLJwXcYGDgKuPlVcnNyf4ha5d3WjyXl/f3MWnNE7wT3rutw8c pcOwPfkDPJ4rlat3unS2EVnJMyMLy3FxHtJ4Usy4PHXKn9K55ZfgrxjKCvra++u+u7fne4cz1t2/ A62f4iQagsMOq6N59rBqgvY4YrkR4iVSI7fJQ/Ku4845BPTORBqnji11zS7yz1bS5ZfOvhdxSwSW 1u6cENvMduPMZgTljjnbxwc8dRWUclwEJKUadmttXprfTXS/W260ehXtJdzpvGfjKfxZqDTCTU4r ZpGl+x3eom5iick/6sbFCAA4AwfrWHpeoS6Tq1rqFuFaW2lWVVccMQc4Psaq0V20cHQoUFhqcbQt a3l+ZMpOTuztIfHkOm6fBY6Ja6pDaR3sN19lu9V8+FRHIZNqII025bBJOenrzUOs/EC71XTfssNu bKSLUvtlrPDNhreNVIjiXAH3NxIYY6niuRorkjk+BjP2ip63vdtvXzu9fmV7ST/r+u50ereOtf1a 3sIptX1LFpGmd97I3mSq7MsvXhhkAHkjaOap3fizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkVT vdOlsIrOSZkYXluLiPaTwpZlweOuVP6VUrajgsFGC9lTjZXtovmLml36fga934s8R36xLfa/qlyI ZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZFFarB4ZWtTjpto tBc0u5r3fizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkUXfizxHfrEt9r+qXIhlWaITXsj7JF+6 4yeGHYjkVkUULB4ZWtTjptotA5pdzXu/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIou/FniO/ WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIrIooWDwytanHTbRaBzS7mvd+LPEd+sS32v6pciGVZohNe yPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWRRQsHhla1OOm2i0Dml3Ne 58XeJL0RC88QarcCGUTRebeyN5bjo4yeGGTgjmrGu+NNa1/T7SzvtSv5YIYRHLHNePIszhmbzCDx nDAc5+71rArR1bSf7Lj09vO837bZrdY2bdm5mG3qc/d68daxeFwUKsP3cVJX5dPvGpS116fgZ1T3 F9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUUaeZIqblXcQNzHAHua6LxT4Iv/AAlb2cuoz2xa6jV1 iSdHbkEnAVmyo+X5jjO4Yzg42qYjDwrQpVJLnlflXV23t+okm72ObooorqEFFFFABRRWpe6ZDYeH 7C4naT7dfM0qRZG1LcHarEYzlmD456KDzuGM51IwlGL3k7L7r/oCVzLp8M0ttcRz28jxTRMHjkjY qyMDkEEdCD3rRvdMhsPD9hcTtJ9uvmaVIsjaluDtViMZyzB8c9FB53DGXShUhWi2tVqvu0YNWNe7 8WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecii78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Eci siislg8MrWpx020Wg+aXc17vxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKLvxZ4jv1iW+1/VL kQyrNEJr2R9ki/dcZPDDsRyKyKKFg8MrWpx020Wgc0u5r3fizxHfrEt9r+qXIhlWaITXsj7JF+64 yeGHYjkVHqPibXtYthbatreo30AYOIrm7kkUMMgHDEjPJ596zKKccJhoNONOKttotPQOaXcKKltj ALuE3iyNbiRfNWIgOUz8wUkEA4zjIrQ1TTING8TNaXTST2KSq6yQsA01u2GV1JGAWQgjI4zyKuVa MZ8nW1/W2/6feK2lzKorQ13S/wCx9auLNZPNhUh4Jh0liYBo3H+8pU/jWfV06kakFOOz1Q2rOwUU UVYgooooAKKKKACiird7p0thFZyTMjC8txcR7SeFLMuDx1yp/Spc4pqLerAqUUUVQBRRRQAUVbvd OlsIrOSZkYXluLiPaTwpZlweOuVP6VUqYzjNc0XoAUUUVQBRRVu906Wwis5JmRheW4uI9pPClmXB 465U/pUucU1FvVgVKnuL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKbim02tgCiird7p0thFZyT MjC8txcR7SeFLMuDx1yp/Sk5xTUW9WBe8Q39tfQ6MtrJ5httNjgl+Uja4dyRz14I5HFY1aOraT/Z cent53m/bbNbrGzbs3Mw29Tn7vXjrWdWGFVNUYqk7xG76ei/IKKt3unS2EVnJMyMLy3FxHtJ4Usy 4PHXKn9KqVvGcZrmi9BBRRRVAFFFFABRRRQBJb3E1pcR3FrLJDNEweOWNirIw5BBHIPvW/q3jrX9 Wt7CKbV9SxaRpnfeyN5kquzLL14YZAB5I2jmucormq4WhWnGpUgm47NrYabWxr3fizxHfrEt9r+q XIhlWaITXsj7JF+64yeGHYjkUXfizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkVTvdOlsIrOSZk YXluLiPaTwpZlweOuVP6VUqKeFwjSlCnGy20XzHzS7mvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ 4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWRVu906Wwis5JmRheW4uI9pPClmXB46 5U/pR9VwkHGPs4p620XzsHNJ9S5d+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRc+LvEl6Ihe eINVuBDKJovNvZG8tx0cZPDDJwRzWRRVLBYVWtTjptohc0u5v67401rX9PtLO+1K/lghhEcsc148 izOGZvMIPGcMBzn7vWsCiiroYelh4ezoxUV2QNt7hRRVu906Wwis5JmRheW4uI9pPClmXB465U/p WrnFNRb1YipRRRVAFFFFABRRRQAVs+Ib+2vodGW1k8w22mxwS/KRtcO5I568Ecjis2xsptRvobO1 8vzpm2IJJVjUn3ZiAPxNaV74U1bT7G8u7pLVYbG4FtPsvoHZZT/CFVyWPXoD91v7pxx1qmHVeHtJ pSWyutb6bb+nmNX1t/XX9DGqe4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KijTzJFTcq7iBuY4A9 zXReKfBF/wCErezl1Ge2LXUausSTo7cgk4Cs2VHy/McZ3DGcHFVMRh4VoUqklzyvyrq7b2/UEm72 ObooorqEFFFFAEtsIDdwi8aRbcyL5rRKC4TPzFQSATjOMmtDVNTg1nxM13dLJBYvKqLHCoLQ264V UUE4JVAAMnnHJqPVtJ/suPT287zfttmt1jZt2bmYbepz93rx1rOrmjGnXtWi+jSf5/kvuHqlbuaG u6p/bGtXF4sflQsQkEI6RRKAsaD/AHVCj8Kz6KK2pwjTgoR2WiBu7uFFFFWIKKKKACiiigArUvdT hv8Aw/YW86yfbrFmiSTA2vbk7lUnOcqxfHHRgONozl0VnOnGcoye8Xdfdb9QTsal7qcN/wCH7C3n WT7dYs0SSYG17cncqk5zlWL446MBxtGcuitHVtJ/suPT287zfttmt1jZt2bmYbepz93rx1rOHs6D VJdbtfm/zHqzOoooroEFFFFABRRRQBJb3E1pcR3FrLJDNEweOWNirIw5BBHIPvW/q3jrX9Wt7CKb V9SxaRpnfeyN5kquzLL14YZAB5I2jmucrak8NTHUNFsrWZZZtWgjlTeNixl3ZcE5PA25z+lcOJp4 R1I1K8VzK9m1sktRxbV7DLvxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKLvxZ4jv1iW+1/VLk QyrNEJr2R9ki/dcZPDDsRyKujw9ot/JFa6Br8t3fy3KW8cFzYGBZNxx5iuHYbR/tbT7dcQ3ek+Hv s5OleIpJ7gTrEIrqwMCuCceYHDsNo/2tp6cdcckZ5fdJUrNf9O5K1/8At3RPu7J69mU+bq/xILvx Z4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKLnxd4kvRELzxBqtwIZRNF5t7I3luOjjJ4YZOCOa3 9T8B2Wl6hZWl3qOqW8t1fC1UXOjGISL0M0TGTbIgYoOoOGBxVLWPCNto2k6jcTajNJcWl3FbxRpa r5U6SBnSQSeZkAojEjaSDgepGNHFZTUcFTitdvcfV2093a+je3cbU9blXXfGmta/p9pZ32pX8sEM IjljmvHkWZwzN5hB4zhgOc/d61gVbvdOlsIrOSZkYXluLiPaTwpZlweOuVP6VUr1sLSoUaSjh0lH yIbbtcKKKfDGstxHG8qQq7BWlkBKoCfvHaCcDrwCfY10N2VxC29xNaXEdxayyQzRMHjljYqyMOQQ RyD71v6t461/Vrewim1fUsWkaZ33sjeZKrsyy9eGGQAeSNo5rO1jQL/Q5I/tiI8E+4293A4khuAD glHHDYyMjqM4IB4qa50SKzu9HjuLp/K1G3jnd0hBaIM7KQFLDcRtz1GfavOqfUazhWmlJ2dna+29 v6/Ed3G/p+Al34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+ yRfuuMnhh2I5FaWseFNNsZNRFhq9zdjSLryNQWWxWJ0TzPL8yMCVg43cYJU/MvqSH674S03S31NL PV7u5bSbtba882wWIYLMu6MiVtxyp4O3I+hxywr5W3FRgvL3GrXt/d0vzLe17o0caivf8zKufF3i S9EQvPEGq3AhlE0Xm3sjeW46OMnhhk4I5qxrvjTWtf0+0s77Ur+WCGERyxzXjyLM4Zm8wg8ZwwHO fu9aPEeiaVo9rYPp+p3l5LewLcqk9ikKrGSw5Ilf5sr0xjB69qo6tpP9lx6e3neb9ts1usbNuzcz Db1Ofu9eOtbUYZfVdOpTgr68vu29dGlYm809+n4FjxDf219Doy2snmG202OCX5SNrh3JHPXgjkcV lW9xNaXEdxayyQzRMHjljYqyMOQQRyD71an0t7V9P+0zwxR30SzLIdxWNC7JlsAnjaTwDx0yeKk1 jQL/AEOSP7YiPBPuNvdwOJIbgA4JRxw2MjI6jOCAeK6aMsPCEaCle97X69/XzJ1av5I0dW8da/q1 vYRTavqWLSNM772RvMlV2ZZevDDIAPJG0c1Tu/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIps Ph29uNQ0qzhMTS6oivB8xwoZ2T5jjjBUk9eK0l8J22qgr4U1T+05o5lhljuYVtM7jhHRnkIZS3y/ NsbLL8vPHF/wl4ZKPLFJa35dFd9Xa0bu61auVeTW/T8DPu/FniO/WJb7X9UuRDKs0QmvZH2SL91x k8MOxHIou/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIqW+8Ha1ppUXsNvHmcW7kXsDCCQ5wsu HPlHg/f2/dPoaZrnha/8P3ptr2fT5HExhzb6hDL8w7lQ25B7sBWlOWVylGNPkb1tbl+dv1G/aK97 jbvxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKLvxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDs RyKsXHhDUE1yw0i1Ec15fQLJEpuYNjkkjCSLIyMPlwOQSeMdMt1LwXrmk232i/toY4t6puW8hfqS A3yufl3AqW+6GBUnIIpRnlV4Ri6d3rFe7ez7Lz/EXv67kN34s8R36xLfa/qlyIZVmiE17I+yRfuu Mnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FJq3h650rULOybEk11Cki7ZInRixIG 143ZWXI65H0FT6j4L1zS7eGa5t7d0nufskf2a9huGabum2N2ORxnjjI9RVReWLktyK/w/Cr97f8A AD39SG78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecii58XeJL0RC88QarcCGUTRebeyN5bjo4y eGGTgjmlv/C2q6asT3SWpjlm+z+bDewzRxyf3XdHKxnqfmI4BPY4fq3g/W9DtTcanaxxRgK3y3UT sUb7sgVWJKHoHA2k8ZzRF5W3BR9nrfl+HXvb9bB7/mSa7401rX9PtLO+1K/lghhEcsc148izOGZv MIPGcMBzn7vWsCrd7p0thFZyTMjC8txcR7SeFLMuDx1yp/Sq8May3EcbypCrsFaWQEqgJ+8doJwO vAJ9jXXh6dChStQilHXZfeS23a4tvcTWlxHcWsskM0TB45Y2KsjDkEEcg+9b+reOtf1a3sIptX1L FpGmd97I3mSq7MsvXhhkAHkjaOaztY0C/wBDkj+2IjwT7jb3cDiSG4AOCUccNjIyOozggHirEvhq b7fo1nazLLNq0Ecqbl2CMu7LgnJ4G3Of0rnqPA1nCvPllo7PfRb6jXMm0uwy78WeI79Ylvtf1S5E MqzRCa9kfZIv3XGTww7Ecii78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecipr3SdBFpIdJ8QTX l2kgjW3l08w+dkgbkbew29T8209Pl5OK+oeGdU01YWmhhmSeUwxvZ3MVypk4+TMTMA3I+U81FP8A s98qUIxetk48r87KST9bDfP3HXfizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkUXfizxHfrEt9r +qXIhlWaITXsj7JF+64yeGHYjkVfXwLqlvJFJqqpBZfaktbia2nhuXt5GOArRrJkN1+VsHg+lQa3 4M1fRLzyJoFmD3RtY/JljkcyfwqyIxMbEchWwevoazp1cplNQpuF9bW5fnZ7eqWvV7h79m3f+v6Z XufF3iS9EQvPEGq3AhlE0Xm3sjeW46OMnhhk4I5qxrvjTWtf0+0s77Ur+WCGERyxzXjyLM4Zm8wg 8ZwwHOfu9aq6r4a1PRrdbi9jgaEyGIy213FcKj4zsYxswVsZIDYJwcdDVW906Wwis5JmRheW4uI9 pPClmXB465U/pW1Ojl83CpSjF2vytW+drCvNN37fgVKKKK9MkKKKKACiiigArc8QeJ5det7SJ4Fg 8vMtwytk3NwwAeZvchV49cnvWHVu906Wwis5JmRheW4uI9pPClmXB465U/pXPUp0ZVYTmveV7fdq NN7IqVPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelQUVu4ptNrYQUUUUwCinwxrLcRxvKkKuwVpZ ASqAn7x2gnA68An2NX9Y0C/0OSP7YiPBPuNvdwOJIbgA4JRxw2MjI6jOCAeKylWpxmqbdm9l39O4 WZP4hv7a+h0ZbWTzDbabHBL8pG1w7kjnrwRyOKxqt3unS2EVnJMyMLy3FxHtJ4Usy4PHXKn9KqVO HhCFJRpu6B9PRfkFFOjCGVBMzLGWG5lXcQO5AyMn2yK6TVfDFhBJpdvoup3N7d6nGksSXdrFaoqM WAy5mYBsr0OBz17VNXFUqM1Co7Xv0dtN7u1l82hpNnM0Vt6j4P1nSZIkv4baIyT/AGYkXsDCKX+5 IQ5ER/39vQ+ho1nwlqWiaiLKdrK5nac26JZXsU7M+cY2Ixdcn+8BURx2Fm4qNSLvdrVa23t6DcZL dGJRWxf+FtV01YnuktTHLN9n82G9hmjjk/uu6OVjPU/MRwCexxaufAfiGzkiS6tbeJpmQRhr6D5g /wBx/v8A+rJ4D/dJ4znik8wwaSbqx1vb3lrbe2vTqLll2Odorb1LwhrekyRpeWiGSSf7MI7e4inZ Zv8AnmyxsxR/9lsHg+hpt74U1bT/ACTcJaGOWb7OJor+CWOOT+67q5WM9T85HAJ7HFRx2Fkk41Yu +2q1tvbXoDjJboxqK2Nf8MX3hu6eC/msJWSVoj9lvopjkeqqxZf+BAVj1tRrU68FUpSUovqgaadm FbPiG/tr6HRltZPMNtpscEvykbXDuSOevBHI4rGrR1bSf7Lj09vO837bZrdY2bdm5mG3qc/d68da zqKm60HJ+9rb9QV9bdv1RnUUUV0iCiiigAooooAK6S+1+ODUPDl9prrLNpllCrq6kASJI7FT0yME dPWubq3e6dLYRWckzIwvLcXEe0nhSzLg8dcqf0rlrUqVScfaeat3utfwBdbdv1R1Efj5dM0yOx8P 2+pW9ul1HcC3vdU+0QKEcvtWMRptBY5Jyc49eajfxnYxaKuj2dhqn9lPdRTT2N3q5liMauXaNAsa bNxPLcnv15rkKK5P7HwV78mt7/FLfvvq10e66F+0kdXD4p0iwWCDTNHvorNdQivpoZtSWQs0YYIq HyRs++ckhiQB6U3UPGsk+kPYWFvNabNRS9tLk3O6a3CiT93uVVyA8rMCACCT1zxy1FWsrwnNzuN3 5uT++7d/n002Fzv+v68zo9W8da/q1vYRTavqWLSNM772RvMlV2ZZevDDIAPJG0c1Tu/FniO/WJb7 X9UuRDKs0QmvZH2SL91xk8MOxHIqne6dLYRWckzIwvLcXEe0nhSzLg8dcqf0qpV0cFgowXsqcbK9 tF8w5pd+n4Gvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+J9Z1ZYoNf1jVNSsllWR7ea9 ds49N24BsEgHBxnoelZFPhjWW4jjeVIVdgrSyAlUBP3jtBOB14BPsa0+qYaCTVNK21lqvS2v3C5p dzX1TxE91ZDTNJt/7L0kcm0jlZjO39+ZuPMbgdgo/hVcnM2qarYzXPh+Rd9zHZWMUdxGhMbblkdi oYqQDgjnBHPeqOsaBf6HJH9sRHgn3G3u4HEkNwAcEo44bGRkdRnBAPFQXunS2EVnJMyMLy3FxHtJ 4Usy4PHXKn9K56dHCTjB03o72s977tvdvzvcHfVPt+Ghvav4q0y+k1NrHSbu1OsXQmvzLfrKWTzD IY48RLsBYg5O77q++U8X+MpPFeqCaRtVWyaYzNY3Op+ekZJPEXyAIMHA4OP0rl6KqnlmEpzjUjHW N7NtvdJPd9klfdW0KdSTvfqb/iPW9K1i1sE0/TLyzlsoFt1ee+SZWjBY8gRJ82W65xgdO9N1rV0k fQptLupEnsdPijaSPcjRSq7ng8cjIORWFVu906Wwis5JmRheW4uI9pPClmXB465U/pVRwmHpckF0 vZNt3vvvd/iLmbfy/DT/AIBsat411XXbewtNXv8AUrmzgjRLiF752+0EOzF/mBAbDYBIbGB16VFe eKrkRxWnh9ZNFsIXEiQ207b5JAQRLLJwXcYGDgKuPlVcnNLVtJ/suPT287zfttmt1jZt2bmYbepz 93rx1rOqKGDwTpxdKC5Vey6ettr+drg5S69jqrn4i+IrmXS5H1O+k+wKhaO4u3ljnkV2beyk4PDB ec8DrVjR/EWi2+s2Uen2X9i2st9FcX1xc3DXOI43DiNAse5VyOhDsSFy2Ac8xe6dLYRWckzIwvLc XEe0nhSzLg8dcqf0qpWf9l4KpS5aceVNNe7p36bNp6q6dmDk2tex1fibWdGEmqWnh6CQi/uFlmuz dtLG6gl9savDG6jcwzu3H5cZPU1Na13SNXujdf2JNDc3NwJ72U324t/eWIbAIwSSfmEhHy4PBzz9 FbUsvoU1G17rrzSu7pJ3112XkraWHKo5O52a+MNCi1jRNQg0HURJo4jWNX1VCJFQswBxbjncwyfQ YxzkQS+LdLn0lNOl0e88lbZbXK6goYok7Sqc+TjOHKnjng4HSuTorJZRg007PS1vel0ba+13bFzv 9P6+46PXdd0TVYdPW20i/t2sokt8y6ikgeJSxIwIVwx3fezgelXNW8Z2E95YXuiaRcafc6dPFJaL LfCaG3jjJPloixpwzEMzMWYkdckk8hRVrK8LaKs7Rva8pPffd638w5mdZr/jGLXoI4bhvEUkIuFl kgu9dNxFtGchFaLKtg4DEtjuDVPXdfsb/UodR0Wzv9MvYvLAlbUFkx5aKqldsSFW+UHOTz6Vz9FV Ry3C0eX2cWrXW8ra73V7O9utwc5Pc6PVvHWv6tb2EU2r6li0jTO+9kbzJVdmWXrwwyADyRtHNU7v xPrOrLFBr+sapqVksqyPbzXrtnHpu3ANgkA4OM9D0qne6dLYRWckzIwvLcXEe0nhSzLg8dcqf0qp To4PBxgvZQSSvay272e6Dml36fgbWqeInurIaZpNv/Zekjk2kcrMZ2/vzNx5jcDsFH8Krk5s3+vp BfeHb7SpFkn02yhVg6HaJFkdtpBxkYI6cc1zlW73TpbCKzkmZGF5bi4j2k8KWZcHjrlT+lH1PDRc YW76d7rW99W/Nu4ru79P1Rrf214ftbqG50zw24kS5jnZb6+M8YVWyY1UInynod+/gfUnX1X4i/br OzWODVJbuyv0voLnU9V+1bXX+Hb5agLwOFx368AcPRWc8pwlScZzi247Nyk/zf4MfPJbHRDWfDkF 3FPZeHrqMrcJM/manvKKpzsjxEAoJxy4c4AxzkmyfGFrb+fNpum3MF42rJqcEsl4rrGyEkKVEalh 8zc5Hb0OefvdOlsIrOSZkYXluLiPaTwpZlweOuVP6VUoWX4SquZ3kvOUn+bDmf8AXp/kzrde8cTa rDH9lu/EUM0dws8f2vXWuYomGcFFMasCM8NuJAz1zmqOu+NNa1/T7SzvtSv5YIYRHLHNePIszhmb zCDxnDAc5+71rAq3e6dLYRWckzIwvLcXEe0nhSzLg8dcqf0op5fgaDgowV1flvq/PV3Y+eTe/T8C pRRRXpkBRRRQAUUUUASW9xNaXEdxayyQzRMHjljYqyMOQQRyD71v6t461/Vrewim1fUsWkaZ33sj eZKrsyy9eGGQAeSNo5rno4zLKkalQzsFBZgo59SeAPc1ra1o1lp1vHJp+sW+o7X8m4VAEMcoGTsB JMkZ5AkAHIOQMru4a9PCzrw9rFOettL2+drLyvv0HG6vYS78WeI79Ylvtf1S5EMqzRCa9kfZIv3X GTww7Ecii78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7EcisqNPMkVNyruIG5jgD3NdF4p8EX/hK 3s5dRnti11GrrEk6O3IJOArNlR8vzHGdwxnBxnKGX0asKMoxUpX5VZX87afeNOcr2KV34s8R36xL fa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZFFdCweG VrU46baLQXNLua934n1nVlig1/WNU1KyWVZHt5r12zj03bgGwSAcHGeh6VPeeKrkRxWnh9ZNFsIX EiQ207b5JAQRLLJwXcYGDgKuPlVcnODRU/UcNp7istl09bbX87XDmZv67401rX9PtLO+1K/lghhE csc148izOGZvMIPGcMBzn7vWsCtHVtJ/suPT287zfttmt1jZt2bmYbepz93rx1rOqsJTw9Oilhkl HyVgbbtcdGUEqGZWaMMNyq20kdwDg4Pvg109/wCJdEurvR5oNG1CL+zFji2vqSP5saMzAcQDDZbr yMDp3rlqKK2EpV5KVS91dbtb6PZoV7X8zotT8Q6de6XqVrBpl1DLeagL1ZHvVdY+GG0qIhu++3OR 2445kv8AxXaSavDrOl6S1rqwvEvZbiW7Mq+YpzhECrtUtkkMXPQAjnPM0Vl/Z+G7Pr9qXW1766rR aPQpzb3/AK/q51mv+MYtegjhuG8RSQi4WWSC7103EW0ZyEVosq2DgMS2O4NQ6j4h0W816z1ODSL+ FoXi82N9RRxIsaqqhSIRtPyjJO7vxXM0VFPK8JTiowi0kmviltLfr/XQJTctzqz4wtbfz5tN025g vG1ZNTglkvFdY2QkhSojUsPmbnI7ehy3xL4w/wCEgsPs/m6+f3wl8q/1s3cC8HhUMYIIzwSxIGeu c1y1FEcrwkasaqj7y2d2/wA2P2kv6/rzN3xBrmm6y8tzbaO9tf3U3nXNxJdmUbsciNAqhVJJJDbz 0wRznCoorsoUIUKap072Xdt/m2yW29wrZ8Q39tfQ6MtrJ5httNjgl+Uja4dyRz14I5HFY1aOraT/ AGXHp7ed5v22zW6xs27NzMNvU5+71461FRU3Wg5P3tbfqCvrbt+qM6iiiukQUUUUAFFFFAElvcTW lxHcWsskM0TB45Y2KsjDkEEcg+9b+reOtf1a3sIptX1LFpGmd97I3mSq7MsvXhhkAHkjaOa5yiua rhaFacalSCbjs2thptbGvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pci GVZohNeyPskX7rjJ4YdiORWRRSWDwytanHTbRaBzS7mvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ 4YdiORRc+LvEl6IheeINVuBDKJovNvZG8tx0cZPDDJwRzWRRQsFhVa1OOm2iDml3Oj1bx1r+rW9h FNq+pYtI0zvvZG8yVXZll68MMgA8kbRzVO78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecisiio p4DCU0lCnFW20XUfNLua934s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34n1nVlig1/WNU1K yWVZHt5r12zj03bgGwSAcHGeh6VkUVaweGjblppW2skrenb5C5pdzevPFVyI4rTw+smi2ELiRIba dt8kgIIllk4LuMDBwFXHyquTmXVvHWv6tb2EU2r6li0jTO+9kbzJVdmWXrwwyADyRtHNc5Wpe6ZD YeH7C4naT7dfM0qRZG1LcHarEYzlmD456KDzuGOeWDwVOcL005Xdr6u9rttvV+bf5jTlrYfd+LPE d+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWVGn mSKm5V3EDcxwB7mui8U+CL/wlb2cuoz2xa6jV1iSdHbkEnAVmyo+X5jjO4Yzg4JQy+jVhRlGKlK/ KrK/nbT7wTnK9ilc+LvEl6IheeINVuBDKJovNvZG8tx0cZPDDJwRzVjXfGmta/p9pZ32pX8sEMIj ljmvHkWZwzN5hB4zhgOc/d61gUVssDhVKM1TinHbRaBzS7mz4hv7a+h0ZbWTzDbabHBL8pG1w7kj nrwRyOKyre4mtLiO4tZZIZomDxyxsVZGHIII5B96u6tpP9lx6e3neb9ts1usbNuzczDb1Ofu9eOt Z1Vho0vYKMNY+YnfT0X5HR6t461/Vrewim1fUsWkaZ33sjeZKrsyy9eGGQAeSNo5qnd+LPEd+sS3 2v6pciGVZohNeyPskX7rjJ4YdiORWRRUU8BhKaShTirbaLqPml3Ne78WeI79Ylvtf1S5EMqzRCa9 kfZIv3XGTww7Ecii78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7EcisiirWDwytanHTbRaC5pdzX u/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIou/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxH IrIooWDwytanHTbRaBzS7mvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6p ciGVZohNeyPskX7rjJ4YdiORWRRQsHhla1OOm2i0Dml3Ne78WeI79Ylvtf1S5EMqzRCa9kfZIv3X GTww7Ecii58XeJL0RC88QarcCGUTRebeyN5bjo4yeGGTgjmsiihYLCq1qcdNtEHNLub+u+NNa1/T 7SzvtSv5YIYRHLHNePIszhmbzCDxnDAc5+71rAooq6GHpYeHs6MVFdkDbe5Jb3E1pcR3FrLJDNEw eOWNirIw5BBHIPvW/q3jrX9Wt7CKbV9SxaRpnfeyN5kquzLL14YZAB5I2jmucoqauFoVpxqVIJuO za2BNrY17vxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKLnxd4kvRELzxBqtwIZRNF5t7I3luO jjJ4YZOCOayKKSwWFVrU46baIOaXc6PVvHWv6tb2EU2r6li0jTO+9kbzJVdmWXrwwyADyRtHNU7v xZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZPDDsRyKj1LRxpx0zddKVv7VLkuyECLczLg4ySBtzkD8Ks6 voum2ulRaho+rSX0LXL2zCe18hiyqrbkG5tyYYcnBGRlRkVxUqeXw9nGnTWt+X3dPPW2nzauVeT6 9PwIrnxd4kvRELzxBqtwIZRNF5t7I3luOjjJ4YZOCOasa7401rX9PtLO+1K/lghhEcsc148izOGZ vMIPGcMBzn7vWsCiutYHCqUZqnFOO2i0FzS7hRRRXYSFFFFABRRRQAUUVo6tpP8AZcent53m/bbN brGzbs3Mw29Tn7vXjrUSqRjJQb1e3yDczqnuL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoo08yRU 3Ku4gbmOAPc10XinwRf+Erezl1Ge2LXUausSTo7cgk4Cs2VHy/McZ3DGcHGFTEYeFaFKpJc8r8q6 u29v1Gk3exzdFFFdQgooooA2fEN/bX0OjLayeYbbTY4JflI2uHckc9eCORxWNUtsYBdwm8WRrcSL 5qxEBymfmCkggHGcZFaGqaZBo3iZrS6aSexSVXWSFgGmt2wyupIwCyEEZHGeRXJT5MOlQjd2Ta89 dfzX3j1av2sZVFaGu6X/AGPrVxZrJ5sKkPBMOksTANG4/wB5Sp/Gs+uinUjUgpx2eqBqzsFFFFWI KKKKACiiigAoorUvdMhsPD9hcTtJ9uvmaVIsjaluDtViMZyzB8c9FB53DGc6kYSjF7ydl91/0BK5 l1s+Ib+2vodGW1k8w22mxwS/KRtcO5I568Ecjior3TIbDw/YXE7Sfbr5mlSLI2pbg7VYjGcswfHP RQedwxl1jFU68o1l9m6/R/kPVfMKKKK6hBRRRQAUUUUAFFFFABRRRQAUUUUAFFS2ltJe3kNrAAZZ 5FjQE4yxOB/OtnWdAsrHT5brS9Skvltbv7HdeZa+SFkIYqU+ZtynY/JCngZUZrnniKVOpGnJ6vyf 4vZX6XtfoCTZg0UUV0AS2wgN3CLxpFtzIvmtEoLhM/MVBIBOM4yat67qn9sa1cXix+VCxCQQjpFE oCxoP91Qo/CpL3TIbDw/YXE7Sfbr5mlSLI2pbg7VYjGcswfHPRQedwxl1zU/Z1Z+2j0uvx1+9r8B 6pWCp7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qKNPMkVNyruIG5jgD3NdF4p8EX/hK3s5dRnti 11GrrEk6O3IJOArNlR8vzHGdwxnBwqmIw8K0KVSS55X5V1dt7fqCTd7HN0UUV1CNnxDf219Doy2s nmG202OCX5SNrh3JHPXgjkcVjVo6tpP9lx6e3neb9ts1usbNuzczDb1Ofu9eOtZ1c2FVNUYqk7xG 76ei/IKKKK6RBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRU9jZTajfQ2dr5fnTNsQSSrGpPuzEA fiamUowi5SdkgNnVdT065uNAZka8gs7GKK6hVjEWKyOWTcRxkEcgHrS+KvEVhr7QGwsLuwSDKxW7 3iSQQxnnZGixJt56kkk9SSear3vhTVtPsby7uktVhsbgW0+y+gdllP8ACFVyWPXoD91v7pxjV52H w+Em4VaUuZwuk1K6V9Xona+va9rFNyWj9Pu0CiiivTJCiiigAooooAKKKKACtnxDf219Doy2snmG 202OCX5SNrh3JHPXgjkcVjVo6tpP9lx6e3neb9ts1usbNuzczDb1Ofu9eOtc1RU3Wg5P3tbfqNX1 t2/VGdU9xfXd4MXd1NOPMaXEshb52xubnudoye+B6VFGnmSKm5V3EDcxwB7mui8U+CL/AMJW9nLq M9sWuo1dYknR25BJwFZsqPl+Y4zuGM4OFUxGHhWhSqSXPK/Kurtvb9QSbvY5uiiiuoQUUUUAFal7 qcN/4fsLedZPt1izRJJgbXtydyqTnOVYvjjowHG0Zy6KznTjOUZPeLuvut+oJ2NS91OG/wDD9hbz rJ9usWaJJMDa9uTuVSc5yrF8cdGA42jOXRRRTpxpR5Y7Xb+93Bu4UUUVoAUUUUAFFFFAEtsIDdwi 8aRbcyL5rRKC4TPzFQSATjOMmtDVNTg1nxM13dLJBYvKqLHCoLQ264VUUE4JVAAMnnHJrKorGVGM p8/W1vS+/wCn3BfSxoa7qn9sa1cXix+VCxCQQjpFEoCxoP8AdUKPwrPooq6cI04KEdloht3dwooo qxBRRRQAUUUUAFFFFABRRVu906Wwis5JmRheW4uI9pPClmXB465U/pUucU1FvVgVKKKKoCW1uZLO 7huYDtlhdZEOM4YHI/UVta14gsr6xltdK02axS6u/tlz510JtzgMFCYRNqje/ByeRzxWBRXPPD0q lSNSS1Xm/wAVs7dL3t0Gm0FS2wgN3CLxpFtzIvmtEoLhM/MVBIBOM4yaioreSumiTQ13VP7Y1q4v Fj8qFiEghHSKJQFjQf7qhR+FZ9W73TpbCKzkmZGF5bi4j2k8KWZcHjrlT+lVKzoqmqajT+FaL5aF Ntu4VPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelRRp5kipuVdxA3McAe5rovFPgi/8ACVvZy6jP bFrqNXWJJ0duQScBWbKj5fmOM7hjODjKpiMPCtClUkueV+VdXbe36gk3exzdFFFdQjZ8Q39tfQ6M trJ5httNjgl+Uja4dyRz14I5HFY1aOraT/Zcent53m/bbNbrGzbs3Mw29Tn7vXjrWdXNhVTVGKpO 8Ru+novyCiiiukQUUU6NQ8qIzrGrMAXbOF9zgE4+gNDdlcBtFdH4g8LRaPo9rqNtd3U0NxIUQ3di bbzxtBEsOWJkj/2iFIyvHPHOVhh8RSxNP2lJ3Xo1to9HZjaa3CiiitxBRRRQAUUVbvdOlsIrOSZk YXluLiPaTwpZlweOuVP6VLnFNRb1YFSiiiqAKKKKANzxB4nl163tIngWDy8y3DK2Tc3DAB5m9yFX j1ye9YdFW73TpbCKzkmZGF5bi4j2k8KWZcHjrlT+lc9KnRw0Y0aastbL8WO7bKlFFFdAgoq3e6dL YRWckzIwvLcXEe0nhSzLg8dcqf0qpUxnGa5ovQAoooqgCiird7p0thFZyTMjC8txcR7SeFLMuDx1 yp/Spc4pqLerAqVs+Ib+2vodGW1k8w22mxwS/KRtcO5I568EcjisatHVtJ/suPT287zfttmt1jZt 2bmYbepz93rx1rCoqbrQcn72tv1Gr627fqjOqe4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KijTz JFTcq7iBuY4A9zXReKfBF/4St7OXUZ7YtdRq6xJOjtyCTgKzZUfL8xxncMZwcKpiMPCtClUkueV+ VdXbe36gk3exzdFFFdQgooooAKKKKACnwzS21xHPbyPFNEweOSNirIwOQQR0IPemUUmk1Zga934s 8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZF FcyweGVrU46baLQfNLua934s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyI ZVmiE17I+yRfuuMnhh2I5FZFFCweGVrU46baLQOaXc17vxZ4jv1iW+1/VLkQyrNEJr2R9ki/dcZP DDsRyKj1HxNr2sWwttW1vUb6AMHEVzdySKGGQDhiRnk8+9ZlFOOEw0GnGnFW20WnoHNLuFFFFdIg ooooAKKKKACiiigAooooAKKKKAJLe4mtLiO4tZZIZomDxyxsVZGHIII5B9639W8da/q1vYRTavqW LSNM772RvMlV2ZZevDDIAPJG0c1zlakWildQ0mG9n8qHUlSRZIU8xo0Zyn3SVycqeM/jXFiaWFcl VrxTcb2bV3tqCbV7dh934s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZV miE17I+yRfuuMnhh2I5FX9e8K2unQSS6TqFxeiDUG0+YXFmLc+aAcFCHcMvBzyCPlyPmqhe+FtWs Wtg8EVx9qm8iJrK5iug0vH7vMTMA3I+U8muWjLLJxi4qK3tdKL87JpP10NHzq9wu/FniO/WJb7X9 UuRDKs0QmvZH2SL91xk8MOxHIou/FniO/WJb7X9UuRDKs0QmvZH2SL91xk8MOxHIq7f+DLvTPDja leTRCUX6WYSGeGaLLIzcypIQrDZyrAYDKc81Vv8Awxd2WrWGmqY3uL2FJEJuIPLYsSBtlWRkK5HU kfQUqVTK529nyaXtounxW8tdXsJ86vcZd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRc+LvE l6IheeINVuBDKJovNvZG8tx0cZPDDJwRzUU+galb2f2mSFDGLk2hWOZHdZRn5SiksM7TgkYOOM1P qnhPV9G0831/Dbi3WcWzvDeQzbJcE7GCOSrYU8EDpWqjlqlGK5L6pL3d+qX62D3/ADJtd8aa1r+n 2lnfalfywQwiOWOa8eRZnDM3mEHjOGA5z93rWBVu906Wwis5JmRheW4uI9pPClmXB465U/pVSurC 0qFGko4dJR8iW27XCp7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qKNPMkVNyruIG5jgD3NdF4p8 EX/hK3s5dRnti11GrrEk6O3IJOArNlR8vzHGdwxnBwqmIw8K0KVSS55X5V1dt7fqCTd7HN0UUV1C NnxDf219Doy2snmG202OCX5SNrh3JHPXgjkcVjVbvdOlsIrOSZkYXluLiPaTwpZlweOuVP6VUrDD whCko03dA+novyCiiitwCnxOscyO8ayqrAmNydrj0OCDg+xB96ZRSaurAb2qa5p02inS9E0u4sbe S6F1L9pvftB3BSqqmEQKuGbOQxPy5PFYNFFZUaEKEeWHrq2397bY22wooorYQUUU+GNZbiON5UhV 2CtLICVQE/eO0E4HXgE+xpN2VwFt7ia0uI7i1lkhmiYPHLGxVkYcggjkH3rf1bx1r+rW9hFNq+pY tI0zvvZG8yVXZll68MMgA8kbRzWdrGgX+hyR/bER4J9xt7uBxJDcAHBKOOGxkZHUZwQDxTovD95N f6VZxNEZdVRHg+YgKGdkG4kccqSevFefUWBrcuInyytez0enUa5otpf0h934s8R36xLfa/qlyIZV miE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FS32l+H0s3fSfEE11d LMIhBcWHkCQH+NX3sAv+9tPI464ra5okuhXFtBcMGea3WfcskUiHJI+V43dWXjrkH2FRSWAnKMYw Setk48r87JpO2u5T5+5Jd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciG VZohNeyPskX7rjJ4YdiORWXEI2mQTsyRFhvZF3Mq55IBIyfbI+tegXXw102x1q202+1jVbWW8nMN o8+joFuSHVcpicnHzAgsACM4JPFZYqpluClGNWCTabVoN6Le1k/V+WoLnkm0cnc+LvEl6IheeINV uBDKJovNvZG8tx0cZPDDJwRzVjXfGmta/p9pZ32pX8sEMIjljmvHkWZwzN5hB4zhgOc/d61Y1Hwn bad4en1KS8u0fMD2kM1oii4hm3lHLLK204jkJXBxgc88Yd7p0thFZyTMjC8txcR7SeFLMuDx1yp/ SroQy6tKM6UY3i3b3ba2u7aLo9/1Buae/T8LlSpLe4mtLiO4tZZIZomDxyxsVZGHIII5B96SGNZb iON5UhV2CtLICVQE/eO0E4HXgE+xq/rGgX+hyR/bER4J9xt7uBxJDcAHBKOOGxkZHUZwQDxXoTqU uZUptXl0fXv6+ZFjR1bx1r+rW9hFNq+pYtI0zvvZG8yVXZll68MMgA8kbRzVO78WeI79Ylvtf1S5 EMqzRCa9kfZIv3XGTww7Ecip18Owpq2h2lzeukerQxSmSOAMYd7soG0sN2COuR1q9qXg+x0iwvZ7 7VLnfa30NuBDZK6SxShmWVWMo/gRjtx97CkjkjyIzyqi4U4wXlaLe7t277/K/Qv32t+35afgZV34 s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5Fa es+E9N0fWLGGTW5Dp07GO4uns8PbSqFLxmJXbJUOnRupPpmotf8AD+iaTpsM1nrl1cXU8MVxFbz6 cIg0b553LK4BGOQfXgmqpVstm6apw+L4f3b72evLp53tbqO09dfxKNz4u8SXoiF54g1W4EMomi82 9kby3HRxk8MMnBHNWNd8aa1r+n2lnfalfywQwiOWOa8eRZnDM3mEHjOGA5z93rWBVu906Wwis5Jm RheW4uI9pPClmXB465U/pXb9TwcakH7OKavy6L52J5pa69PwKlbPiG/tr6HRltZPMNtpscEvykbX DuSOevBHI4rGq3e6dLYRWckzIwvLcXEe0nhSzLg8dcqf0repCDqwlJ6q9v1JXW3b9UVKnuL67vBi 7uppx5jS4lkLfO2Nzc9ztGT3wPSoo08yRU3Ku4gbmOAPc10XinwRf+Erezl1Ge2LXUausSTo7cgk 4Cs2VHy/McZ3DGcHEVMRh4VoUqklzyvyrq7b2/UaTd7HN0UUV1CCiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAJLe4mtLiO4tZZIZomDxyxsVZGHIII5B966W68 e6tqUulLq17qV3aWQj8+3e/ci5ZZC+87gQGwQMkHpXLVbvdOlsIrOSZkYXluLiPaTwpZlweOuVP6 Vx4jC4WvOLrRTlql387ME3ql2Op1X4gjWdQ+0anp81+tvfLeWK3155xgBIMkLHYPMibaMLhdvvyD Pf8AxIF1b2YW21S4uLO+W9im1PVvtXI4Me0RqAhHZdpGTyeMcJRXH/YmAXLan8O2stL6Pr169223 qy/aTbbvudNNr3h7+wJdKs9C1CKOa8iunkk1RHb5Ay7R+4AwVd8HGQSCcgbSmr+I9Kvf7Lk03Sby 1uNNSOKNri/SZGRGZsFRCh3Et1zjA6VzVFbxy3DRlzWd9d5Se6s93rp3E5N38zrtQ8VaDd2ksEXh y5RZ9RW/m8zU9/mEFt0fES4UqxAxhgTkluAE17xzLqlnbw2TasktvdC5iudQ1Q3csBAICxPsQxjn J65Kp0288lRUxyrCRlGXK243teUnvvu2P2kv6/rzN/XfGmta/p9pZ32pX8sEMIjljmvHkWZwzN5h B4zhgOc/d61gVbvdOlsIrOSZkYXluLiPaTwpZlweOuVP6VUrqwtKhRpKOHSUfIltu1wqe4vru8GL u6mnHmNLiWQt87Y3Nz3O0ZPfA9KijTzJFTcq7iBuY4A9zXReKfBF/wCErezl1Ge2LXUausSTo7cg k4Cs2VHy/McZ3DGcHCqYjDwrQpVJLnlflXV23t+oJN3sc3UlvcTWlxHcWsskM0TB45Y2KsjDkEEc g+9R0V0tKSsxHR6t461/Vrewim1fUsWkaZ33sjeZKrsyy9eGGQAeSNo5qnd+LPEd+sS32v6pciGV ZohNeyPskX7rjJ4YdiORWRRXHTwGEppKFOKttoupXNLua934s8R36xLfa/qlyIZVmiE17I+yRfuu Mnhh2I5FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZFFWsHhla1OOm2i0FzS7mvd+LPEd+ sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWRRQsH hla1OOm2i0Dml3Ne78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecii78WeI79Ylvtf1S5EMqzRC a9kfZIv3XGTww7EcisiihYPDK1qcdNtFoHNLua934s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5 FF34s8R36xLfa/qlyIZVmiE17I+yRfuuMnhh2I5FZFFCweGVrU46baLQOaXc17vxZ4jv1iW+1/VL kQyrNEJr2R9ki/dcZPDDsRyKLvxPrOrLFBr+sapqVksqyPbzXrtnHpu3ANgkA4OM9D0rIooWDw0b ctNK21klb07fIOaXc3rzxVciOK08PrJothC4kSG2nbfJICCJZZOC7jAwcBVx8qrk5uXPxE1+6m0p 5tRvZ108Rlorm7eWO4dHZg7KT1wQPXA61ytW73TpbCKzkmZGF5bi4j2k8KWZcHjrlT+lc8svwV4x lBN62vq9d9Xq35vUfNLWx0Nz4vsz4dbQ9PtdXh02a4SSW2n1cSxqisWKxL5ShCSc7iG6Dg1T8Ra3 pGr2dlHYaXe2k1nAtujzX6TK0aljyohQ7st1zjjpXP0VVLLcNSmpwTTTb+KW73b11v53Dnkx8RjW ZDOjPEGG9UbazLnkAkHB98H6V0ep+LIbrxZaa1Y2l3CkF59sNrc3omQSeYHOzEa7AcDsTx1rmaK3 q4WlWmpzV2k1u9nvpe3z3Fd2sddrPxAu9V037LDbmyki1L7ZazwzYa3jVSI4lwB9zcSGGOp4qpq3 jrX9Wt7CKbV9SxaRpnfeyN5kquzLL14YZAB5I2jmucq3e6dLYRWckzIwvLcXEe0nhSzLg8dcqf0r lhluAouMVTV1e3Xffcrnk23f+rly78T6zqyxQa/rGqalZLKsj28167Zx6btwDYJAODjPQ9KfqniJ 7qyGmaTb/wBl6SOTaRysxnb+/M3HmNwOwUfwquTnForpWDw8XFxgly7JbX722v52uTzM6a51ywTV PDd4qvdpptnCs0Ub+UfMSR227ip9Rzg1dXxzZNClpd6NNc2MWppfRI96PNCKJD5DP5eCm+Vm+6D8 zDvkcve6dLYRWckzIwvLcXEe0nhSzLg8dcqf0qpXH/ZuDrQXMnJLS92ur7Na6vXcfM7fd+R2GreO LfXNJvbPU9Mkkaa9F3DNC9tAyHBB3+Xbr5jNk5Y4/h4GDnL8Sa1p2siw/s7TrqyNpbrbHz7xZ96L 908Rpg8nPXPHA74dFbUMtwuHkpUY8tr2Sbtra+l7dO2+u43Uk9yS3uJrS4juLWWSGaJg8csbFWRh yCCOQfet/VvHWv6tb2EU2r6li0jTO+9kbzJVdmWXrwwyADyRtHNc5Vu906Wwis5JmRheW4uI9pPC lmXB465U/pWtbD4apVjKrFOSva6+8lNq9i5c+LvEl6IheeINVuBDKJovNvZG8tx0cZPDDJwRzVjX fGmta/p9pZ32pX8sEMIjljmvHkWZwzN5hB4zhgOc/d61gUUlgcKpRmqcU47aLQfNLuFT3F9d3gxd 3U048xpcSyFvnbG5ue52jJ74HpUUaeZIqblXcQNzHAHua6LxT4Iv/CVvZy6jPbFrqNXWJJ0duQSc BWbKj5fmOM7hjODiqmIw8K0KVSS55X5V1dt7fqJJu9jm6KKK6hBRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAElvcTWlxHcWsskM0TB45Y2KsjDkEEcg+9b+reO tf1a3sIptX1LFpGmd97I3mSq7MsvXhhkAHkjaOa5yiuarhaFacalSCbjs2thptbGvd+LPEd+sS32 v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORWRRSWDwyta nHTbRaBzS7mvd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyP skX7rjJ4YdiORWRRQsHhla1OOm2i0Dml3Ne78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecii58 XeJL0RC88QarcCGUTRebeyN5bjo4yeGGTgjmsiihYLCq1qcdNtEHNLub+u+NNa1/T7SzvtSv5YIY RHLHNePIszhmbzCDxnDAc5+71rAooq6GHpYeHs6MVFdkDbe4VPcX13eDF3dTTjzGlxLIW+dsbm57 naMnvgelRRp5kipuVdxA3McAe5rpPE3ga/8AC0di2o3NoGvERlQToxGc5PyM3yj5fmOM7uM4OIq4 jD060KdSSU5X5V1dt7fqCTaduhzNFdN4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHB4 m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHGNPM8FV5OSonz35fO29vTqNwkr3WxzNFdN 4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHB4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5 R8vzHGd3GcHBTzPBVeTkqJ89+Xztvb06g4SV7rY5mium8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8 o+X5jjO7jODg8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODgp5ngqvJyVE+e/L523t6d QcJK91sczRXTeJvA1/4WjsW1G5tA14iMqCdGIznJ+Rm+UfL8xxndxnBweJvA1/4WjsW1G5tA14iM qCdGIznJ+Rm+UfL8xxndxnBwU8zwVXk5KifPfl87b29OoOEle62OZorpvE3ga/8AC0di2o3NoGvE RlQToxGc5PyM3yj5fmOM7uM4ODxN4Gv/AAtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODgp5ngq vJyVE+e/L523t6dQcJK91sczRXTeJvA1/wCFo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcHibw Nf8AhaOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHBTzPBVeTkqJ89+Xztvb06g4SV7rY5mium8T eBr/AMLR2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg4PE3ga/wDC0di2o3NoGvERlQToxGc5PyM3 yj5fmOM7uM4OCnmeCq8nJUT578vnbe3p1Bwkr3WxztvcTWlxHcWsskM0TB45Y2KsjDkEEcg+9b+r eOtf1a3sIptX1LFpGmd97I3mSq7MsvXhhkAHkjaOaf4m8DX/AIWjsW1G5tA14iMqCdGIznJ+Rm+U fL8xxndxnBweJvA1/wCFo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcc31nK8XOlUbjJyvyPe9t 7enXsPlnG/pr6FC78WeI79Ylvtf1S5EMqzRCa9kfZIv3XGTww7Ecii78WeI79Ylvtf1S5EMqzRCa 9kfZIv3XGTww7Ecir/ibwNf+Fo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcHibwNf+Fo7FtRub QNeIjKgnRiM5yfkZvlHy/McZ3cZwcTSr5TU9n7PkfNflslrb4radOo3zq9yhd+LPEd+sS32v6pci GVZohNeyPskX7rjJ4YdiORRd+LPEd+sS32v6pciGVZohNeyPskX7rjJ4YdiORV/xN4Gv/C0di2o3 NoGvERlQToxGc5PyM3yj5fmOM7uM4ODxN4Gv/C0di2o3NoGvERlQToxGc5PyM3yj5fmOM7uM4OCl Xymp7P2fI+a/LZLW3xW06dQfOr3KFz4u8SXoiF54g1W4EMomi829kby3HRxk8MMnBHNWNd8aa1r+ n2lnfalfywQwiOWOa8eRZnDM3mEHjOGA5z93rU/ibwNf+Fo7FtRubQNeIjKgnRiM5yfkZvlHy/Mc Z3cZwcHibwNf+Fo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcKlVyipKlOlyXd3CyWtt7enUH7R Xv2/A5mpLe4mtLiO4tZZIZomDxyxsVZGHIII5B966LxN4Gv/AAtHYtqNzaBrxEZUE6MRnOT8jN8o +X5jjO7jODg8TeBr/wALR2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg464Zlgqygo1E/aX5f71t7 d7dSXCSvdbDNW8da/q1vYRTavqWLSNM772RvMlV2ZZevDDIAPJG0c1Tu/FniO/WJb7X9UuRDKs0Q mvZH2SL91xk8MOxHIq/4m8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHB4m8DX/haOxbUb m0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHHHh6mUNU1R5Pevy2S1t8VvTqU/aK9+i/AoXfizxHfrEt9r +qXIhlWaITXsj7JF+64yeGHYjkUXfizxHfrEt9r+qXIhlWaITXsj7JF+64yeGHYjkVf8TeBr/wAL R2Lajc2ga8RGVBOjEZzk/IzfKPl+Y4zu4zg4PE3ga/8AC0di2o3NoGvERlQToxGc5PyM3yj5fmOM 7uM4OKpV8pqez9nyPmvy2S1t8VtOnUHzq9yhc+LvEl6IheeINVuBDKJovNvZG8tx0cZPDDJwRzVj XfGmta/p9pZ32pX8sEMIjljmvHkWZwzN5hB4zhgOc/d61P4m8DX/AIWjsW1G5tA14iMqCdGIznJ+ Rm+UfL8xxndxnBweJvA1/wCFo7FtRubQNeIjKgnRiM5yfkZvlHy/McZ3cZwcKlVyipKlOlyXd3Cy Wtt7enUH7RXv2/A5mium8TeBr/wtHYtqNzaBrxEZUE6MRnOT8jN8o+X5jjO7jODg8TeBr/wtHYtq NzaBrxEZUE6MRnOT8jN8o+X5jjO7jODjsp5ngqvJyVE+e/L523t6dSXCSvdbHM1PcX13eDF3dTTj zGlxLIW+dsbm57naMnvgelb/AIm8DX/haOxbUbm0DXiIyoJ0YjOcn5Gb5R8vzHGd3GcHDfFPgi/8 JW9nLqM9sWuo1dYknR25BJwFZsqPl+Y4zuGM4OFTzHA13TcKibnfl87b29OockldWObooor0SQoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACp7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qCik4ptNrYCe4vru8GLu6mnHmNLi WQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qCipVOCtZbAT3F9d3gxd3U04 8xpcSyFvnbG5ue52jJ74HpRcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelQUUKnBWstgJ7i+u7wYu 7qaceY0uJZC3ztjc3Pc7Rk98D0ouL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKFTgrWWwE9xfX d4MXd1NOPMaXEshb52xubnudoye+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUFFCpwVrLYC e4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qCihU4K 1lsBPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelFxfXd4MXd1NOPMaXEshb52xubnudoye+B6VBR QqcFay2AnuL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSi4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA 9KgooVOCtZbAT3F9d3gxd3U048xpcSyFvnbG5ue52jJ74HpRcX13eDF3dTTjzGlxLIW+dsbm57na MnvgelQUUKnBWstgJ7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0ouL67vBi7uppx5jS4lkLfO2Nz c9ztGT3wPSoKKFTgrWWwE9xfXd4MXd1NOPMaXEshb52xubnudoye+B6UXF9d3gxd3U048xpcSyFv nbG5ue52jJ74HpUFFCpwVrLYCe4vru8GLu6mnHmNLiWQt87Y3Nz3O0ZPfA9KLi+u7wYu7qaceY0u JZC3ztjc3Pc7Rk98D0qCihU4K1lsBPcX13eDF3dTTjzGlxLIW+dsbm57naMnvgelFxfXd4MXd1NO PMaXEshb52xubnudoye+B6VBRQqcFay2AnuL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSi4vru8GL u6mnHmNLiWQt87Y3Nz3O0ZPfA9KgooVOCtZbAT3F9d3gxd3U048xpcSyFvnbG5ue52jJ74HpRcX1 3eDF3dTTjzGlxLIW+dsbm57naMnvgelQUUKnBWstgJ7i+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0 ouL67vBi7uppx5jS4lkLfO2Nzc9ztGT3wPSoKKFTgrWWwE9xfXd4MXd1NOPMaXEshb52xubnudoy e+B6UXF9d3gxd3U048xpcSyFvnbG5ue52jJ74HpUFFCpwVrLYCe4vru8GLu6mnHmNLiWQt87Y3Nz 3O0ZPfA9KLi+u7wYu7qaceY0uJZC3ztjc3Pc7Rk98D0qCihU4K1lsAUUUVYBRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQB//Z --_004_76B41B8FACE1514795D30EC137FF391D3D09B3LILASjungleqosmos_-- From paulq@cisco.com Tue Jan 28 05:33:20 2014 Return-Path: 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 14F141A03C3 for ; Tue, 28 Jan 2014 05:33:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 fjybc-s_RFez for ; Tue, 28 Jan 2014 05:33:17 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B0D8B1A039F for ; Tue, 28 Jan 2014 05:33:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4266; q=dns/txt; s=iport; t=1390915995; x=1392125595; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=EKVvCinjzNSgTNPe6s2CxInu22Mvkv3VatheW+hWOMM=; b=aECJpPoIUjLzyF8UqS0sk6ToXcVwzJ+Scb8trOAOhcFqMo+dZ9Jtgr/G UgAOkyLv8OSd8lZxsdjkXbIzmpBA86ez2yla4dcrQCkNlIh62cH45he/8 7qDx0cUTzF5EXe15nRda4ChY17odbopW58FIZM8IGoPq39CWSfmrcHhWh Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAFux51KtJXHA/2dsb2JhbABagwyBDoJ9uVkYfhZ0giUBAQEDASMRRQUHBAIBBgIRBAEBAQICIwMCAgIwFAEICAIEDgWHfQiOAZtxn3QXgSmNOxsHBoJpNYEUAQOYKJIfgy2CKg X-IronPort-AV: E=Sophos;i="4.95,736,1384300800"; d="scan'208";a="300214132" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 28 Jan 2014 13:33:14 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0SDXEcQ007403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Jan 2014 13:33:14 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.19]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Tue, 28 Jan 2014 07:33:13 -0600 From: "Paul Quinn (paulq)" To: "Songhaibin (A)" Thread-Topic: [sfc] Services eligible for chaining Thread-Index: AQHPG2mFQeofjW3B0UKZbnWKHHGTnZqZwCgAgADIlAA= Date: Tue, 28 Jan 2014 13:33:13 +0000 Message-ID: <2EE1C938-4B84-4558-9540-4DAF448132F6@cisco.com> References: <9C2DE4B8FE85984BA1B0581235F6B2ED0F633EAB@SZXEMA502-MBS.china.huawei.com> <9C2DE4B8FE85984BA1B0581235F6B2ED0F633F22@SZXEMA502-MBS.china.huawei.com> <52E5CAF7.80603@gmail.com> <6A6EB5A7-A39B-49DD-B665-7198EBDA9723@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.229] Content-Type: text/plain; charset="utf-8" Content-ID: <935F7BE2971B3C4F84F2F6E49789C8BA@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Melinda Shore , "sfc@ietf.org" Subject: Re: [sfc] Services eligible for chaining X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 13:33:20 -0000 SGksDQoNCg0KDQpPbiBKYW4gMjcsIDIwMTQsIGF0IDg6MzUgUE0sICJTb25naGFpYmluIChBKSIg PGhhaWJpbi5zb25nQGh1YXdlaS5jb20+DQogd3JvdGU6DQoNCj4gSGkgUGF1bCwNCj4gDQo+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogUGF1bCBRdWlubiAocGF1bHEpIFtt YWlsdG86cGF1bHFAY2lzY28uY29tXQ0KPj4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDI3LCAyMDE0 IDEwOjEwIFBNDQo+PiBUbzogU29uZ2hhaWJpbiAoQSkNCj4+IENjOiBNZWxpbmRhIFNob3JlOyBz ZmNAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlcyBlbGlnaWJsZSBmb3Ig Y2hhaW5pbmcNCj4+IA0KPj4gSGkgSGFpYmluLA0KPj4gDQo+PiANCj4+IE9uIEphbiAyNywgMjAx NCwgYXQgNDozNiBBTSwgU29uZ2hhaWJpbiAoQSkgPGhhaWJpbi5zb25nQGh1YXdlaS5jb20+DQo+ PiB3cm90ZToNCj4+IA0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9t OiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1lbGluZGEg U2hvcmUNCj4+Pj4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDI3LCAyMDE0IDEwOjU3IEFNDQo+Pj4+ IFRvOiBzZmNAaWV0Zi5vcmcNCj4+Pj4gU3ViamVjdDogUmU6IFtzZmNdIOetlOWkjTogU2Vydmlj ZXMgZWxpZ2libGUgZm9yIGNoYWluaW5nDQo+Pj4+IA0KPj4+PiBPbiAxLzI2LzE0IDU6MzEgUE0s IFpodWFuZ3l1eGluIHdyb3RlOg0KPj4+Pj4gICAgICAgIFdoZW4gdHJhZmZpYyBmcm9tIEludGVy bmV0IGFycml2ZXMgYXQgdGhlIHJvdXRlciwgaXRzIGRlc3RJUA0KPj4+Pj4gcG9pbnRzIGF0IE5B VC4gSG93IGRvZXMgdGhlIHJvdXRlciBkZWNpZGUgdGhlIG5leHQgaG9wPw0KPj4+Pj4gDQo+Pj4+ PiAtICAgICAgICBBcyB0aGUgcGFja2V0IGlzIGRpcmVjdGx5IGFkZHJlc3NlZCB0byB0aGUgTkFU LCBkb2VzIGl0DQo+Pj4+PiBjb25mbGljdCB3aXRoIHRoZSDigJh0cmFuc3BhcmVudCBtaWRib3ji gJkgY29uY2VwdCBpbg0KPj4+Pj4gZHJhZnQtcGFya2VyLXNmYy1jaGFpbi10by1wYXRoLTAwPw0K Pj4+IA0KPj4+IEkgdGhpbmsgdGhlIE5BVCBzZXJ2aWNlIGZ1bmN0aW9uIGlzIHRyYW5zcGFyZW50 IHRvIHRoZSBlbmQgdXNlcnMsIGJ1dCBub3QgdG8NCj4+IFNGQy4NCj4+PiANCj4+Pj4+IA0KPj4+ Pj4gLSAgICAgICAgSXMgaXQgcG9zc2libGUgZm9yIHRoZSBSb3V0ZXIgdG8gc2VuZCBvdXQgQVJQ IHRvIHF1ZXJ5IGZvciB0aGUNCj4+Pj4+IElQIGFkZHJlc3Mgb24gTkFUPyBIb3cgZG9lcyBOQVQg cmVhY3QgdG8gQVJQIHJlcXVlc3QgZXNwZWNpYWxseSB3aGVuDQo+Pj4+PiBOQVQgaXMgU0ZDLWF3 YXJlPw0KPj4+PiANCj4+Pj4gV2hlbiBJIGZpcnN0IHJlYWQgdGhpcyBJIHRob3VnaHQgIldlbGws IHllcywgYW5kIE5BVCBpcyBwYXJ0aWN1bGFybHkNCj4+Pj4gc2Vuc2l0aXZlIHRvIG5ldHdvcmsg dG9wb2xvZ3kgKGRldmljZSBvcmRlcmluZykuIiAgQnV0LCBJIHRoaW5rIHRoaXMNCj4+Pj4gbmVl ZG4ndCBhY3R1YWxseSBjcmVhdGUgYSBwYXJ0aWN1bGFybHkgZGlmZmljdWx0IHByb2JsZW0gaGVy ZSwgc2luY2UNCj4+Pj4gdGhlIG9yaWdpbmFsIHBhY2tldCBpcyBnb2luZyB0byBiZSBlbmNhcHN1 bGF0ZWQgYnkgdGhlIFNGQw0KPj4+PiB0cmFuc3BvcnQuIiAgSG93ZXZlciwgdGhlcmUgY2FuIGJl IHRoZSB1c3VhbCBwcm9ibGVtcyB3aXRoIHNlcnZpY2UNCj4+Pj4gb3JkZXJpbmcgdGhhdCB5b3Ug ZmluZCB3aXRoaW4gYSBzaW5nbGUgYm94IC0gZm9yIGV4YW1wbGUsIHlvdSBuZWVkIHRvDQo+Pj4+ IGJlIGF0dGVudGl2ZSB0byB3aGljaCBhZGRyZXNzZXMgeW91J3JlIHB1dHRpbmcgaW50byB5b3Vy IGZpcmV3YWxsaW5nDQo+Pj4+IHJ1bGVzLCBldGMuICBCdXQgdGhhdCdzIGdvaW5nIHRvIGJlIHRy dWUsIHJlZ2FyZGxlc3Mgd2hldGhlciB0aGUgc2VydmljZXMgYXJlDQo+PiBkZWNvbXBvc2VkIGlu dG8gZGlmZmVyZW50IGJveGVzIG9yIGNvLXJlc2lkZW50IHdpdGhpbiB0aGUgc2FtZSBib3guDQo+ Pj4+IFNpbWlsYXJseSwgdGhlIE5BVC1mcm9tLXRoZS1vdXRzaWRlIHByb2JsZW0gZXhpc3RzIHdo ZXRoZXIgb3Igbm90DQo+Pj4+IHlvdSdyZSB1c2luZyBTRkMuDQo+Pj4gDQo+Pj4gSSBkbyBub3Qg dGhpbmsgd2Ugc2hvdWxkIG1ha2UgdGhlIHNlcnZpY2UgZnVuY3Rpb25zIGF3YXJlIG9mIHRoZSBz ZXJ2aWNlDQo+PiBmdW5jdGlvbiBjaGFpbmluZy4gIFNGcyBzaG91bGQgb25seSByZWNlaXZlIHRo ZSBvcmlnaW5hbCBwYWNrZXQgYXMgdGhleQ0KPj4gY29udmVudGlvbmFsbHkgZG8sIHdpdGhvdXQg YW55IFNGQyBoZWFkZXJzLiBUaGUgU0ZDIGZvcndhcmRpbmcgZW5naW5lIHNob3VsZA0KPj4gYmUg cmVzcG9uc2libGUgZm9yIGFkZGluZy9yZW1vdmluZyB0aGUgaGVhZGVyLg0KPj4+IA0KPj4gDQo+ PiBXaGF0IGV4YWN0bHkgZG8geW91IG1lYW4gYnkgImF3YXJlIj8gIEluIGNlcnRhaW4gY2FzZXMs IHRoZSBTRnMgd2lsbCBuZWVkIHRvDQo+PiBiZSBhd2FyZSBvZiB0aGUgU0ZDIGVuY2FwLg0KPiAN Cj4gSSBtZWFuIHRoZXkoU0ZzKSBjYW4gcHJvY2VzcyB0aGUgcGFja2V0cyBhcyB0aGVyZSB3ZXJl IG5vIFNGQy4gT3RoZXJ3aXNlIHdlIG5lZWQgdG8gdXBncmFkZSB0aGUgc2VydmljZSBmdW5jdGlv bnMgdG8gc3VwcG9ydCBTRkMsIHdoaWNoIHdpbGwgYmUgYSBoaW5kcmFuY2UgZm9yIHRoZSBhZG9w dGlvbiBvZiBTRkMuIE1heWJlIEkgbWlzc2VkIHNvbWV0aGluZyBvciBteSB0aG91Z2h0IGlzIHRv byBpZGVhbCwgYnV0IHdoYXQgaXMgdGhlIHVzZSBjYXNlIGluIHlvdXIgbWluZCB0aGF0IGEgU0Yg bXVzdCBiZSBhd2FyZSBvZiB0aGUgU0ZDIGVuY2FwPyBUaGUgbWV0YWRhdGE/DQo+IA0KPiBCUiwN Cj4gLUhhaWJpbg0KDQpDZXJ0YWlubHksIFNGQyBuZWVkcyB0byBzdXBwb3J0IHNlcnZpY2VzIHRo YXQgZG8gbm90IHN1cHBvcnQgdGhlIFNGQyBlbmNhcC4gIEhvd2V2ZXIsIHRoZSBTRkMgZW5jYXAg Y2FuIHByb3ZpZGUgdmFsdWFibGUgaW5mb3JtYXRpb24gdG8gdGhlIFNGcyBzdWNoIGFzLCBhcyB5 b3UgcG9pbnQgb3V0LCBtZXRhZGF0YS4gIA0KDQpQYXVsDQoNCg0K From mikebianc@aol.com Tue Jan 28 07:07:46 2014 Return-Path: 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 E638B1A03B6 for ; Tue, 28 Jan 2014 07:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 Ew281SSAPD6o for ; Tue, 28 Jan 2014 07:07:42 -0800 (PST) Received: from omr-d01.mx.aol.com (omr-d01.mx.aol.com [205.188.252.208]) by ietfa.amsl.com (Postfix) with ESMTP id 7647E1A0431 for ; Tue, 28 Jan 2014 07:07:39 -0800 (PST) Received: from mtaout-mcd01.mx.aol.com (mtaout-mcd01.mx.aol.com [172.26.223.205]) by omr-d01.mx.aol.com (Outbound Mail Relay) with ESMTP id D6E1F700544E9; Tue, 28 Jan 2014 10:07:36 -0500 (EST) Received: from mgs-aam01.mail.aol.com (mgs-aam01.mail.aol.com [64.12.250.54]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-mcd01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 811013800040E; Tue, 28 Jan 2014 10:07:36 -0500 (EST) Date: Tue, 28 Jan 2014 10:07:36 -0500 From: "mikebianc@aol.com" To: jun.lee@huawei.com, zhuangyuxin@huawei.com, Ron_Parker@affirmednetworks.com, sfc@ietf.org, melinda.shore@gmail.com Message-ID: <1989047253.7723.1390921656400.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: <81126FE293D58240BD872F99F2606543368E3E75@szxema507-mbs.china.huawei.com> References: <9C2DE4B8FE85984BA1B0581235F6B2ED0F633EAB@SZXEMA502-MBS.china.huawei.com> <9C2DE4B8FE85984BA1B0581235F6B2ED0F633F22@SZXEMA502-MBS.china.huawei.com> <9C2DE4B8FE85984BA1B0581235F6B2ED0F6350D1@SZXEMA502-MBS.china.huawei.com> <81126FE293D58240BD872F99F2606543368E3E75@szxema507-mbs.china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7722_697248755.1390921656399" X-Originating-IP: 10.181.180.254, 205.188.91.40 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1390921656; bh=DIs6egshUQjbU70Bf9W2yWr7/s9D3CuXplOJPy2LBF0=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=enQytryp1Yd1V/hQ9GbddJ1fX3cfAFYSoSDJx/sZTtRAsnClzEsKyNLYPFKw4YIqn rfp5//NWk321x4KYmNNP5zHDttyNo1hOFxUphxGD9Yt9sc9t2CW9xjxAakKD8/hl3o M13NpkUJ0dNq82SWQCpIEhel0YP+vyAk8ae4ne5A= x-aol-sid: 3039ac1adfcd52e7c7b83a2a X-AOL-IP: 64.12.250.54 Subject: Re: [sfc] =?utf-8?b?562U5aSNOiBTZXJ2aWNlcyBlbGlnaWJsZSBmb3IgY2hhaW5p?= =?utf-8?q?ng?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 15:07:46 -0000 ------=_Part_7722_697248755.1390921656399 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable NAT for sure needs to be in the SFC at least in the direction that performs= the NAT because in that direction the packet dstIP is of the ultimate dst = and not that of the NAT. =C2=A0Typically, you will want your FW, etc to be = in the chain before this so the original packets can be inspected, but SFC = should not require that specifically. In the opposite direction, however, SFC is not required to direct the flow = through the NAT because the dstIP takes care of that. =C2=A0The same could = be said for L3 LB because that's how we force traffic through the LB in a n= on SFC world. =C2=A0However, that shouldn't mean that we *can't* use SFC fo= r these functions esp as its use might allow one to do things with flows th= at were otherwise not possible. From: jun.lee@huawei.com To: Zhuangyuxin,Zhuangyuxin= ,Ron Parker,sfc@ietf.org,Mel= inda Shore Sent: Monday, January 27, 2014 Subject: [sfc] =E7=AD=94=E5=A4=8D: Services eligible for chaining Without SFC, packets can already be forwarded to service functions with L3 = address. In this regard, service functions with L3 address are quite diff= erent to those =E2=80=98transparent midbox=E2=80=99. So, I wonder why SFC should cover NAT and LB. =20 Regards Li jun =20 =20 =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: sfc [mailto:sfc-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Zhuangyuxin =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B41=E6=9C=8828=E6=97=A5 8:48 =E6=94=B6=E4=BB=B6=E4=BA=BA: Zhuangyuxin; Ron Parker; sfc@ietf.org; Melinda= Shore =E4=B8=BB=E9=A2=98: [sfc] =E7=AD=94=E5=A4=8D: Services eligible for chainin= g =20 Actually, with these questions, I=E2=80=99m trying to figure out when we pu= t any service (e.g. NAT/LB/VPN) with L3 address in the chain, a) how the po= ssible ARP packets are handled, b) how the routing table is configured for the routers which are not in the chain, but the traffic = coming out of the chain will go thru. =20 =20 Thanks, Yuxin =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: sfc [mailto:sfc-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Zhuangyuxin =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B41=E6=9C=8827=E6=97=A5 10:32 =E6=94=B6=E4=BB=B6=E4=BA=BA: Ron Parker; sfc@ietf.org =E4=B8=BB=E9=A2=98: [sfc] =E7=AD=94=E5=A4=8D: Services eligible for chainin= g =20 Hi, Ron, =20 Thanks for the reply. =20 When we consider inserting LB/NAT in the chain, I have some further questio= ns here. =20 - Let=E2=80=99s take a chain with NAT service function as an example= , user is using this chain to process traffic produced by VM1 accessing Int= ernet. I assume the topology is like this: VM1 --- (chain including NAT) --- Router --- Internet When traffic from Internet arrives at the router, its destIP point= s at NAT. How does the router decide the next hop? - As the packet is directly addressed to the NAT, does it conflict w= ith the =E2=80=98transparent midbox=E2=80=99 concept in draft-parker-sfc-ch= ain-to-path-00? - Is it possible for the Router to send out ARP to query for the IP = address on NAT? How does NAT react to ARP request especially when NAT is SFC-aware? =20 Thanks, Yuxin =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: Ron Parker [mailto:Ron_Parker@affirmednetworks= .com] =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B41=E6=9C=8827=E6=97=A5 9:29 =E6=94=B6=E4=BB=B6=E4=BA=BA: Zhuangyuxin;=20 sfc@ietf.org =E4=B8=BB=E9=A2=98: RE: Services eligible for chaining =20 Yuxin, =20 Both load balancer and NAT are definitely candidates for SFC service functi= ons. =20 Ron =20 =20 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Zhuangyuxin Sent: Sunday, January 26, 2014 8:06 PM To: sfc@ietf.org Subject: [sfc] Services eligible for chaining =20 Hello, Folks, =20 For SFC, do you have any concrete service candidates which are eligible for= chaining? How about load balancer and NAT, which usually cross subnets and= change packet header? Are they suitable for the chain we are discussing here? =20 Thanks, Yuxin=20 ------=_Part_7722_697248755.1390921656399 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
NAT for sure ne= eds to be in the SFC at least in the direction that performs the NAT becaus= e in that direction the packet dstIP is of the ultimate dst and not that of= the NAT.  Typically, you will want your FW, etc to be in the chain be= fore this so the original packets can be inspected, but SFC should not requ= ire that specifically.

In the opposite direction, = however, SFC is not required to direct the flow through the NAT because the= dstIP takes care of that.  The same could be said for L3 LB because t= hat's how we force traffic through the LB in a non SFC world.  However= , that shouldn't mean that we *can't* use SFC for these functions esp as it= s use might allow one to do things with flows that were otherwise not possi= ble.





From: jun.lee@huawei.com<jun.lee@huawei.com>= ;
To: Zhuangyuxin<zhuangyuxin@huawei.com>,Zhuangyuxin<zh= uangyuxin@huawei.com>,Ron Parker<Ron_Parker@affirmednetworks.com>,= sfc@ietf.org<sfc@ietf.org>,Melinda Shore<melinda.shore@gmail.com&g= t;
Sent: Monday, January 27, 2014
Subject: [sfc] =E7=AD= =94=E5=A4=8D: Services eligible for chaining

Without= SFC, packets can already be forwarded to service functions with L3 address= . In this regard, service functions with L3 address are quite different t= o those =E2=80=98transparent mi= dbox=E2=80=99.

So, I w= onder why SFC should cover NAT and LB.

<= /o:p>

Regards=

Li jun<= o:p>

<= /o:p>

<= /o:p>

<= /o:p>

=E5=8F=91=E4=BB=B6= =E4=BA=BA: sfc [mailto:sfc-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Zhuangyuxin
= =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B41=E6=9C=8828=E6=97=A5 8:48
=E6=94=B6=E4=BB=B6=E4=BA=BA: Zhuangyuxin; Ron Parker; s= fc@ietf.org; Melinda Shore
=E4=B8=BB=E9=A2=98: [sfc] =E7=AD=94=E5=A4=8D: Services elig= ible for chaining

=20

Actuall= y, with these questions, I=E2=80=99m trying to figure out when we put any s= ervice (e.g. NAT/LB/VPN) with L3 address in the chain, a) how the possible = ARP packets are handled, b) how the routing table is configured for the routers which are not in the chain, but the traffic = coming out of the chain will go thru.

<= /o:p>

<= /o:p>

Thanks,=

Yuxin

<= /o:p>

=E5=8F=91=E4=BB=B6= =E4=BA=BA: sfc [mailto:sfc-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Zhuangyuxin
= =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B41=E6=9C=8827=E6=97=A5 10:32
=E6=94=B6=E4=BB=B6=E4=BA=BA: Ron Parker; sfc@ietf.org
=E4=B8=BB=E9=A2=98: [sfc] =E7=AD=94=E5=A4=8D: Services elig= ible for chaining

Hi, Ron= ,

<= /o:p>

Thanks = for the reply.

<= /o:p>

When we= consider inserting LB/NAT in the chain, I have some further questions here= .

<= /o:p>

- = Let=E2=80=99s take a chain with NAT service function as an example, user = is using this chain to process traffic produced by VM1 accessing Internet. = I assume the topology is like this:

= VM1 --- (chain including NAT) --- Router --- Internet<= /p>

When traffic= from Internet arrives at the router, its destIP points at NAT. How does th= e router decide the next hop?

- As the packe= t is directly addressed to the NAT, does it conflict with the =E2=80=98tran= sparent midbox=E2=80=99 concept in draft-parker-sfc-chain-to-path-00?<= /o:p>

- Is it possib= le for the Router to send out ARP to query for the IP address on NAT? How d= oes NAT react to ARP request especially when NAT is SFC-aware?

<= /o:p>

Thanks,=

Yuxin

<= /o:p>

=E5=8F=91=E4=BB=B6= =E4=BA=BA: Ron Parker [mailto:Ron_Parker@affirmednetwo= rks.com]
= =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B41=E6=9C=8827=E6=97=A5 9:29
=E6=94=B6=E4=BB=B6=E4=BA=BA: Zhuangyuxin; sfc@ietf.org
=E4=B8=BB=E9=A2=98: RE: Services eligible for chaining

Yuxin,

Both load balancer and NAT are definitely candidates for SFC serv= ice functions.

Ron

From: sfc [= mailto:sfc-bounces@ietf.org] On Behalf Of Zhuangyuxin
Sent: Sunday, January 26, 2014 8:06 PM
To: sfc@ietf.org
Subject: [sfc] Services eligible for chaining

Hello, Folks,=

For SFC, do you have any concre= te service candidates which are eligible for chaining? How about load balan= cer and NAT, which usually cross subnets and change packet header? Are they= suitable for the chain we are discussing here?

Thanks,

Yuxin

------=_Part_7722_697248755.1390921656399-- From Ron_Parker@affirmednetworks.com Tue Jan 28 07:58:22 2014 Return-Path: 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 A45C91A0439 for ; Tue, 28 Jan 2014 07:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 KT3OktnXozqC for ; Tue, 28 Jan 2014 07:58:20 -0800 (PST) Received: from hub021-ca-2.exch021.serverdata.net (hub021-ca-2.exch021.serverdata.net [64.78.22.169]) by ietfa.amsl.com (Postfix) with ESMTP id 4E08F1A02EA for ; Tue, 28 Jan 2014 07:58:20 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0158.001; Tue, 28 Jan 2014 07:58:18 -0800 From: Ron Parker To: "mikebianc@aol.com" , "jun.lee@huawei.com" , "zhuangyuxin@huawei.com" , "sfc@ietf.org" , "melinda.shore@gmail.com" Thread-Topic: =?utf-8?B?W3NmY10g562U5aSNOiBTZXJ2aWNlcyBlbGlnaWJsZSBmb3IgY2hhaW5pbmc=?= Thread-Index: Ac8aTJ6FwniRxzcWRuaQFnPfr+bu1gAr0QHAAADQNHAAABcD4AAwlPPgAAKOGCAALGv+AAAQuT9g Date: Tue, 28 Jan 2014 15:58:17 +0000 Message-ID: References: <9C2DE4B8FE85984BA1B0581235F6B2ED0F633EAB@SZXEMA502-MBS.china.huawei.com> <9C2DE4B8FE85984BA1B0581235F6B2ED0F633F22@SZXEMA502-MBS.china.huawei.com> <9C2DE4B8FE85984BA1B0581235F6B2ED0F6350D1@SZXEMA502-MBS.china.huawei.com> <81126FE293D58240BD872F99F2606543368E3E75@szxema507-mbs.china.huawei.com> <1989047253.7723.1390921656400.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: <1989047253.7723.1390921656400.JavaMail.tomcat@mgs-aam01.mail.aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A79A078MBX021W3CA2exch_" MIME-Version: 1.0 Subject: Re: [sfc] =?utf-8?b?562U5aSNOiBTZXJ2aWNlcyBlbGlnaWJsZSBmb3IgY2hhaW5p?= =?utf-8?q?ng?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 15:58:22 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A79A078MBX021W3CA2exch_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VHlwaWNhbGx5LCBhIHNvdXJjZSBOQVQvTkFQVCBwZXJmb3JtZWQgZnJvbSBjbGllbnQgdG8gc2Vy dmVyIHdhbnRzIHRvIGJlIHJldmVyc2VkIGluIHRoZSBzZXJ2ZXIgdG8gY2xpZW50IGRpcmVjdGlv bi4gICBUaGlzIGlzIGFuIGV4Y2VsbGVudCB1c2UgY2FzZSBmb3IgYSBiaWRpcmVjdGlvbmFsIGNo YWluIG9yIGNvb3JkaW5hdGlvbiBvZiAyIHVuaWRpcmVjdGlvbmFsIGNoYWlucy4gICBJdCBpcyBv ZnRlbiBkZXNpcmFibGUgdG8gcHV0IHRoZSBOQVQgZnVuY3Rpb24gbGFzdCBpbiB0aGUgY2xpZW50 IHRvIHNlcnZlciBkaXJlY3Rpb24gYW5kIGZpcnN0IGluIHRoZSBzZXJ2ZXIgdG8gY2xpZW50IGRp cmVjdGlvbiAoYWx0aG91Z2ggdGhpcyBpcyBub3QgdW5pdmVyc2FsbHkgZG9uZSkuDQoNCkFsc28s IE5BVCBpcyB0cmFkaXRpb25hbGx5IGNvb3JkaW5hdGVkIHdpdGggcm91dGluZy4gICBJbiB0aGUg c2VydmVyIHRvIGNsaWVudCBkaXJlY3Rpb24sIHRoZSByZXBsYWNlbWVudCBJUCBhZGRyZXNzZXMg bXVzdCBnZXQgcm91dGVkIGJhY2sgdG8gdGhlIHNlcnZpY2UgZnVuY3Rpb24gdGhhdCBwZXJmb3Jt ZWQgdGhlIE5BVC4gICAgVGhpcyBjb3VsZCBiZSBhY2hpZXZlZCBpbiB0aGUgdHJhZGl0aW9uYWwg bWFubmVyIGJ5IGFzc3VtaW5nIHRoYXQgdGhlIHJvdXRpbmcgaXMgaGFuZGxlZCBvdXRzaWRlIG9m IFNGQy4NCg0KQWx0ZXJuYXRpdmVseSwgdGhlIHJldmVyc2UgZmxvd3MgY291bGQgYmUgaGFuZGxl ZCBieSBoYXZpbmcgdGhlIGNsYXNzaWZpZXIgYXJyYW5nZWQgdG9wb2xvZ2ljYWxseSBzdWNoIHRo YXQgaXQgc2VlcyBhbGwgdHJhZmZpYyBhcnJpdmluZyBmcm9tIHRoZSBzZXJ2ZXIgc2lkZSBhbmQg ZGV0ZXJtaW5lcyB0aGF0IHRoZSByZWxldmFudCBmbG93cyBtdXN0IGdvIHRvIHRoZSBOQVQgc2Vy dmljZSBmdW5jdGlvbiB0byBiZSB1bi1OQVTigJlkLiAgICBJbiB0aGUgY2xhc3NpZmllciBhcHBy b2FjaCwgZWl0aGVyIHRoZSBjbGFzc2lmaWVyIG11c3QgYmUgcHJvdmlzaW9uZWQgd2l0aCBmaWx0 ZXJzIHRoYXQgbWF0Y2ggdGhlIE5BVCByZXBsYWNlbWVudCBJUCBhZGRyZXNzZXMgKGkuZS4sIGNv b3JkaW5hdGVkIGNvbmZpZ3VyYXRpb24pIG9yIHNvbWUgZHluYW1pYyBtZWNoYW5pc20gbXVzdCBl eGlzdCBiZXR3ZWVuIHRoZSBOQVQgc2VydmljZSBmdW5jdGlvbiBhbmQgdGhlIGNsYXNzaWZpZXIg c3VjaCB0aGF0IGR5bmFtaWMgcG9saWN5IHJ1bGVzIGNhbiBiZSBpbnN0YWxsZWQuDQoNCklNTywg TkFUIHdvdWxkIGJlIGFuIGV4Y2VsbGVudCBjYW5kaWRhdGUgZm9yIG9uZSBvZiB0aG9zZSAzLTUg dXNlIGNhc2VzIGluIG91ciB1c2UgY2FzZSBkb2N1bWVudC4NCg0KDQogICAgUm9uDQoNCg0KDQoN CkZyb206IG1pa2ViaWFuY0Bhb2wuY29tIFttYWlsdG86bWlrZWJpYW5jQGFvbC5jb21dDQpTZW50 OiBUdWVzZGF5LCBKYW51YXJ5IDI4LCAyMDE0IDEwOjA4IEFNDQpUbzoganVuLmxlZUBodWF3ZWku Y29tOyB6aHVhbmd5dXhpbkBodWF3ZWkuY29tOyBSb24gUGFya2VyOyBzZmNAaWV0Zi5vcmc7IG1l bGluZGEuc2hvcmVAZ21haWwuY29tDQpTdWJqZWN0OiBSRTogW3NmY10g562U5aSNOiBTZXJ2aWNl cyBlbGlnaWJsZSBmb3IgY2hhaW5pbmcNCg0KTkFUIGZvciBzdXJlIG5lZWRzIHRvIGJlIGluIHRo ZSBTRkMgYXQgbGVhc3QgaW4gdGhlIGRpcmVjdGlvbiB0aGF0IHBlcmZvcm1zIHRoZSBOQVQgYmVj YXVzZSBpbiB0aGF0IGRpcmVjdGlvbiB0aGUgcGFja2V0IGRzdElQIGlzIG9mIHRoZSB1bHRpbWF0 ZSBkc3QgYW5kIG5vdCB0aGF0IG9mIHRoZSBOQVQuICBUeXBpY2FsbHksIHlvdSB3aWxsIHdhbnQg eW91ciBGVywgZXRjIHRvIGJlIGluIHRoZSBjaGFpbiBiZWZvcmUgdGhpcyBzbyB0aGUgb3JpZ2lu YWwgcGFja2V0cyBjYW4gYmUgaW5zcGVjdGVkLCBidXQgU0ZDIHNob3VsZCBub3QgcmVxdWlyZSB0 aGF0IHNwZWNpZmljYWxseS4NCg0KSW4gdGhlIG9wcG9zaXRlIGRpcmVjdGlvbiwgaG93ZXZlciwg U0ZDIGlzIG5vdCByZXF1aXJlZCB0byBkaXJlY3QgdGhlIGZsb3cgdGhyb3VnaCB0aGUgTkFUIGJl Y2F1c2UgdGhlIGRzdElQIHRha2VzIGNhcmUgb2YgdGhhdC4gIFRoZSBzYW1lIGNvdWxkIGJlIHNh aWQgZm9yIEwzIExCIGJlY2F1c2UgdGhhdCdzIGhvdyB3ZSBmb3JjZSB0cmFmZmljIHRocm91Z2gg dGhlIExCIGluIGEgbm9uIFNGQyB3b3JsZC4gIEhvd2V2ZXIsIHRoYXQgc2hvdWxkbid0IG1lYW4g dGhhdCB3ZSAqY2FuJ3QqIHVzZSBTRkMgZm9yIHRoZXNlIGZ1bmN0aW9ucyBlc3AgYXMgaXRzIHVz ZSBtaWdodCBhbGxvdyBvbmUgdG8gZG8gdGhpbmdzIHdpdGggZmxvd3MgdGhhdCB3ZXJlIG90aGVy d2lzZSBub3QgcG9zc2libGUuDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KRnJvbToganVuLmxlZUBodWF3ZWkuY29tPGp1bi5sZWVAaHVhd2VpLmNvbTxtYWlsdG86anVu LmxlZUBodWF3ZWkuY29tJTNjanVuLmxlZUBodWF3ZWkuY29tPj4NClRvOiBaaHVhbmd5dXhpbjx6 aHVhbmd5dXhpbkBodWF3ZWkuY29tPG1haWx0bzp6aHVhbmd5dXhpbkBodWF3ZWkuY29tPj4sWmh1 YW5neXV4aW48emh1YW5neXV4aW5AaHVhd2VpLmNvbTxtYWlsdG86emh1YW5neXV4aW5AaHVhd2Vp LmNvbT4+LFJvbiBQYXJrZXI8Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbTxtYWlsdG86 Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4+LHNmY0BpZXRmLm9yZzxzZmNAaWV0Zi5v cmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4+LE1lbGluZGEgU2hvcmU8bWVsaW5kYS5zaG9yZUBnbWFp bC5jb208bWFpbHRvOm1lbGluZGEuc2hvcmVAZ21haWwuY29tPj4NClNlbnQ6IE1vbmRheSwgSmFu dWFyeSAyNywgMjAxNA0KU3ViamVjdDogW3NmY10g562U5aSNOiBTZXJ2aWNlcyBlbGlnaWJsZSBm b3IgY2hhaW5pbmcNCldpdGhvdXQgU0ZDLCBwYWNrZXRzIGNhbiBhbHJlYWR5IGJlIGZvcndhcmRl ZCB0byBzZXJ2aWNlIGZ1bmN0aW9ucyB3aXRoIEwzIGFkZHJlc3MuIEluIHRoaXMgcmVnYXJkLCBz ZXJ2aWNlIGZ1bmN0aW9ucyB3aXRoIEwzIGFkZHJlc3MgYXJlIHF1aXRlIGRpZmZlcmVudCB0byB0 aG9zZSDigJh0cmFuc3BhcmVudCBtaWRib3jigJkuDQpTbywgSSB3b25kZXIgd2h5IFNGQyBzaG91 bGQgY292ZXIgTkFUIGFuZCBMQi4NClJlZ2FyZHMNCkxpIGp1bg0K5Y+R5Lu25Lq6OiBzZmMgW21h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIFpodWFuZ3l1eGluDQrlj5HpgIHml7bp l7Q6IDIwMTTlubQx5pyIMjjml6UgODo0OA0K5pS25Lu25Lq6OiBaaHVhbmd5dXhpbjsgUm9uIFBh cmtlcjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+OyBNZWxpbmRhIFNob3JlDQrk uLvpopg6IFtzZmNdIOetlOWkjTogU2VydmljZXMgZWxpZ2libGUgZm9yIGNoYWluaW5nDQpBY3R1 YWxseSwgd2l0aCB0aGVzZSBxdWVzdGlvbnMsIEnigJltIHRyeWluZyB0byBmaWd1cmUgb3V0IHdo ZW4gd2UgcHV0IGFueSBzZXJ2aWNlIChlLmcuIE5BVC9MQi9WUE4pIHdpdGggTDMgYWRkcmVzcyBp biB0aGUgY2hhaW4sIGEpIGhvdyB0aGUgcG9zc2libGUgQVJQIHBhY2tldHMgYXJlIGhhbmRsZWQs IGIpIGhvdyB0aGUgcm91dGluZyB0YWJsZSBpcyBjb25maWd1cmVkIGZvciB0aGUgcm91dGVycyB3 aGljaCBhcmUgbm90IGluIHRoZSBjaGFpbiwgYnV0IHRoZSB0cmFmZmljIGNvbWluZyBvdXQgb2Yg dGhlIGNoYWluIHdpbGwgZ28gdGhydS4NClRoYW5rcywNCll1eGluDQrlj5Hku7bkuro6IHNmYyBb bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSDku6PooaggWmh1YW5neXV4aW4NCuWPkemAgeaX tumXtDogMjAxNOW5tDHmnIgyN+aXpSAxMDozMg0K5pS25Lu25Lq6OiBSb24gUGFya2VyOyBzZmNA aWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCuS4u+mimDogW3NmY10g562U5aSNOiBTZXJ2 aWNlcyBlbGlnaWJsZSBmb3IgY2hhaW5pbmcNCkhpLCBSb24sDQpUaGFua3MgZm9yIHRoZSByZXBs eS4NCldoZW4gd2UgY29uc2lkZXIgaW5zZXJ0aW5nIExCL05BVCBpbiB0aGUgY2hhaW4sIEkgaGF2 ZSBzb21lIGZ1cnRoZXIgcXVlc3Rpb25zIGhlcmUuDQotIExldOKAmXMgdGFrZSBhIGNoYWluIHdp dGggTkFUIHNlcnZpY2UgZnVuY3Rpb24gYXMgYW4gZXhhbXBsZSwgdXNlciBpcyB1c2luZyB0aGlz IGNoYWluIHRvIHByb2Nlc3MgdHJhZmZpYyBwcm9kdWNlZCBieSBWTTEgYWNjZXNzaW5nIEludGVy bmV0LiBJIGFzc3VtZSB0aGUgdG9wb2xvZ3kgaXMgbGlrZSB0aGlzOg0KVk0xIC0tLSAoY2hhaW4g aW5jbHVkaW5nIE5BVCkgLS0tIFJvdXRlciAtLS0gSW50ZXJuZXQNCldoZW4gdHJhZmZpYyBmcm9t IEludGVybmV0IGFycml2ZXMgYXQgdGhlIHJvdXRlciwgaXRzIGRlc3RJUCBwb2ludHMgYXQgTkFU LiBIb3cgZG9lcyB0aGUgcm91dGVyIGRlY2lkZSB0aGUgbmV4dCBob3A/DQotIEFzIHRoZSBwYWNr ZXQgaXMgZGlyZWN0bHkgYWRkcmVzc2VkIHRvIHRoZSBOQVQsIGRvZXMgaXQgY29uZmxpY3Qgd2l0 aCB0aGUg4oCYdHJhbnNwYXJlbnQgbWlkYm944oCZIGNvbmNlcHQgaW4gZHJhZnQtcGFya2VyLXNm Yy1jaGFpbi10by1wYXRoLTAwPw0KLSBJcyBpdCBwb3NzaWJsZSBmb3IgdGhlIFJvdXRlciB0byBz ZW5kIG91dCBBUlAgdG8gcXVlcnkgZm9yIHRoZSBJUCBhZGRyZXNzIG9uIE5BVD8gSG93IGRvZXMg TkFUIHJlYWN0IHRvIEFSUCByZXF1ZXN0IGVzcGVjaWFsbHkgd2hlbiBOQVQgaXMgU0ZDLWF3YXJl Pw0KVGhhbmtzLA0KWXV4aW4NCuWPkeS7tuS6ujogUm9uIFBhcmtlciBbbWFpbHRvOlJvbl9QYXJr ZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb21dDQrlj5HpgIHml7bpl7Q6IDIwMTTlubQx5pyIMjfml6Ug OToyOQ0K5pS25Lu25Lq6OiBaaHVhbmd5dXhpbjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0 Zi5vcmc+DQrkuLvpopg6IFJFOiBTZXJ2aWNlcyBlbGlnaWJsZSBmb3IgY2hhaW5pbmcNCll1eGlu LA0KQm90aCBsb2FkIGJhbGFuY2VyIGFuZCBOQVQgYXJlIGRlZmluaXRlbHkgY2FuZGlkYXRlcyBm b3IgU0ZDIHNlcnZpY2UgZnVuY3Rpb25zLg0KUm9uDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFpodWFuZ3l1eGluDQpTZW50OiBTdW5kYXksIEph bnVhcnkgMjYsIDIwMTQgODowNiBQTQ0KVG86IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYu b3JnPg0KU3ViamVjdDogW3NmY10gU2VydmljZXMgZWxpZ2libGUgZm9yIGNoYWluaW5nDQpIZWxs bywgRm9sa3MsDQpGb3IgU0ZDLCBkbyB5b3UgaGF2ZSBhbnkgY29uY3JldGUgc2VydmljZSBjYW5k aWRhdGVzIHdoaWNoIGFyZSBlbGlnaWJsZSBmb3IgY2hhaW5pbmc/IEhvdyBhYm91dCBsb2FkIGJh bGFuY2VyIGFuZCBOQVQsIHdoaWNoIHVzdWFsbHkgY3Jvc3Mgc3VibmV0cyBhbmQgY2hhbmdlIHBh Y2tldCBoZWFkZXI/IEFyZSB0aGV5IHN1aXRhYmxlIGZvciB0aGUgY2hhaW4gd2UgYXJlIGRpc2N1 c3NpbmcgaGVyZT8NClRoYW5rcywNCll1eGluDQo= --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A79A078MBX021W3CA2exch_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2 IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRo IjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAy IDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9z ZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VHlwaWNhbGx5LCBhIHNvdXJjZSBOQVQv TkFQVCBwZXJmb3JtZWQgZnJvbSBjbGllbnQgdG8gc2VydmVyIHdhbnRzIHRvIGJlIHJldmVyc2Vk IGluIHRoZSBzZXJ2ZXIgdG8gY2xpZW50IGRpcmVjdGlvbi4mbmJzcDsmbmJzcDsgVGhpcyBpcyBh biBleGNlbGxlbnQgdXNlIGNhc2UgZm9yIGEgYmlkaXJlY3Rpb25hbA0KIGNoYWluIG9yIGNvb3Jk aW5hdGlvbiBvZiAyIHVuaWRpcmVjdGlvbmFsIGNoYWlucy4mbmJzcDsmbmJzcDsgSXQgaXMgb2Z0 ZW4gZGVzaXJhYmxlIHRvIHB1dCB0aGUgTkFUIGZ1bmN0aW9uIGxhc3QgaW4gdGhlIGNsaWVudCB0 byBzZXJ2ZXIgZGlyZWN0aW9uIGFuZCBmaXJzdCBpbiB0aGUgc2VydmVyIHRvIGNsaWVudCBkaXJl Y3Rpb24gKGFsdGhvdWdoIHRoaXMgaXMgbm90IHVuaXZlcnNhbGx5IGRvbmUpLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ QWxzbywgTkFUIGlzIHRyYWRpdGlvbmFsbHkgY29vcmRpbmF0ZWQgd2l0aCByb3V0aW5nLiZuYnNw OyZuYnNwOyBJbiB0aGUgc2VydmVyIHRvIGNsaWVudCBkaXJlY3Rpb24sIHRoZSByZXBsYWNlbWVu dCBJUCBhZGRyZXNzZXMgbXVzdCBnZXQgcm91dGVkIGJhY2sgdG8gdGhlIHNlcnZpY2UgZnVuY3Rp b24NCiB0aGF0IHBlcmZvcm1lZCB0aGUgTkFULiZuYnNwOyZuYnNwOyZuYnNwOyBUaGlzIGNvdWxk IGJlIGFjaGlldmVkIGluIHRoZSB0cmFkaXRpb25hbCBtYW5uZXIgYnkgYXNzdW1pbmcgdGhhdCB0 aGUgcm91dGluZyBpcyBoYW5kbGVkIG91dHNpZGUgb2YgU0ZDLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWx0ZXJuYXRp dmVseSwgdGhlIHJldmVyc2UgZmxvd3MgY291bGQgYmUgaGFuZGxlZCBieSBoYXZpbmcgdGhlIGNs YXNzaWZpZXIgYXJyYW5nZWQgdG9wb2xvZ2ljYWxseSBzdWNoIHRoYXQgaXQgc2VlcyBhbGwgdHJh ZmZpYyBhcnJpdmluZyBmcm9tIHRoZSBzZXJ2ZXIgc2lkZQ0KIGFuZCBkZXRlcm1pbmVzIHRoYXQg dGhlIHJlbGV2YW50IGZsb3dzIG11c3QgZ28gdG8gdGhlIE5BVCBzZXJ2aWNlIGZ1bmN0aW9uIHRv IGJlIHVuLU5BVOKAmWQuJm5ic3A7ICZuYnNwOyZuYnNwO0luIHRoZSBjbGFzc2lmaWVyIGFwcHJv YWNoLCBlaXRoZXIgdGhlIGNsYXNzaWZpZXIgbXVzdCBiZSBwcm92aXNpb25lZCB3aXRoIGZpbHRl cnMgdGhhdCBtYXRjaCB0aGUgTkFUIHJlcGxhY2VtZW50IElQIGFkZHJlc3NlcyAoaS5lLiwgY29v cmRpbmF0ZWQgY29uZmlndXJhdGlvbikgb3INCiBzb21lIGR5bmFtaWMgbWVjaGFuaXNtIG11c3Qg ZXhpc3QgYmV0d2VlbiB0aGUgTkFUIHNlcnZpY2UgZnVuY3Rpb24gYW5kIHRoZSBjbGFzc2lmaWVy IHN1Y2ggdGhhdCBkeW5hbWljIHBvbGljeSBydWxlcyBjYW4gYmUgaW5zdGFsbGVkLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SU1PLCBOQVQgd291bGQgYmUgYW4gZXhjZWxsZW50IGNhbmRpZGF0ZSBmb3Igb25lIG9mIHRo b3NlIDMtNSB1c2UgY2FzZXMgaW4gb3VyIHVzZSBjYXNlIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyBSb248 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gbWlrZWJpYW5jQGFvbC5j b20gW21haWx0bzptaWtlYmlhbmNAYW9sLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5 LCBKYW51YXJ5IDI4LCAyMDE0IDEwOjA4IEFNPGJyPg0KPGI+VG86PC9iPiBqdW4ubGVlQGh1YXdl aS5jb207IHpodWFuZ3l1eGluQGh1YXdlaS5jb207IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZzsg bWVsaW5kYS5zaG9yZUBnbWFpbC5jb208YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtzZmNdIDwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBH b3RoaWMmcXVvdDsiPuetlOWkjTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjog U2VydmljZXMgZWxpZ2libGUgZm9yIGNoYWluaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TkFUIGZvciBzdXJlIG5lZWRz IHRvIGJlIGluIHRoZSBTRkMgYXQgbGVhc3QgaW4gdGhlIGRpcmVjdGlvbiB0aGF0IHBlcmZvcm1z IHRoZSBOQVQgYmVjYXVzZSBpbiB0aGF0IGRpcmVjdGlvbiB0aGUgcGFja2V0IGRzdElQIGlzIG9m IHRoZSB1bHRpbWF0ZSBkc3QgYW5kIG5vdCB0aGF0IG9mIHRoZSBOQVQuDQogJm5ic3A7VHlwaWNh bGx5LCB5b3Ugd2lsbCB3YW50IHlvdXIgRlcsIGV0YyB0byBiZSBpbiB0aGUgY2hhaW4gYmVmb3Jl IHRoaXMgc28gdGhlIG9yaWdpbmFsIHBhY2tldHMgY2FuIGJlIGluc3BlY3RlZCwgYnV0IFNGQyBz aG91bGQgbm90IHJlcXVpcmUgdGhhdCBzcGVjaWZpY2FsbHkuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5JbiB0aGUgb3Bwb3NpdGUgZGlyZWN0aW9uLCBob3dldmVyLCBTRkMg aXMgbm90IHJlcXVpcmVkIHRvIGRpcmVjdCB0aGUgZmxvdyB0aHJvdWdoIHRoZSBOQVQgYmVjYXVz ZSB0aGUgZHN0SVAgdGFrZXMgY2FyZSBvZiB0aGF0LiAmbmJzcDtUaGUgc2FtZSBjb3VsZA0KIGJl IHNhaWQgZm9yIEwzIExCIGJlY2F1c2UgdGhhdCdzIGhvdyB3ZSBmb3JjZSB0cmFmZmljIHRocm91 Z2ggdGhlIExCIGluIGEgbm9uIFNGQyB3b3JsZC4gJm5ic3A7SG93ZXZlciwgdGhhdCBzaG91bGRu J3QgbWVhbiB0aGF0IHdlICpjYW4ndCogdXNlIFNGQyBmb3IgdGhlc2UgZnVuY3Rpb25zIGVzcCBh cyBpdHMgdXNlIG1pZ2h0IGFsbG93IG9uZSB0byBkbyB0aGluZ3Mgd2l0aCBmbG93cyB0aGF0IHdl cmUgb3RoZXJ3aXNlIG5vdCBwb3NzaWJsZS48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tYm90 dG9tOjYuNzVwdCI+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxl PSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMSIgd2lkdGg9IjEwMCUiIG5vc2hhZGU9 IiIgc3R5bGU9ImNvbG9yOiM5OTk5OTkiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+RnJv bTogPC9iPjxhIGhyZWY9Im1haWx0bzpqdW4ubGVlQGh1YXdlaS5jb20lM2NqdW4ubGVlQGh1YXdl aS5jb20iPmp1bi5sZWVAaHVhd2VpLmNvbSZsdDtqdW4ubGVlQGh1YXdlaS5jb208L2E+Jmd0Ozxi cj4NCjxiPlRvOiA8L2I+Wmh1YW5neXV4aW4mbHQ7PGEgaHJlZj0ibWFpbHRvOnpodWFuZ3l1eGlu QGh1YXdlaS5jb20iPnpodWFuZ3l1eGluQGh1YXdlaS5jb208L2E+Jmd0OyxaaHVhbmd5dXhpbiZs dDs8YSBocmVmPSJtYWlsdG86emh1YW5neXV4aW5AaHVhd2VpLmNvbSI+emh1YW5neXV4aW5AaHVh d2VpLmNvbTwvYT4mZ3Q7LFJvbiBQYXJrZXImbHQ7PGEgaHJlZj0ibWFpbHRvOlJvbl9QYXJrZXJA YWZmaXJtZWRuZXR3b3Jrcy5jb20iPlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb208L2E+ Jmd0OyxzZmNAaWV0Zi5vcmcmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGll dGYub3JnPC9hPiZndDssTWVsaW5kYQ0KIFNob3JlJmx0OzxhIGhyZWY9Im1haWx0bzptZWxpbmRh LnNob3JlQGdtYWlsLmNvbSI+bWVsaW5kYS5zaG9yZUBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxi PlNlbnQ6IDwvYj5Nb25kYXksIEphbnVhcnkgMjcsIDIwMTQ8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+ W3NmY10gPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+562U5aSNPC9zcGFuPjogU2VydmljZXMgZWxpZ2libGUgZm9yIGNo YWluaW5nPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+V2l0aG91dCBTRkMsIHBhY2tldHMgY2FuIGFscmVhZHkg YmUgZm9yd2FyZGVkIHRvIHNlcnZpY2UgZnVuY3Rpb25zIHdpdGggTDMgYWRkcmVzcy4gSW4gdGhp cyByZWdhcmQsIHNlcnZpY2UgZnVuY3Rpb25zIHdpdGggTDMgYWRkcmVzcyBhcmUgcXVpdGUgZGlm ZmVyZW50DQogdG8gdGhvc2Ug4oCYdHJhbnNwYXJlbnQgbWlkYm944oCZLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPlNvLCBJIHdvbmRlciB3aHkgU0ZDIHNob3VsZCBjb3ZlciBOQVQgYW5kIExCLg0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+UmVnYXJkczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkxpIGp1bjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNp bVN1biI+5Y+R5Lu25Lq6Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6U2ltU3VuIj4gc2ZjIFs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpT aW1TdW4iPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj5dDQo8Yj7ku6PooaggPC9iPlpo dWFuZ3l1eGluPGJyPg0KPGI+5Y+R6YCB5pe26Ze0OjwvYj4gMjAxNOW5tDHmnIgyOOaXpSA4OjQ4 PGJyPg0KPGI+5pS25Lu25Lq6OjwvYj4gWmh1YW5neXV4aW47IFJvbiBQYXJrZXI7IDwvc3Bhbj48 YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTpTaW1TdW4iPnNmY0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj47IE1lbGluZGEgU2hvcmU8YnI+ DQo8Yj7kuLvpopg6PC9iPiBbc2ZjXSDnrZTlpI06IFNlcnZpY2VzIGVsaWdpYmxlIGZvciBjaGFp bmluZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5BY3R1YWxseSwgd2l0aCB0aGVz ZSBxdWVzdGlvbnMsIEnigJltIHRyeWluZyB0byBmaWd1cmUgb3V0IHdoZW4gd2UgcHV0IGFueSBz ZXJ2aWNlIChlLmcuIE5BVC9MQi9WUE4pIHdpdGggTDMgYWRkcmVzcyBpbiB0aGUgY2hhaW4sIGEp IGhvdyB0aGUgcG9zc2libGUNCiBBUlAgcGFja2V0cyBhcmUgaGFuZGxlZCwgYikgaG93IHRoZSBy b3V0aW5nIHRhYmxlIGlzIGNvbmZpZ3VyZWQgZm9yIHRoZSByb3V0ZXJzIHdoaWNoIGFyZSBub3Qg aW4gdGhlIGNoYWluLCBidXQgdGhlIHRyYWZmaWMgY29taW5nIG91dCBvZiB0aGUgY2hhaW4gd2ls bCBnbyB0aHJ1Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5ZdXhp bjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OlNpbVN1biI+5Y+R5Lu25Lq6Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4gc2ZjIFs8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTpTaW1TdW4iPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48 L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj5dDQo8 Yj7ku6PooaggPC9iPlpodWFuZ3l1eGluPGJyPg0KPGI+5Y+R6YCB5pe26Ze0OjwvYj4gMjAxNOW5 tDHmnIgyN+aXpSAxMDozMjxicj4NCjxiPuaUtuS7tuS6ujo8L2I+IFJvbiBQYXJrZXI7IDwvc3Bh bj48YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTpTaW1TdW4iPnNmY0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8Yj7kuLvpopg6 PC9iPiBbc2ZjXSDnrZTlpI06IFNlcnZpY2VzIGVsaWdpYmxlIGZvciBjaGFpbmluZzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IaSwgUm9uLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoYW5r cyBmb3IgdGhlIHJlcGx5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPldoZW4gd2UgY29uc2lkZXIgaW5zZXJ0 aW5nIExCL05BVCBpbiB0aGUgY2hhaW4sIEkgaGF2ZSBzb21lIGZ1cnRoZXIgcXVlc3Rpb25zIGhl cmUuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4tIExldOKAmXMgdGFrZSBhIGNoYWluIHdpdGggTkFUIHNl cnZpY2UgZnVuY3Rpb24gYXMgYW4gZXhhbXBsZSwgdXNlciBpcyB1c2luZyB0aGlzIGNoYWluIHRv IHByb2Nlc3MgdHJhZmZpYyBwcm9kdWNlZCBieSBWTTEgYWNjZXNzaW5nIEludGVybmV0LiBJIGFz c3VtZQ0KIHRoZSB0b3BvbG9neSBpcyBsaWtlIHRoaXM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Vk0xIC0t LSAoY2hhaW4gaW5jbHVkaW5nIE5BVCkgLS0tIFJvdXRlciAtLS0gSW50ZXJuZXQ8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hdXRvc3BhY2U6bm9uZSI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+V2hlbiB0cmFmZmljIGZyb20gSW50ZXJuZXQg YXJyaXZlcyBhdCB0aGUgcm91dGVyLCBpdHMgZGVzdElQIHBvaW50cyBhdCBOQVQuIEhvdyBkb2Vz IHRoZSByb3V0ZXIgZGVjaWRlIHRoZSBuZXh0IGhvcD88L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+LSBBcyB0aGUgcGFja2V0IGlzIGRpcmVjdGx5IGFkZHJlc3NlZCB0byB0 aGUgTkFULCBkb2VzIGl0IGNvbmZsaWN0IHdpdGggdGhlIOKAmHRyYW5zcGFyZW50IG1pZGJveOKA mSBjb25jZXB0IGluIGRyYWZ0LXBhcmtlci1zZmMtY2hhaW4tdG8tcGF0aC0wMD88L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hdXRvc3BhY2U6bm9uZSI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+LSBJcyBpdCBwb3NzaWJsZSBmb3IgdGhlIFJv dXRlciB0byBzZW5kIG91dCBBUlAgdG8gcXVlcnkgZm9yIHRoZSBJUCBhZGRyZXNzIG9uIE5BVD8g SG93IGRvZXMgTkFUIHJlYWN0IHRvIEFSUCByZXF1ZXN0IGVzcGVjaWFsbHkgd2hlbiBOQVQgaXMg U0ZDLWF3YXJlPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5ZdXhp bjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OlNpbVN1biI+5Y+R5Lu25Lq6Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4gUm9uIFBhcmtlciBbPC9zcGFuPjxh IGhyZWY9Im1haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPm1haWx0bzpSb25fUGFya2Vy QGFmZmlybWVkbmV0d29ya3MuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTpTaW1TdW4iPl0NCjxicj4NCjxiPuWPkemAgeaXtumXtDo8L2I+IDIw MTTlubQx5pyIMjfml6UgOToyOTxicj4NCjxiPuaUtuS7tuS6ujo8L2I+IFpodWFuZ3l1eGluOyA8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj5zZmNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPGI+5Li7 6aKYOjwvYj4gUkU6IFNlcnZpY2VzIGVsaWdpYmxlIGZvciBjaGFpbmluZzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPll1eGluLDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6IzFGNDk3RCI+Qm90aCBsb2FkIGJhbGFuY2VyIGFuZCBOQVQgYXJlIGRlZmlu aXRlbHkgY2FuZGlkYXRlcyBmb3IgU0ZDIHNlcnZpY2UgZnVuY3Rpb25zLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6IzFGNDk3RCI+Um9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+IHNmYyBbPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0Bp ZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPm1haWx0bzpzZmMtYm91bmNl c0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPl0NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+Wmh1YW5neXV4aW48YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBK YW51YXJ5IDI2LCAyMDE0IDg6MDYgUE08YnI+DQo8Yj5Ubzo8L2I+IDwvc3Bhbj48YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+c2ZjQGll dGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFtzZmNdIFNlcnZpY2VzIGVsaWdpYmxlIGZvciBjaGFpbmluZzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhl bGxvLCBGb2xrcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Rm9yIFNG QywgZG8geW91IGhhdmUgYW55IGNvbmNyZXRlIHNlcnZpY2UgY2FuZGlkYXRlcyB3aGljaCBhcmUg ZWxpZ2libGUgZm9yIGNoYWluaW5nPyBIb3cgYWJvdXQgbG9hZCBiYWxhbmNlciBhbmQgTkFULCB3 aGljaCB1c3VhbGx5IGNyb3NzIHN1Ym5ldHMgYW5kIGNoYW5nZSBwYWNrZXQgaGVhZGVyPyBBcmUN CiB0aGV5IHN1aXRhYmxlIGZvciB0aGUgY2hhaW4gd2UgYXJlIGRpc2N1c3NpbmcgaGVyZT88bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzLDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ZdXhpbg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A79A078MBX021W3CA2exch_-- From Kevin.Glavin@riverbed.com Tue Jan 28 09:32:07 2014 Return-Path: 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 C74561A02B6 for ; Tue, 28 Jan 2014 09:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.515 X-Spam-Level: *** X-Spam-Status: No, score=3.515 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.535, 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 jgVa9eFnzusK for ; Tue, 28 Jan 2014 09:32:04 -0800 (PST) Received: from smtp1.riverbed.com (smtp.riverbed.com [208.70.196.45]) by ietfa.amsl.com (Postfix) with ESMTP id 686CB1A017D for ; Tue, 28 Jan 2014 09:32:04 -0800 (PST) Received: from unknown (HELO 365EXCH-HUB-P1.nbttech.com) ([10.16.4.1]) by smtp1.riverbed.com with ESMTP; 28 Jan 2014 09:32:01 -0800 Received: from SFO1EXC-MBXP07.nbttech.com ([fe80::470:1b85:695b:b44e]) by 365EXCH-HUB-P1.nbttech.com ([::1]) with mapi id 14.02.0328.009; Tue, 28 Jan 2014 09:32:01 -0800 From: Kevin Glavin To: Ron Parker , "mikebianc@aol.com" , "jun.lee@huawei.com" , "zhuangyuxin@huawei.com" , "sfc@ietf.org" , "melinda.shore@gmail.com" Thread-Topic: =?gb2312?B?W3NmY10gtPC4tDogU2VydmljZXMgZWxpZ2libGUgZm9yIGNoYWluaW5n?= Thread-Index: AQHPHEHNJ+bOhtOpHEemZpycK3bsSpqaY63M Date: Tue, 28 Jan 2014 17:32:00 +0000 Message-ID: <9EA32E60D7600C43B6FE22876DF564C81D8ACB1D@SFO1EXC-MBXP07.nbttech.com> References: <9C2DE4B8FE85984BA1B0581235F6B2ED0F633EAB@SZXEMA502-MBS.china.huawei.com> <9C2DE4B8FE85984BA1B0581235F6B2ED0F633F22@SZXEMA502-MBS.china.huawei.com> <9C2DE4B8FE85984BA1B0581235F6B2ED0F6350D1@SZXEMA502-MBS.china.huawei.com> <81126FE293D58240BD872F99F2606543368E3E75@szxema507-mbs.china.huawei.com> <1989047253.7723.1390921656400.JavaMail.tomcat@mgs-aam01.mail.aol.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.205.254] Content-Type: multipart/alternative; boundary="_000_9EA32E60D7600C43B6FE22876DF564C81D8ACB1DSFO1EXCMBXP07nb_" MIME-Version: 1.0 Subject: Re: [sfc] =?gb2312?b?tPC4tDogU2VydmljZXMgZWxpZ2libGUgZm9yIGNoYWluaW5n?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 17:32:08 -0000 --_000_9EA32E60D7600C43B6FE22876DF564C81D8ACB1DSFO1EXCMBXP07nb_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 QW5vdGhlciBleGFtcGxlIG9mIHRoZSAiYmlkaXJlY3Rpb25hbCBjaGFpbiBvciBjb29yZGluYXRp b24gb2YgMiB1bmlkaXJlY3Rpb25hbCBjaGFpbnMiIHNjZW5hcmlvIHdvdWxkIGJlIGNoYWluaW5n IFdhbiBPcHRpbWl6YXRpb24gYWxvbmcgd2l0aCBzb21lIGluc3BlY3Rpb24gc2VydmljZSBzdWNo IGFzIElQUy4gQXNzdW1pbmcgdGhhdCB0aGUgc2VnbWVudCBiZXR3ZWVuIHRoZSB0d28gV2FuIE9w dCBub2RlcyAoRGF0YSBDZW50ZXIgYW5kIEJyYW5jaCkgaXMgdHJhbnNmb3JtZWQgdGhlbiB5b3Ug aGF2ZSB0aGUgc2FtZSBzY2VuYXJpbyB3aGVyZSBJUFMgaGFzIHRvIGJlIGRvbmUgb24gdGhlIHVu dHJhbnNmb3JtZWQgZmxvdy4NCg0KSW4gdGhlIGRhdGEgY2VudGVyIGluIHRoZSBvdXRib3VuZCBk aXJlY3Rpb24gKHRvd2FyZHMgYSByZW1vdGUgc2l0ZSkgSVBTIG5lZWRzIHRvIGhhcHBlbiBiZWZv cmUgV2FuIE9wdCB3aGlsZSBpbmJvdW5kIGludG8gdGhlIERDLCBXYW4gT3B0IGhhcyB0byBiZSBw cm9jZXNzZWQgYmVmb3JlIElQUyBmb3IgdGhlIElQUyB0byBmdW5jdGlvbiBjb3JyZWN0bHkuDQoN CktldmluDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBzZmMgW3Nm Yy1ib3VuY2VzQGlldGYub3JnXSBvbiBiZWhhbGYgb2YgUm9uIFBhcmtlciBbUm9uX1BhcmtlckBh ZmZpcm1lZG5ldHdvcmtzLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjgsIDIwMTQgNzo1 OCBBTQ0KVG86IG1pa2ViaWFuY0Bhb2wuY29tOyBqdW4ubGVlQGh1YXdlaS5jb207IHpodWFuZ3l1 eGluQGh1YXdlaS5jb207IHNmY0BpZXRmLm9yZzsgbWVsaW5kYS5zaG9yZUBnbWFpbC5jb20NClN1 YmplY3Q6IFJlOiBbc2ZjXSC08Li0OiBTZXJ2aWNlcyBlbGlnaWJsZSBmb3IgY2hhaW5pbmcNCg0K VHlwaWNhbGx5LCBhIHNvdXJjZSBOQVQvTkFQVCBwZXJmb3JtZWQgZnJvbSBjbGllbnQgdG8gc2Vy dmVyIHdhbnRzIHRvIGJlIHJldmVyc2VkIGluIHRoZSBzZXJ2ZXIgdG8gY2xpZW50IGRpcmVjdGlv bi4gICBUaGlzIGlzIGFuIGV4Y2VsbGVudCB1c2UgY2FzZSBmb3IgYSBiaWRpcmVjdGlvbmFsIGNo YWluIG9yIGNvb3JkaW5hdGlvbiBvZiAyIHVuaWRpcmVjdGlvbmFsIGNoYWlucy4gICBJdCBpcyBv ZnRlbiBkZXNpcmFibGUgdG8gcHV0IHRoZSBOQVQgZnVuY3Rpb24gbGFzdCBpbiB0aGUgY2xpZW50 IHRvIHNlcnZlciBkaXJlY3Rpb24gYW5kIGZpcnN0IGluIHRoZSBzZXJ2ZXIgdG8gY2xpZW50IGRp cmVjdGlvbiAoYWx0aG91Z2ggdGhpcyBpcyBub3QgdW5pdmVyc2FsbHkgZG9uZSkuDQoNCkFsc28s IE5BVCBpcyB0cmFkaXRpb25hbGx5IGNvb3JkaW5hdGVkIHdpdGggcm91dGluZy4gICBJbiB0aGUg c2VydmVyIHRvIGNsaWVudCBkaXJlY3Rpb24sIHRoZSByZXBsYWNlbWVudCBJUCBhZGRyZXNzZXMg bXVzdCBnZXQgcm91dGVkIGJhY2sgdG8gdGhlIHNlcnZpY2UgZnVuY3Rpb24gdGhhdCBwZXJmb3Jt ZWQgdGhlIE5BVC4gICAgVGhpcyBjb3VsZCBiZSBhY2hpZXZlZCBpbiB0aGUgdHJhZGl0aW9uYWwg bWFubmVyIGJ5IGFzc3VtaW5nIHRoYXQgdGhlIHJvdXRpbmcgaXMgaGFuZGxlZCBvdXRzaWRlIG9m IFNGQy4NCg0KQWx0ZXJuYXRpdmVseSwgdGhlIHJldmVyc2UgZmxvd3MgY291bGQgYmUgaGFuZGxl ZCBieSBoYXZpbmcgdGhlIGNsYXNzaWZpZXIgYXJyYW5nZWQgdG9wb2xvZ2ljYWxseSBzdWNoIHRo YXQgaXQgc2VlcyBhbGwgdHJhZmZpYyBhcnJpdmluZyBmcm9tIHRoZSBzZXJ2ZXIgc2lkZSBhbmQg ZGV0ZXJtaW5lcyB0aGF0IHRoZSByZWxldmFudCBmbG93cyBtdXN0IGdvIHRvIHRoZSBOQVQgc2Vy dmljZSBmdW5jdGlvbiB0byBiZSB1bi1OQVShr2QuICAgIEluIHRoZSBjbGFzc2lmaWVyIGFwcHJv YWNoLCBlaXRoZXIgdGhlIGNsYXNzaWZpZXIgbXVzdCBiZSBwcm92aXNpb25lZCB3aXRoIGZpbHRl cnMgdGhhdCBtYXRjaCB0aGUgTkFUIHJlcGxhY2VtZW50IElQIGFkZHJlc3NlcyAoaS5lLiwgY29v cmRpbmF0ZWQgY29uZmlndXJhdGlvbikgb3Igc29tZSBkeW5hbWljIG1lY2hhbmlzbSBtdXN0IGV4 aXN0IGJldHdlZW4gdGhlIE5BVCBzZXJ2aWNlIGZ1bmN0aW9uIGFuZCB0aGUgY2xhc3NpZmllciBz dWNoIHRoYXQgZHluYW1pYyBwb2xpY3kgcnVsZXMgY2FuIGJlIGluc3RhbGxlZC4NCg0KSU1PLCBO QVQgd291bGQgYmUgYW4gZXhjZWxsZW50IGNhbmRpZGF0ZSBmb3Igb25lIG9mIHRob3NlIDMtNSB1 c2UgY2FzZXMgaW4gb3VyIHVzZSBjYXNlIGRvY3VtZW50Lg0KDQoNCiAgICBSb24NCg0KDQoNCg0K RnJvbTogbWlrZWJpYW5jQGFvbC5jb20gW21haWx0bzptaWtlYmlhbmNAYW9sLmNvbV0NClNlbnQ6 IFR1ZXNkYXksIEphbnVhcnkgMjgsIDIwMTQgMTA6MDggQU0NClRvOiBqdW4ubGVlQGh1YXdlaS5j b207IHpodWFuZ3l1eGluQGh1YXdlaS5jb207IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZzsgbWVs aW5kYS5zaG9yZUBnbWFpbC5jb20NClN1YmplY3Q6IFJFOiBbc2ZjXSC08Li0OiBTZXJ2aWNlcyBl bGlnaWJsZSBmb3IgY2hhaW5pbmcNCg0KTkFUIGZvciBzdXJlIG5lZWRzIHRvIGJlIGluIHRoZSBT RkMgYXQgbGVhc3QgaW4gdGhlIGRpcmVjdGlvbiB0aGF0IHBlcmZvcm1zIHRoZSBOQVQgYmVjYXVz ZSBpbiB0aGF0IGRpcmVjdGlvbiB0aGUgcGFja2V0IGRzdElQIGlzIG9mIHRoZSB1bHRpbWF0ZSBk c3QgYW5kIG5vdCB0aGF0IG9mIHRoZSBOQVQuICBUeXBpY2FsbHksIHlvdSB3aWxsIHdhbnQgeW91 ciBGVywgZXRjIHRvIGJlIGluIHRoZSBjaGFpbiBiZWZvcmUgdGhpcyBzbyB0aGUgb3JpZ2luYWwg cGFja2V0cyBjYW4gYmUgaW5zcGVjdGVkLCBidXQgU0ZDIHNob3VsZCBub3QgcmVxdWlyZSB0aGF0 IHNwZWNpZmljYWxseS4NCg0KSW4gdGhlIG9wcG9zaXRlIGRpcmVjdGlvbiwgaG93ZXZlciwgU0ZD IGlzIG5vdCByZXF1aXJlZCB0byBkaXJlY3QgdGhlIGZsb3cgdGhyb3VnaCB0aGUgTkFUIGJlY2F1 c2UgdGhlIGRzdElQIHRha2VzIGNhcmUgb2YgdGhhdC4gIFRoZSBzYW1lIGNvdWxkIGJlIHNhaWQg Zm9yIEwzIExCIGJlY2F1c2UgdGhhdCdzIGhvdyB3ZSBmb3JjZSB0cmFmZmljIHRocm91Z2ggdGhl IExCIGluIGEgbm9uIFNGQyB3b3JsZC4gIEhvd2V2ZXIsIHRoYXQgc2hvdWxkbid0IG1lYW4gdGhh dCB3ZSAqY2FuJ3QqIHVzZSBTRkMgZm9yIHRoZXNlIGZ1bmN0aW9ucyBlc3AgYXMgaXRzIHVzZSBt aWdodCBhbGxvdyBvbmUgdG8gZG8gdGhpbmdzIHdpdGggZmxvd3MgdGhhdCB3ZXJlIG90aGVyd2lz ZSBub3QgcG9zc2libGUuDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K RnJvbToganVuLmxlZUBodWF3ZWkuY29tPGp1bi5sZWVAaHVhd2VpLmNvbTxtYWlsdG86anVuLmxl ZUBodWF3ZWkuY29tJTNjanVuLmxlZUBodWF3ZWkuY29tPj4NClRvOiBaaHVhbmd5dXhpbjx6aHVh bmd5dXhpbkBodWF3ZWkuY29tPG1haWx0bzp6aHVhbmd5dXhpbkBodWF3ZWkuY29tPj4sWmh1YW5n eXV4aW48emh1YW5neXV4aW5AaHVhd2VpLmNvbTxtYWlsdG86emh1YW5neXV4aW5AaHVhd2VpLmNv bT4+LFJvbiBQYXJrZXI8Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbTxtYWlsdG86Um9u X1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4+LHNmY0BpZXRmLm9yZzxzZmNAaWV0Zi5vcmc8 bWFpbHRvOnNmY0BpZXRmLm9yZz4+LE1lbGluZGEgU2hvcmU8bWVsaW5kYS5zaG9yZUBnbWFpbC5j b208bWFpbHRvOm1lbGluZGEuc2hvcmVAZ21haWwuY29tPj4NClNlbnQ6IE1vbmRheSwgSmFudWFy eSAyNywgMjAxNA0KU3ViamVjdDogW3NmY10gtPC4tDogU2VydmljZXMgZWxpZ2libGUgZm9yIGNo YWluaW5nDQpXaXRob3V0IFNGQywgcGFja2V0cyBjYW4gYWxyZWFkeSBiZSBmb3J3YXJkZWQgdG8g c2VydmljZSBmdW5jdGlvbnMgd2l0aCBMMyBhZGRyZXNzLiBJbiB0aGlzIHJlZ2FyZCwgc2Vydmlj ZSBmdW5jdGlvbnMgd2l0aCBMMyBhZGRyZXNzIGFyZSBxdWl0ZSBkaWZmZXJlbnQgdG8gdGhvc2Ug oa50cmFuc3BhcmVudCBtaWRib3ihry4NClNvLCBJIHdvbmRlciB3aHkgU0ZDIHNob3VsZCBjb3Zl ciBOQVQgYW5kIExCLg0KUmVnYXJkcw0KTGkganVuDQq3orz+yMs6IHNmYyBbbWFpbHRvOnNmYy1i b3VuY2VzQGlldGYub3JnXSC0+rHtIFpodWFuZ3l1eGluDQq3osvNyrG85DogMjAxNMTqMdTCMjjI 1SA4OjQ4DQrK1bz+yMs6IFpodWFuZ3l1eGluOyBSb24gUGFya2VyOyBzZmNAaWV0Zi5vcmc8bWFp bHRvOnNmY0BpZXRmLm9yZz47IE1lbGluZGEgU2hvcmUNCtb3zOI6IFtzZmNdILTwuLQ6IFNlcnZp Y2VzIGVsaWdpYmxlIGZvciBjaGFpbmluZw0KQWN0dWFsbHksIHdpdGggdGhlc2UgcXVlc3Rpb25z LCBJoa9tIHRyeWluZyB0byBmaWd1cmUgb3V0IHdoZW4gd2UgcHV0IGFueSBzZXJ2aWNlIChlLmcu IE5BVC9MQi9WUE4pIHdpdGggTDMgYWRkcmVzcyBpbiB0aGUgY2hhaW4sIGEpIGhvdyB0aGUgcG9z c2libGUgQVJQIHBhY2tldHMgYXJlIGhhbmRsZWQsIGIpIGhvdyB0aGUgcm91dGluZyB0YWJsZSBp cyBjb25maWd1cmVkIGZvciB0aGUgcm91dGVycyB3aGljaCBhcmUgbm90IGluIHRoZSBjaGFpbiwg YnV0IHRoZSB0cmFmZmljIGNvbWluZyBvdXQgb2YgdGhlIGNoYWluIHdpbGwgZ28gdGhydS4NClRo YW5rcywNCll1eGluDQq3orz+yMs6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSC0 +rHtIFpodWFuZ3l1eGluDQq3osvNyrG85DogMjAxNMTqMdTCMjfI1SAxMDozMg0KytW8/sjLOiBS b24gUGFya2VyOyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCtb3zOI6IFtzZmNd ILTwuLQ6IFNlcnZpY2VzIGVsaWdpYmxlIGZvciBjaGFpbmluZw0KSGksIFJvbiwNClRoYW5rcyBm b3IgdGhlIHJlcGx5Lg0KV2hlbiB3ZSBjb25zaWRlciBpbnNlcnRpbmcgTEIvTkFUIGluIHRoZSBj aGFpbiwgSSBoYXZlIHNvbWUgZnVydGhlciBxdWVzdGlvbnMgaGVyZS4NCi0gTGV0oa9zIHRha2Ug YSBjaGFpbiB3aXRoIE5BVCBzZXJ2aWNlIGZ1bmN0aW9uIGFzIGFuIGV4YW1wbGUsIHVzZXIgaXMg dXNpbmcgdGhpcyBjaGFpbiB0byBwcm9jZXNzIHRyYWZmaWMgcHJvZHVjZWQgYnkgVk0xIGFjY2Vz c2luZyBJbnRlcm5ldC4gSSBhc3N1bWUgdGhlIHRvcG9sb2d5IGlzIGxpa2UgdGhpczoNClZNMSAt LS0gKGNoYWluIGluY2x1ZGluZyBOQVQpIC0tLSBSb3V0ZXIgLS0tIEludGVybmV0DQpXaGVuIHRy YWZmaWMgZnJvbSBJbnRlcm5ldCBhcnJpdmVzIGF0IHRoZSByb3V0ZXIsIGl0cyBkZXN0SVAgcG9p bnRzIGF0IE5BVC4gSG93IGRvZXMgdGhlIHJvdXRlciBkZWNpZGUgdGhlIG5leHQgaG9wPw0KLSBB cyB0aGUgcGFja2V0IGlzIGRpcmVjdGx5IGFkZHJlc3NlZCB0byB0aGUgTkFULCBkb2VzIGl0IGNv bmZsaWN0IHdpdGggdGhlIKGudHJhbnNwYXJlbnQgbWlkYm94oa8gY29uY2VwdCBpbiBkcmFmdC1w YXJrZXItc2ZjLWNoYWluLXRvLXBhdGgtMDA/DQotIElzIGl0IHBvc3NpYmxlIGZvciB0aGUgUm91 dGVyIHRvIHNlbmQgb3V0IEFSUCB0byBxdWVyeSBmb3IgdGhlIElQIGFkZHJlc3Mgb24gTkFUPyBI b3cgZG9lcyBOQVQgcmVhY3QgdG8gQVJQIHJlcXVlc3QgZXNwZWNpYWxseSB3aGVuIE5BVCBpcyBT RkMtYXdhcmU/DQpUaGFua3MsDQpZdXhpbg0Kt6K8/sjLOiBSb24gUGFya2VyIFttYWlsdG86Um9u X1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbV0NCreiy83KsbzkOiAyMDE0xOox1MIyN8jVIDk6 MjkNCsrVvP7IyzogWmh1YW5neXV4aW47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3Jn Pg0K1vfM4jogUkU6IFNlcnZpY2VzIGVsaWdpYmxlIGZvciBjaGFpbmluZw0KWXV4aW4sDQpCb3Ro IGxvYWQgYmFsYW5jZXIgYW5kIE5BVCBhcmUgZGVmaW5pdGVseSBjYW5kaWRhdGVzIGZvciBTRkMg c2VydmljZSBmdW5jdGlvbnMuDQpSb24NCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgWmh1YW5neXV4aW4NClNlbnQ6IFN1bmRheSwgSmFudWFyeSAy NiwgMjAxNCA4OjA2IFBNDQpUbzogc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpT dWJqZWN0OiBbc2ZjXSBTZXJ2aWNlcyBlbGlnaWJsZSBmb3IgY2hhaW5pbmcNCkhlbGxvLCBGb2xr cywNCkZvciBTRkMsIGRvIHlvdSBoYXZlIGFueSBjb25jcmV0ZSBzZXJ2aWNlIGNhbmRpZGF0ZXMg d2hpY2ggYXJlIGVsaWdpYmxlIGZvciBjaGFpbmluZz8gSG93IGFib3V0IGxvYWQgYmFsYW5jZXIg YW5kIE5BVCwgd2hpY2ggdXN1YWxseSBjcm9zcyBzdWJuZXRzIGFuZCBjaGFuZ2UgcGFja2V0IGhl YWRlcj8gQXJlIHRoZXkgc3VpdGFibGUgZm9yIHRoZSBjaGFpbiB3ZSBhcmUgZGlzY3Vzc2luZyBo ZXJlPw0KVGhhbmtzLA0KWXV4aW4NCg== --_000_9EA32E60D7600C43B6FE22876DF564C81D8ACB1DSFO1EXCMBXP07nb_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Another example of the "bidirectional chain or= coordination of 2 unidirectional chains" scenario would be chaining Wan Optimization along with some inspection ser= vice such as IPS. Assuming that the segment between the two Wan Opt nodes (= Data Center and Branch) is transformed then you have the same scenario wher= e IPS has to be done on the untransformed flow. 

In the data center in the outbound direction (towards a remote site) I= PS needs to happen before Wan Opt while inbound into the DC, Wan Opt has to= be processed before IPS for the IPS to function correctly. 

Kevin

From: sfc [sfc-bounces@ietf.org] on behal= f of Ron Parker [Ron_Parker@affirmednetworks.com]
Sent: Tuesday, January 28, 2014 7:58 AM
To: mikebianc@aol.com; jun.lee@huawei.com; zhuangyuxin@huawei.com; s= fc@ietf.org; melinda.shore@gmail.com
Subject: Re: [sfc] =B4=F0=B8=B4: Services eligible for chaining

Typically, a source NAT= /NAPT performed from client to server wants to be reversed in the server to= client direction.   This is an excellent use case for a bidirectional chain or coordination of 2 unidirectional chains.  = ; It is often desirable to put the NAT function last in the client to serve= r direction and first in the server to client direction (although this is n= ot universally done).

 

Also, NAT is traditiona= lly coordinated with routing.   In the server to client direction= , the replacement IP addresses must get routed back to the service function that performed the NAT.    This could be achieved = in the traditional manner by assuming that the routing is handled outside o= f SFC.

 

Alternatively, the reve= rse flows could be handled by having the classifier arranged topologically = such that it sees all traffic arriving from the server side and determines that the relevant flows must go to the NAT service function= to be un-NAT=A1=AFd.    In the classifier approach, either = the classifier must be provisioned with filters that match the NAT replacem= ent IP addresses (i.e., coordinated configuration) or some dynamic mechanism must exist between the NAT service function and the= classifier such that dynamic policy rules can be installed.

 

IMO, NAT would be an ex= cellent candidate for one of those 3-5 use cases in our use case document.<= /span>

 

 

    Ron<= /span>

 

 

 

 

From: mike= bianc@aol.com [mailto:mikebianc@aol.com]
Sent: Tuesday, January 28, 2014 10:08 AM
To: jun.lee@huawei.com; zhuangyuxin@huawei.com; Ron Parker; sfc@ietf= .org; melinda.shore@gmail.com
Subject: RE: [sfc] =B4=F0=B8=B4: Services eligi= ble for chaining

 

NAT for sure needs to be in the SFC at l= east in the direction that performs the NAT because in that direction the p= acket dstIP is of the ultimate dst and not that of the NAT.  Typically, you will want your FW, etc to be in the chain before this= so the original packets can be inspected, but SFC should not require that = specifically.

 

In the op= posite direction, however, SFC is not required to direct the flow through t= he NAT because the dstIP takes care of that.  The same could be said for L3 LB because that's how we force traffic through the LB in a = non SFC world.  However, that shouldn't mean that we *can't* use SFC f= or these functions esp as its use might allow one to do things with flows t= hat were otherwise not possible.



From: jun.l= ee@huawei.com<jun.lee@huawei.com>
To: Zhuangyuxin<zhuangyuxin@huawei.com>,Zhuangyuxin<zhuangyuxin@huawei.com>,R= on Parker<Ron_Parker@affirmednetworks.com>,sfc@ietf.org<sfc@ietf.org>,Melinda Shore<meli= nda.shore@gmail.com>
Sent: Monday, January 27, 2014
Subject: [sfc] =B4=F0=B8=B4: Services eligible for chaining

Without SFC= , packets can already be forwarded to service functions with L3 address. In= this regard, service functions with L3 address are quite different to thos= e =A1=AEtransparent midbox=A1=AF.

So, I wonde= r why SFC should cover NAT and LB.

Regards

Li jun

=B7=A2=BC=FE=C8=CB: sfc [mai= lto:sfc-bounces@ietf.org] =B4=FA=B1=ED Zhuangyuxin
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C228=C8=D5 8:48
=CA=D5=BC=FE=C8=CB: Zhuangyuxin; Ron Parker; sfc@ietf.org; Melinda Shore
=D6=F7=CC=E2: [sfc] =B4=F0=B8=B4: Services eligible for chaining

Actually, w= ith these questions, I=A1=AFm trying to figure out when we put any service = (e.g. NAT/LB/VPN) with L3 address in the chain, a) how the possible ARP pac= kets are handled, b) how the routing table is configured for the routers which are not in the chain, but the traffic = coming out of the chain will go thru.

Thanks,

Yuxin

=B7=A2=BC=FE=C8=CB: sfc [mai= lto:sfc-bounces@ietf.org] =B4=FA=B1=ED Zhuangyuxin
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C227=C8=D5 10:32
=CA=D5=BC=FE=C8=CB: Ron Parker; s= fc@ietf.org=
=D6=F7=CC=E2: [sfc] =B4=F0=B8=B4: Services eligible for chaining

Hi, Ron,

Thanks for = the reply.

When we con= sider inserting LB/NAT in the chain, I have some further questions here.

- Let=A1=AF= s take a chain with NAT service function as an example, user is using this = chain to process traffic produced by VM1 accessing Internet. I assume the t= opology is like this:

VM1 --- (ch= ain including NAT) --- Router --- Internet

When traffic from Internet arrives at the router, its destIP points= at NAT. How does the router decide the next hop?

- As the packet is directly addressed to the NAT, does it conflict = with the =A1=AEtransparent midbox=A1=AF concept in draft-parker-sfc-chain-t= o-path-00?

- Is it possible for the Router to send out ARP to query for the IP= address on NAT? How does NAT react to ARP request especially when NAT is S= FC-aware?

Thanks,

Yuxin

=B7=A2=BC=FE=C8=CB: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C227=C8=D5 9:29
=CA=D5=BC=FE=C8=CB: Zhuangyuxin; = sfc@ietf.org
=D6=F7=CC=E2: RE: Services eligible for chaining

Yuxin,

Both load balancer and NAT are definitely candidates for SFC service= functions.

Ron

From:= sfc [ma= ilto:sfc-bounces@ietf.org] On Behalf Of Zhuangyuxin
Sent: Sunday, January 26, 2014 8:06 PM
To: sfc@ietf.org
Subject: [sfc] Services eligible for chaining

Hello, Folks,

For SFC, do you have any concrete service= candidates which are eligible for chaining? How about load balancer and NA= T, which usually cross subnets and change packet header? Are they suitable = for the chain we are discussing here?

Thanks,

Yuxin

--_000_9EA32E60D7600C43B6FE22876DF564C81D8ACB1DSFO1EXCMBXP07nb_-- From jguichar@cisco.com Tue Jan 28 09:51:47 2014 Return-Path: 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 E94641A0240 for ; Tue, 28 Jan 2014 09:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.085 X-Spam-Level: X-Spam-Status: No, score=-9.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 e0jD5Xc_2OBV for ; Tue, 28 Jan 2014 09:51:44 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id E62F81A0232 for ; Tue, 28 Jan 2014 09:51:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22717; q=dns/txt; s=iport; t=1390931501; x=1392141101; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Q0qXURnCFcQPQm5g5FeceUB9K01rFyeRVosKp/oFeys=; b=CroGeXUbLfV+anvUsC7ZrW+Lvldrs4Dc/a+Jvx1PbPfBt1BlnhktTsqI Vzlla7SeLMXK0FJoG1KXl4caRxRcxmnkFuebDoOhk3dL6adV0rKdxHXnV Wn471X3bd3/gpgwR98BjJ2Rc4UIdS0+gaiukU3R2YbJ6qjJhebED0IJ8F 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAF/t51KtJXHB/2dsb2JhbABagkhEgQ6CfaAghgKTPhh5FnSCJQEBAQRYDSQCAQYCEQMBAQEoBQICHxEUBgMIAgQBEodxAxGOIJtrCJc2DYgcF4xqgSlRChcBBIJngU0EljyBbIxehUGDLYFxOQ X-IronPort-AV: E=Sophos;i="4.95,737,1384300800"; d="scan'208,217";a="300264585" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 28 Jan 2014 17:51:40 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0SHpes7019055 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Jan 2014 17:51:40 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.207]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Tue, 28 Jan 2014 11:51:40 -0600 From: "Jim Guichard (jguichar)" To: "mikebianc@aol.com" , "jun.lee@huawei.com" , "zhuangyuxin@huawei.com" , "Ron_Parker@affirmednetworks.com" , "sfc@ietf.org" , "melinda.shore@gmail.com" Thread-Topic: =?gb2312?B?W3NmY10gtPC4tDogU2VydmljZXMgZWxpZ2libGUgZm9yIGNoYWluaW5n?= Thread-Index: AQHPHFGZEdVES40nC0qAh7j9vbuQBg== Date: Tue, 28 Jan 2014 17:51:40 +0000 Message-ID: References: <9C2DE4B8FE85984BA1B0581235F6B2ED0F633EAB@SZXEMA502-MBS.china.huawei.com> <9C2DE4B8FE85984BA1B0581235F6B2ED0F633F22@SZXEMA502-MBS.china.huawei.com> <9C2DE4B8FE85984BA1B0581235F6B2ED0F6350D1@SZXEMA502-MBS.china.huawei.com> <81126FE293D58240BD872F99F2606543368E3E75@szxema507-mbs.china.huawei.com> <1989047253.7723.1390921656400.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: <1989047253.7723.1390921656400.JavaMail.tomcat@mgs-aam01.mail.aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.43.183] Content-Type: multipart/alternative; boundary="_000_CF0D57C314AF2jguicharciscocom_" MIME-Version: 1.0 Subject: Re: [sfc] =?gb2312?b?tPC4tDogU2VydmljZXMgZWxpZ2libGUgZm9yIGNoYWluaW5n?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 17:51:48 -0000 --_000_CF0D57C314AF2jguicharciscocom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RnJhbmtseSBJIHRoaW5rIHRoZSBzaW1wbGUgcmVzcG9uc2UgdG8gdGhpcyBpcyB0aGF0IGlmICph bGwqIHlvdSB3YW50IHRvIGRvIGlzIE5BVCB0aGVuIHlvdSBkb26hr3QgbmVlZCBzZXJ2aWNlIGNo YWluaW5nOyB0aGUgZnVuZGFtZW50YWwgcG9pbnQgdGhlcmVmb3JlIHRvIHJlYWxpemUgaXMgdGhh dCBpZiB3ZSBhcmUgdXNpbmcgc2VydmljZSBjaGFpbmluZyB0aGVuIHByZXN1bWFibHkgTkFUIGlz IGp1c3Qgb25lIG9mIG11bHRpcGxlIGZ1bmN0aW9ucyB0aGF0IHdpbGwgYmUgYXBwbGllZCB0byB0 aGUgc2VsZWN0ZWQgdHJhZmZpYyBmbG93cy4gSW4gdGhpcyBjYXNlIFNGQyBpcyBuZWNlc3Nhcnkg dG8gb3ZlcmNvbWUgYWxsIG9mIHRoZSBpc3N1ZXMgYXMgbGFpZCBvdXQgaW4gdGhlIHByb2JsZW0g c3RhdGVtZW50Lg0KDQpGcm9tOiAibWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOm1pa2ViaWFuY0Bh b2wuY29tPiIgPG1pa2ViaWFuY0Bhb2wuY29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT4+DQpE YXRlOiBUdWVzZGF5LCBKYW51YXJ5IDI4LCAyMDE0IGF0IDEwOjA3IEFNDQpUbzogImp1bi5sZWVA aHVhd2VpLmNvbTxtYWlsdG86anVuLmxlZUBodWF3ZWkuY29tPiIgPGp1bi5sZWVAaHVhd2VpLmNv bTxtYWlsdG86anVuLmxlZUBodWF3ZWkuY29tPj4sICJ6aHVhbmd5dXhpbkBodWF3ZWkuY29tPG1h aWx0bzp6aHVhbmd5dXhpbkBodWF3ZWkuY29tPiIgPHpodWFuZ3l1eGluQGh1YXdlaS5jb208bWFp bHRvOnpodWFuZ3l1eGluQGh1YXdlaS5jb20+PiwgIlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jr cy5jb208bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+IiA8Um9uX1Bhcmtl ckBhZmZpcm1lZG5ldHdvcmtzLmNvbTxtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtz LmNvbT4+LCAic2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IiA8c2ZjQGlldGYub3Jn PG1haWx0bzpzZmNAaWV0Zi5vcmc+PiwgIm1lbGluZGEuc2hvcmVAZ21haWwuY29tPG1haWx0bzpt ZWxpbmRhLnNob3JlQGdtYWlsLmNvbT4iIDxtZWxpbmRhLnNob3JlQGdtYWlsLmNvbTxtYWlsdG86 bWVsaW5kYS5zaG9yZUBnbWFpbC5jb20+Pg0KU3ViamVjdDogUmU6IFtzZmNdILTwuLQ6IFNlcnZp Y2VzIGVsaWdpYmxlIGZvciBjaGFpbmluZw0KDQpOQVQgZm9yIHN1cmUgbmVlZHMgdG8gYmUgaW4g dGhlIFNGQyBhdCBsZWFzdCBpbiB0aGUgZGlyZWN0aW9uIHRoYXQgcGVyZm9ybXMgdGhlIE5BVCBi ZWNhdXNlIGluIHRoYXQgZGlyZWN0aW9uIHRoZSBwYWNrZXQgZHN0SVAgaXMgb2YgdGhlIHVsdGlt YXRlIGRzdCBhbmQgbm90IHRoYXQgb2YgdGhlIE5BVC4gIFR5cGljYWxseSwgeW91IHdpbGwgd2Fu dCB5b3VyIEZXLCBldGMgdG8gYmUgaW4gdGhlIGNoYWluIGJlZm9yZSB0aGlzIHNvIHRoZSBvcmln aW5hbCBwYWNrZXRzIGNhbiBiZSBpbnNwZWN0ZWQsIGJ1dCBTRkMgc2hvdWxkIG5vdCByZXF1aXJl IHRoYXQgc3BlY2lmaWNhbGx5Lg0KDQpJbiB0aGUgb3Bwb3NpdGUgZGlyZWN0aW9uLCBob3dldmVy LCBTRkMgaXMgbm90IHJlcXVpcmVkIHRvIGRpcmVjdCB0aGUgZmxvdyB0aHJvdWdoIHRoZSBOQVQg YmVjYXVzZSB0aGUgZHN0SVAgdGFrZXMgY2FyZSBvZiB0aGF0LiAgVGhlIHNhbWUgY291bGQgYmUg c2FpZCBmb3IgTDMgTEIgYmVjYXVzZSB0aGF0J3MgaG93IHdlIGZvcmNlIHRyYWZmaWMgdGhyb3Vn aCB0aGUgTEIgaW4gYSBub24gU0ZDIHdvcmxkLiAgSG93ZXZlciwgdGhhdCBzaG91bGRuJ3QgbWVh biB0aGF0IHdlICpjYW4ndCogdXNlIFNGQyBmb3IgdGhlc2UgZnVuY3Rpb25zIGVzcCBhcyBpdHMg dXNlIG1pZ2h0IGFsbG93IG9uZSB0byBkbyB0aGluZ3Mgd2l0aCBmbG93cyB0aGF0IHdlcmUgb3Ro ZXJ3aXNlIG5vdCBwb3NzaWJsZS4NCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KRnJvbToganVuLmxlZUBodWF3ZWkuY29tPG1haWx0bzpqdW4ubGVlQGh1YXdlaS5j b20+PGp1bi5sZWVAaHVhd2VpLmNvbTxtYWlsdG86anVuLmxlZUBodWF3ZWkuY29tPj4NClRvOiBa aHVhbmd5dXhpbjx6aHVhbmd5dXhpbkBodWF3ZWkuY29tPG1haWx0bzp6aHVhbmd5dXhpbkBodWF3 ZWkuY29tPj4sWmh1YW5neXV4aW48emh1YW5neXV4aW5AaHVhd2VpLmNvbTxtYWlsdG86emh1YW5n eXV4aW5AaHVhd2VpLmNvbT4+LFJvbiBQYXJrZXI8Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtz LmNvbTxtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4+LHNmY0BpZXRmLm9y ZzxtYWlsdG86c2ZjQGlldGYub3JnPjxzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4+ LE1lbGluZGEgU2hvcmU8bWVsaW5kYS5zaG9yZUBnbWFpbC5jb208bWFpbHRvOm1lbGluZGEuc2hv cmVAZ21haWwuY29tPj4NClNlbnQ6IE1vbmRheSwgSmFudWFyeSAyNywgMjAxNA0KU3ViamVjdDog W3NmY10gtPC4tDogU2VydmljZXMgZWxpZ2libGUgZm9yIGNoYWluaW5nDQoNCldpdGhvdXQgU0ZD LCBwYWNrZXRzIGNhbiBhbHJlYWR5IGJlIGZvcndhcmRlZCB0byBzZXJ2aWNlIGZ1bmN0aW9ucyB3 aXRoIEwzIGFkZHJlc3MuIEluIHRoaXMgcmVnYXJkLCBzZXJ2aWNlIGZ1bmN0aW9ucyB3aXRoIEwz IGFkZHJlc3MgYXJlIHF1aXRlIGRpZmZlcmVudCB0byB0aG9zZSChrnRyYW5zcGFyZW50IG1pZGJv eKGvLg0KU28sIEkgd29uZGVyIHdoeSBTRkMgc2hvdWxkIGNvdmVyIE5BVCBhbmQgTEIuDQpSZWdh cmRzDQpMaSBqdW4NCreivP7Iyzogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddILT6 se0gWmh1YW5neXV4aW4NCreiy83KsbzkOiAyMDE0xOox1MIyOMjVIDg6NDgNCsrVvP7IyzogWmh1 YW5neXV4aW47IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPjsg TWVsaW5kYSBTaG9yZQ0K1vfM4jogW3NmY10gtPC4tDogU2VydmljZXMgZWxpZ2libGUgZm9yIGNo YWluaW5nDQpBY3R1YWxseSwgd2l0aCB0aGVzZSBxdWVzdGlvbnMsIEmhr20gdHJ5aW5nIHRvIGZp Z3VyZSBvdXQgd2hlbiB3ZSBwdXQgYW55IHNlcnZpY2UgKGUuZy4gTkFUL0xCL1ZQTikgd2l0aCBM MyBhZGRyZXNzIGluIHRoZSBjaGFpbiwgYSkgaG93IHRoZSBwb3NzaWJsZSBBUlAgcGFja2V0cyBh cmUgaGFuZGxlZCwgYikgaG93IHRoZSByb3V0aW5nIHRhYmxlIGlzIGNvbmZpZ3VyZWQgZm9yIHRo ZSByb3V0ZXJzIHdoaWNoIGFyZSBub3QgaW4gdGhlIGNoYWluLCBidXQgdGhlIHRyYWZmaWMgY29t aW5nIG91dCBvZiB0aGUgY2hhaW4gd2lsbCBnbyB0aHJ1Lg0KVGhhbmtzLA0KWXV4aW4NCreivP7I yzogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gWmh1YW5neXV4aW4NCrei y83KsbzkOiAyMDE0xOox1MIyN8jVIDEwOjMyDQrK1bz+yMs6IFJvbiBQYXJrZXI7IHNmY0BpZXRm Lm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0K1vfM4jogW3NmY10gtPC4tDogU2VydmljZXMgZWxp Z2libGUgZm9yIGNoYWluaW5nDQpIaSwgUm9uLA0KVGhhbmtzIGZvciB0aGUgcmVwbHkuDQpXaGVu IHdlIGNvbnNpZGVyIGluc2VydGluZyBMQi9OQVQgaW4gdGhlIGNoYWluLCBJIGhhdmUgc29tZSBm dXJ0aGVyIHF1ZXN0aW9ucyBoZXJlLg0KLSBMZXShr3MgdGFrZSBhIGNoYWluIHdpdGggTkFUIHNl cnZpY2UgZnVuY3Rpb24gYXMgYW4gZXhhbXBsZSwgdXNlciBpcyB1c2luZyB0aGlzIGNoYWluIHRv IHByb2Nlc3MgdHJhZmZpYyBwcm9kdWNlZCBieSBWTTEgYWNjZXNzaW5nIEludGVybmV0LiBJIGFz c3VtZSB0aGUgdG9wb2xvZ3kgaXMgbGlrZSB0aGlzOg0KVk0xIC0tLSAoY2hhaW4gaW5jbHVkaW5n IE5BVCkgLS0tIFJvdXRlciAtLS0gSW50ZXJuZXQNCldoZW4gdHJhZmZpYyBmcm9tIEludGVybmV0 IGFycml2ZXMgYXQgdGhlIHJvdXRlciwgaXRzIGRlc3RJUCBwb2ludHMgYXQgTkFULiBIb3cgZG9l cyB0aGUgcm91dGVyIGRlY2lkZSB0aGUgbmV4dCBob3A/DQotIEFzIHRoZSBwYWNrZXQgaXMgZGly ZWN0bHkgYWRkcmVzc2VkIHRvIHRoZSBOQVQsIGRvZXMgaXQgY29uZmxpY3Qgd2l0aCB0aGUgoa50 cmFuc3BhcmVudCBtaWRib3ihryBjb25jZXB0IGluIGRyYWZ0LXBhcmtlci1zZmMtY2hhaW4tdG8t cGF0aC0wMD8NCi0gSXMgaXQgcG9zc2libGUgZm9yIHRoZSBSb3V0ZXIgdG8gc2VuZCBvdXQgQVJQ IHRvIHF1ZXJ5IGZvciB0aGUgSVAgYWRkcmVzcyBvbiBOQVQ/IEhvdyBkb2VzIE5BVCByZWFjdCB0 byBBUlAgcmVxdWVzdCBlc3BlY2lhbGx5IHdoZW4gTkFUIGlzIFNGQy1hd2FyZT8NClRoYW5rcywN Cll1eGluDQq3orz+yMs6IFJvbiBQYXJrZXIgW21haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0 d29ya3MuY29tXQ0Kt6LLzcqxvOQ6IDIwMTTE6jHUwjI3yNUgOToyOQ0KytW8/sjLOiBaaHVhbmd5 dXhpbjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQrW98ziOiBSRTogU2Vydmlj ZXMgZWxpZ2libGUgZm9yIGNoYWluaW5nDQpZdXhpbiwNCkJvdGggbG9hZCBiYWxhbmNlciBhbmQg TkFUIGFyZSBkZWZpbml0ZWx5IGNhbmRpZGF0ZXMgZm9yIFNGQyBzZXJ2aWNlIGZ1bmN0aW9ucy4N ClJvbg0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBaaHVhbmd5dXhpbg0KU2VudDogU3VuZGF5LCBKYW51YXJ5IDI2LCAyMDE0IDg6MDYgUE0NClRv OiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NClN1YmplY3Q6IFtzZmNdIFNlcnZp Y2VzIGVsaWdpYmxlIGZvciBjaGFpbmluZw0KSGVsbG8sIEZvbGtzLA0KRm9yIFNGQywgZG8geW91 IGhhdmUgYW55IGNvbmNyZXRlIHNlcnZpY2UgY2FuZGlkYXRlcyB3aGljaCBhcmUgZWxpZ2libGUg Zm9yIGNoYWluaW5nPyBIb3cgYWJvdXQgbG9hZCBiYWxhbmNlciBhbmQgTkFULCB3aGljaCB1c3Vh bGx5IGNyb3NzIHN1Ym5ldHMgYW5kIGNoYW5nZSBwYWNrZXQgaGVhZGVyPyBBcmUgdGhleSBzdWl0 YWJsZSBmb3IgdGhlIGNoYWluIHdlIGFyZSBkaXNjdXNzaW5nIGhlcmU/DQpUaGFua3MsDQpZdXhp bg0K --_000_CF0D57C314AF2jguicharciscocom_ Content-Type: text/html; charset="gb2312" Content-ID: <55AF2DB7B4183343AB9E0CC123DAE8E3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Frankly I think the simple response to this is that if *all* you want to do is NAT then you don=A1= =AFt need service chaining; the fundamental point therefore to realize is t= hat if we are using service chaining then presumably NAT is just one of multiple functions that will be applied to the selected= traffic flows. In this case SFC is necessary to overcome all of the issues= as laid out in the problem statement.


NAT for sure needs to be in the SFC at least in the direction that per= forms the NAT because in that direction the packet dstIP is of the ultimate= dst and not that of the NAT.  Typically, you will want your FW, etc t= o be in the chain before this so the original packets can be inspected, but SFC should not require that specifi= cally.

In the opposite direction, however, SFC is not required to direct the = flow through the NAT because the dstIP takes care of that.  The same c= ould be said for L3 LB because that's how we force traffic through the LB i= n a non SFC world.  However, that shouldn't mean that we *can't* use SFC for these functions esp as its use might allo= w one to do things with flows that were otherwise not possible.



From: jun.lee@huawei.com&l= t;jun.lee@huawei.com>
To: Zhuangyuxin<zhuangy= uxin@huawei.com>,Zhuangyuxin<zhuangyuxin@huawei.com>,Ron Parker<Ron_Parker@affirmednetworks.com>,sfc@ietf.org<sfc@ietf.org>,Melinda Shore<melinda.shore@gmail.co= m>
Sent: Monday, January 27, 2014
Subject: [sfc] =B4=F0=B8=B4: Services eligible for chaining

Without= SFC, packets can already be forwarded to service functions with L3 address= . In this regard, service functions with L3 address are quite different to = those =A1=AEtransparent midbo= x=A1=AF.

So, I w= onder why SFC should cover NAT and LB.

Regards=

Li jun<= o:p>

=B7=A2=BC=FE=C8=CB: sfc [mailto:sfc-bounces@ietf.org] =B4=FA= =B1=ED Zhuangyuxin
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C228=C8=D5 8:48
=CA=D5=BC=FE=C8=CB: Zhuangyuxin; Ron Parker; sfc@ietf.org; Melinda Shore
=D6=F7=CC=E2: [sfc] =B4=F0=B8=B4: Services eligible for cha= ining

Actuall= y, with these questions, I=A1=AFm trying to figure out when we put any serv= ice (e.g. NAT/LB/VPN) with L3 address in the chain, a) how the possible ARP= packets are handled, b) how the routing table is configured for the routers which are not in the chain, but the traffic = coming out of the chain will go thru.

Thanks,=

Yuxin

=B7=A2=BC=FE=C8=CB: sfc [mailto:sfc-bounces@ietf.org] =B4=FA= =B1=ED Zhuangyuxin
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C227=C8=D5 10:32
=CA=D5=BC=FE=C8=CB: Ron Parker; sfc@ietf.org
=D6=F7=CC=E2: [sfc] =B4=F0=B8=B4: Services eligible for cha= ining

Hi, Ron= ,

Thanks = for the reply.

When we= consider inserting LB/NAT in the chain, I have some further questions here= .

- Let= =A1=AFs take a chain with NAT service function as an example, user is using= this chain to process traffic produced by VM1 accessing Internet. I assume= the topology is like this:

VM1 ---= (chain including NAT) --- Router --- Internet

When traffic from Int= ernet arrives at the router, its destIP points at NAT. How does the router = decide the next hop?

- As the packet is di= rectly addressed to the NAT, does it conflict with the =A1=AEtransparent mi= dbox=A1=AF concept in draft-parker-sfc-chain-to-path-00?<= /p>

- Is it possible for = the Router to send out ARP to query for the IP address on NAT? How does NAT= react to ARP request especially when NAT is SFC-aware?

Thanks,=

Yuxin

=B7=A2=BC=FE=C8=CB: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA1=D4=C227=C8=D5 9:29
=CA=D5=BC=FE=C8=CB: Zhuangyuxin; sfc@ietf.org
=D6=F7=CC=E2: RE: Services eligible for chaining

Yuxin,

Both load balancer and NAT are definitely candidates for SFC serv= ice functions.

Ron

From: sfc [= mailto:sfc-bounces@ietf.org] On Behalf Of Zhuangyuxin
Sent: Sunday, January 26, 2014 8:06 PM
To: sfc@ietf.org
Subject: [sfc] Services eligible for chaining

Hello, Folks,=

For SFC, do you have any concre= te service candidates which are eligible for chaining? How about load balan= cer and NAT, which usually cross subnets and change packet header? Are they= suitable for the chain we are discussing here?

Thanks,

Yuxin

--_000_CF0D57C314AF2jguicharciscocom_-- From mikebianc@aol.com Tue Jan 28 10:16:20 2014 Return-Path: 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 B07B01A034E for ; Tue, 28 Jan 2014 10:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 n0UL5e8kRNp5 for ; Tue, 28 Jan 2014 10:16:19 -0800 (PST) Received: from omr-d03.mx.aol.com (omr-d03.mx.aol.com [205.188.109.200]) by ietfa.amsl.com (Postfix) with ESMTP id 28FB31A0346 for ; Tue, 28 Jan 2014 10:16:19 -0800 (PST) Received: from mtaout-mbb02.mx.aol.com (mtaout-mbb02.mx.aol.com [172.26.254.110]) by omr-d03.mx.aol.com (Outbound Mail Relay) with ESMTP id 57C10701CDD95; Tue, 28 Jan 2014 13:16:16 -0500 (EST) Received: from mgs-aaa01.mail.aol.com (mgs-aaa01.mail.aol.com [149.174.106.43]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-mbb02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 13444380000AC; Tue, 28 Jan 2014 13:16:16 -0500 (EST) Date: Tue, 28 Jan 2014 13:16:15 -0500 From: "mikebianc@aol.com" To: jguichar@cisco.com, jun.lee@huawei.com, zhuangyuxin@huawei.com, Ron_Parker@affirmednetworks.com, sfc@ietf.org, melinda.shore@gmail.com Message-ID: <114745883.8305.1390932975869.JavaMail.tomcat@mgs-aaa01.mail.aol.com> In-Reply-To: References: <9C2DE4B8FE85984BA1B0581235F6B2ED0F633EAB@SZXEMA502-MBS.china.huawei.com> <9C2DE4B8FE85984BA1B0581235F6B2ED0F633F22@SZXEMA502-MBS.china.huawei.com> <9C2DE4B8FE85984BA1B0581235F6B2ED0F6350D1@SZXEMA502-MBS.china.huawei.com> <81126FE293D58240BD872F99F2606543368E3E75@szxema507-mbs.china.huawei.com> <1989047253.7723.1390921656400.JavaMail.tomcat@mgs-aam01.mail.aol.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: 10.181.180.254, 64.12.75.136 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1390932976; bh=1vGccxc8ge2yxu7G3pRmzletC0qVGIcq6IJP5p2MIDg=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=iKrCvQxUYIDlZI/4KvgQfsx9eAuOl/MCT5G8VELtezf3sKtiuqBTU1ePoM+D8kY9K nG6NSRPS24FielO0CRZo5RMZGXrLqSaagfmxeFnVIVoS8BQKIgAhAnLZsVSn09xZEW jcELkAJyH8ivhAjbUYPrYjPI4ryoCEGcojfxfGTQ= x-aol-sid: 3039ac1afe6e52e7f3f05e12 X-AOL-IP: 149.174.106.43 Subject: Re: [sfc] =?utf-8?b?562U5aSNOiBTZXJ2aWNlcyBlbGlnaWJsZSBmb3IgY2hhaW5p?= =?utf-8?q?ng?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 18:16:20 -0000 Actually, even if all you want to do is NAT, but you don't want to have to put the NAT inline (e.g. you only want some of the traffic to be NATed but don't want to pay for links to support all of the traffic that has no need for the NAT service), SFC would be kind of ideal. That being said, what does it matter if the NAT is one of multiple functions in a chain or the sole function in the chain? Either way, it is a valid SF. From jguichar@cisco.com Tue Jan 28 10:18:46 2014 Return-Path: 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 6EE541A02E9 for ; Tue, 28 Jan 2014 10:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.536 X-Spam-Level: X-Spam-Status: No, score=-11.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 A6bhF6hcIFc2 for ; Tue, 28 Jan 2014 10:18:45 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFF11A0240 for ; Tue, 28 Jan 2014 10:18:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=736; q=dns/txt; s=iport; t=1390933122; x=1392142722; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=bAw4W4MKWhTZ4ly1OKAtauXLiQ7PfRo5kIn95dZ7nrc=; b=c86OFGlZk6ZcsYs2hImzkIJ4qUeC2OXqIMknVsSs44eXaU0LftVIk5Be fzOA0FaYuPQaOGi7uu+/ZWf5T42P8zrmounbIdVVsFfFgPMVtm5cCE+Sd H+zuSmtV5rJJGyrizHxb6seim7XALX5QZzYH6du//UuPDos4LZQrJmrwD w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFADzz51KtJV2Y/2dsb2JhbABagwyBDoJ9piOTPhh5FnSCJgEBBDRVAgEIHCgCAjAaCwIEARKHcQMRjiObZQ6fXheBIItKgWI6gmaBUgEDmCiSH4Mtgio X-IronPort-AV: E=Sophos;i="4.95,737,1384300800"; d="scan'208";a="300271291" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 28 Jan 2014 18:18:42 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0SIIgD9024309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Jan 2014 18:18:42 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.207]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 28 Jan 2014 12:18:42 -0600 From: "Jim Guichard (jguichar)" To: "mikebianc@aol.com" , "jun.lee@huawei.com" , "zhuangyuxin@huawei.com" , "Ron_Parker@affirmednetworks.com" , "sfc@ietf.org" , "melinda.shore@gmail.com" Thread-Topic: =?big5?B?W3NmY10gtarOYDogU2VydmljZXMgZWxpZ2libGUgZm9yIGNoYWluaW5n?= Thread-Index: AQHPHFGZEdVES40nC0qAh7j9vbuQBpqa1gKA//+s14A= Date: Tue, 28 Jan 2014 18:18:41 +0000 Message-ID: References: <9C2DE4B8FE85984BA1B0581235F6B2ED0F633EAB@SZXEMA502-MBS.china.huawei.com> <9C2DE4B8FE85984BA1B0581235F6B2ED0F633F22@SZXEMA502-MBS.china.huawei.com> <9C2DE4B8FE85984BA1B0581235F6B2ED0F6350D1@SZXEMA502-MBS.china.huawei.com> <81126FE293D58240BD872F99F2606543368E3E75@szxema507-mbs.china.huawei.com> <1989047253.7723.1390921656400.JavaMail.tomcat@mgs-aam01.mail.aol.com> <114745883.8305.1390932975869.JavaMail.tomcat@mgs-aaa01.mail.aol.com> In-Reply-To: <114745883.8305.1390932975869.JavaMail.tomcat@mgs-aaa01.mail.aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.43.183] Content-Type: text/plain; charset="big5" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [sfc] =?big5?b?tarOYDogU2VydmljZXMgZWxpZ2libGUgZm9yIGNoYWluaW5n?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 18:18:46 -0000 VHJ1ZSBlbm91Z2guDQoNCk9uIDEvMjgvMTQsIDE6MTYgUE0sICJtaWtlYmlhbmNAYW9sLmNvbSIg PG1pa2ViaWFuY0Bhb2wuY29tPiB3cm90ZToNCg0KPkFjdHVhbGx5LCBldmVuIGlmIGFsbCB5b3Ug d2FudCB0byBkbyBpcyBOQVQsIGJ1dCB5b3UgZG9uJ3Qgd2FudCB0byBoYXZlDQo+dG8gcHV0IHRo ZSBOQVQgaW5saW5lIChlLmcuIHlvdSBvbmx5IHdhbnQgc29tZSBvZiB0aGUgdHJhZmZpYyB0byBi ZSBOQVRlZA0KPmJ1dCBkb24ndCB3YW50IHRvIHBheSBmb3IgbGlua3MgdG8gc3VwcG9ydCBhbGwg b2YgdGhlIHRyYWZmaWMgdGhhdCBoYXMgbm8NCj5uZWVkIGZvciB0aGUgTkFUIHNlcnZpY2UpLCBT RkMgd291bGQgYmUga2luZCBvZiBpZGVhbC4NCj4NCj5UaGF0IGJlaW5nIHNhaWQsIHdoYXQgZG9l cyBpdCBtYXR0ZXIgaWYgdGhlIE5BVCBpcyBvbmUgb2YgbXVsdGlwbGUNCj5mdW5jdGlvbnMgaW4g YSBjaGFpbiBvciB0aGUgc29sZSBmdW5jdGlvbiBpbiB0aGUgY2hhaW4/ICBFaXRoZXIgd2F5LCBp dA0KPmlzIGEgdmFsaWQgU0YuDQoNCg== From ddolson@sandvine.com Tue Jan 28 10:35:27 2014 Return-Path: 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 7406D1A0368 for ; Tue, 28 Jan 2014 10:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.034 X-Spam-Level: X-Spam-Status: No, score=-1.034 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] 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 CxTNGTSy8i1E for ; Tue, 28 Jan 2014 10:35:25 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1911A0425 for ; Tue, 28 Jan 2014 10:35:08 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%16]) with mapi id 14.01.0339.001; Tue, 28 Jan 2014 13:35:05 -0500 From: Dave Dolson To: "sfc@ietf.org" Thread-Topic: SFC using VLANs Thread-Index: Ac8cV6lyHNqG7zyjQfCY48eCbUP0Cw== Date: Tue, 28 Jan 2014 18:35:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.52] Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9818A6990Ewtlexchp2sandvi_" MIME-Version: 1.0 Subject: [sfc] SFC using VLANs X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 18:35:27 -0000 --_000_E8355113905631478EFF04F5AA706E9818A6990Ewtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings, At Sandvine we have been deploying a form of Service Function Chaining (alb= eit under different nomenclature) for about 5 years now. Our Policy Traffic Switch (PTS) platform can initiate and terminate chains,= steering traffic to different chains based on a variety of traffic and sub= scriber conditions. The encapsulation is VLAN tagging, and the requirement on the SF node is to= transparently bridge an Ethernet trunk, forwarding or injecting traffic us= ing the same Ethernet addresses and VLAN tag. We have addressed issues of chain symmetry, health checking, failure, load = balancing and sending different chains through the same node. A benefit of this approach is that explicit chain configuration is not requ= ired in the SF node itself. An obvious con is the limited number of VLAN tags (no more than 4095), and = the complexity of the switch configuration may lower that further. If this group is interested, I could elaborate, including the details and p= ros/cons, either on this mailing list or in a draft. Any interest? David Dolson Senior Software Architect, Sandvine Inc. --_000_E8355113905631478EFF04F5AA706E9818A6990Ewtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings,

 

At Sandvine we have been deploying a form of Service= Function Chaining (albeit under different nomenclature) for about 5 years = now.

Our Policy Traffic Switch (PTS) platform can initiat= e and terminate chains, steering traffic to different chains based on a var= iety of traffic and subscriber conditions.

 

The encapsulation is VLAN tagging, and the requireme= nt on the SF node is to transparently bridge an Ethernet trunk, forwarding = or injecting traffic using the same Ethernet addresses and VLAN tag.

We have addressed issues of chain symmetry, health c= hecking, failure, load balancing and sending different chains through the s= ame node.

A benefit of this approach is that explicit chain co= nfiguration is not required in the SF node itself.

An obvious con is the limited number of VLAN tags (n= o more than 4095), and the complexity of the switch configuration may lower= that further.

 

If this group is interested, I could elaborate, incl= uding the details and pros/cons, either on this mailing list or in a draft.= Any interest?

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;          

 

David Dolson

Senior Software Architect, Sandvine Inc.<= /p>

 

--_000_E8355113905631478EFF04F5AA706E9818A6990Ewtlexchp2sandvi_-- From Ron_Parker@affirmednetworks.com Tue Jan 28 10:58:06 2014 Return-Path: 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 A6D951A0434 for ; Tue, 28 Jan 2014 10:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 PLeZfLdK58-x for ; Tue, 28 Jan 2014 10:58:04 -0800 (PST) Received: from hub021-ca-6.exch021.serverdata.net (hub021-ca-6.exch021.serverdata.net [64.78.56.71]) by ietfa.amsl.com (Postfix) with ESMTP id 8951C1A03B7 for ; Tue, 28 Jan 2014 10:58:04 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.03.0158.001; Tue, 28 Jan 2014 10:58:01 -0800 From: Ron Parker To: Dave Dolson , "sfc@ietf.org" Thread-Topic: SFC using VLANs Thread-Index: Ac8cV6lyHNqG7zyjQfCY48eCbUP0CwAAw6mQ Date: Tue, 28 Jan 2014 18:58:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A79A2F7MBX021W3CA2exch_" MIME-Version: 1.0 Subject: Re: [sfc] SFC using VLANs X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 18:58:06 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A79A2F7MBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Dave. I think the group could benefit greatly from your experiences. In particu= lar, the chain symmetry and load balancing aspects would be very interestin= g to me. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Tuesday, January 28, 2014 1:35 PM To: sfc@ietf.org Subject: [sfc] SFC using VLANs Greetings, At Sandvine we have been deploying a form of Service Function Chaining (alb= eit under different nomenclature) for about 5 years now. Our Policy Traffic Switch (PTS) platform can initiate and terminate chains,= steering traffic to different chains based on a variety of traffic and sub= scriber conditions. The encapsulation is VLAN tagging, and the requirement on the SF node is to= transparently bridge an Ethernet trunk, forwarding or injecting traffic us= ing the same Ethernet addresses and VLAN tag. We have addressed issues of chain symmetry, health checking, failure, load = balancing and sending different chains through the same node. A benefit of this approach is that explicit chain configuration is not requ= ired in the SF node itself. An obvious con is the limited number of VLAN tags (no more than 4095), and = the complexity of the switch configuration may lower that further. If this group is interested, I could elaborate, including the details and p= ros/cons, either on this mailing list or in a draft. Any interest? David Dolson Senior Software Architect, Sandvine Inc. --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A79A2F7MBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Dave.

 

I think the group coul= d benefit greatly from your experiences.   In particular, the cha= in symmetry and load balancing aspects would be very interesting to me.

 

   Ron<= /o:p>

 

 

From: sfc [mailto:sfc-bounces@ietf.org] On= Behalf Of Dave Dolson
Sent: Tuesday, January 28, 2014 1:35 PM
To: sfc@ietf.org
Subject: [sfc] SFC using VLANs

 

Greetings,

 

At Sandvine we have been deploying a form of Service= Function Chaining (albeit under different nomenclature) for about 5 years = now.

Our Policy Traffic Switch (PTS) platform can initiat= e and terminate chains, steering traffic to different chains based on a var= iety of traffic and subscriber conditions.

 

The encapsulation is VLAN tagging, and the requireme= nt on the SF node is to transparently bridge an Ethernet trunk, forwarding = or injecting traffic using the same Ethernet addresses and VLAN tag.

We have addressed issues of chain symmetry, health c= hecking, failure, load balancing and sending different chains through the s= ame node.

A benefit of this approach is that explicit chain co= nfiguration is not required in the SF node itself.

An obvious con is the limited number of VLAN tags (n= o more than 4095), and the complexity of the switch configuration may lower= that further.

 

If this group is interested, I could elaborate, incl= uding the details and pros/cons, either on this mailing list or in a draft.= Any interest?

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;          

 

David Dolson

Senior Software Architect, Sandvine Inc.<= /p>

 

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A79A2F7MBX021W3CA2exch_-- From jmh@joelhalpern.com Tue Jan 28 11:38:05 2014 Return-Path: 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 174C31A037F for ; Tue, 28 Jan 2014 11:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 hlMqglmusemf for ; Tue, 28 Jan 2014 11:38:03 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 4A01E1A037C for ; Tue, 28 Jan 2014 11:38:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id EA5F3562587; Tue, 28 Jan 2014 11:38:00 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-128.clppva.east.verizon.net [70.106.135.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 22B3C562583; Tue, 28 Jan 2014 11:37:59 -0800 (PST) Message-ID: <52E80716.2060406@joelhalpern.com> Date: Tue, 28 Jan 2014 14:37:58 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Jim Guichard (jguichar)" , "mikebianc@aol.com" , "jun.lee@huawei.com" , "zhuangyuxin@huawei.com" , "Ron_Parker@affirmednetworks.com" , "sfc@ietf.org" , "melinda.shore@gmail.com" References: <9C2DE4B8FE85984BA1B0581235F6B2ED0F633EAB@SZXEMA502-MBS.china.huawei.com> <9C2DE4B8FE85984BA1B0581235F6B2ED0F633F22@SZXEMA502-MBS.china.huawei.com> <9C2DE4B8FE85984BA1B0581235F6B2ED0F6350D1@SZXEMA502-MBS.china.huawei.com> <81126FE293D58240BD872F99F2606543368E3E75@szxema507-mbs.china.huawei.com> <1989047253.7723.1390921656400.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sfc] =?utf-8?b?562U5aSNOiBTZXJ2aWNlcyBlbGlnaWJsZSBmb3IgY2hhaW5p?= =?utf-8?q?ng?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 19:38:05 -0000 I agree with Jim. If you have only one service you want to insert, there are likely MUCH simpler solutions that the work this group is doing. If you are using NAT with other services, you need service chaining. There are multiple ways to include NAT in the chains (in each direction). Eventually, with a NAT function which preserve the metadata and transport headers, the inclusion should be very straightforward. Yours, Joel On 1/28/14, 12:51 PM, Jim Guichard (jguichar) wrote: > Frankly I think the simple response to this is that if *all* you want to > do is NAT then you don’t need service chaining; the fundamental point > therefore to realize is that if we are using service chaining then > presumably NAT is just one of multiple functions that will be applied to > the selected traffic flows. In this case SFC is necessary to overcome > all of the issues as laid out in the problem statement. > > From: "mikebianc@aol.com " > > Date: Tuesday, January 28, 2014 at 10:07 AM > To: "jun.lee@huawei.com " >, "zhuangyuxin@huawei.com > " >, "Ron_Parker@affirmednetworks.com > " > >, "sfc@ietf.org > " >, > "melinda.shore@gmail.com " > > > Subject: Re: [sfc] ç­”å¤: Services eligible for chaining > > NAT for sure needs to be in the SFC at least in the direction that > performs the NAT because in that direction the packet dstIP is of the > ultimate dst and not that of the NAT. Typically, you will want your FW, > etc to be in the chain before this so the original packets can be > inspected, but SFC should not require that specifically. > > In the opposite direction, however, SFC is not required to direct the > flow through the NAT because the dstIP takes care of that. The same > could be said for L3 LB because that's how we force traffic through the > LB in a non SFC world. However, that shouldn't mean that we *can't* use > SFC for these functions esp as its use might allow one to do things with > flows that were otherwise not possible. > > > > > > ------------------------------------------------------------------------ > *From: *jun.lee@huawei.com > > > *To: *Zhuangyuxin >,Zhuangyuxin >,Ron > Parker >,sfc@ietf.org > >,Melinda > Shore> > *Sent: *Monday, January 27, 2014 > *Subject: *[sfc] ç­”å¤: Services eligible for chaining > > Without SFC, packets can already be forwarded to service functions with > L3 address. In this regard, service functions with L3 address are quite > different to those ‘transparent midbox’. > > So, I wonder why SFC should cover NAT and LB. > > Regards > > Li jun > > *å‘件人:*sfc [mailto:sfc-bounces@ietf.org] *代表 *Zhuangyuxin > *å‘é€æ—¶é—´:*2014å¹´1月28æ—¥8:48 > *收件人:*Zhuangyuxin; Ron Parker; sfc@ietf.org ; > Melinda Shore > *主题:*[sfc] ç­”å¤: Services eligible for chaining > > Actually, with these questions, I’m trying to figure out when we put any > service (e.g. NAT/LB/VPN) with L3 address in the chain, a) how the > possible ARP packets are handled, b) how the routing table is configured > for the routers which are not in the chain, but the traffic coming out > of the chain will go thru. > > Thanks, > > Yuxin > > *å‘件人:*sfc [mailto:sfc-bounces@ietf.org] *代表 *Zhuangyuxin > *å‘é€æ—¶é—´:*2014å¹´1月27æ—¥10:32 > *收件人:*Ron Parker; sfc@ietf.org > *主题:*[sfc] ç­”å¤: Services eligible for chaining > > Hi, Ron, > > Thanks for the reply. > > When we consider inserting LB/NAT in the chain, I have some further > questions here. > > - Let’s take a chain with NAT service function as an example, user is > using this chain to process traffic produced by VM1 accessing Internet. > I assume the topology is like this: > > VM1 --- (chain including NAT) --- Router --- Internet > > When traffic from Internet arrives at the router, its destIP points at > NAT. How does the router decide the next hop? > > - As the packet is directly addressed to the NAT, does it conflict with > the ‘transparent midbox’ concept in draft-parker-sfc-chain-to-path-00? > > - Is it possible for the Router to send out ARP to query for the IP > address on NAT? How does NAT react to ARP request especially when NAT is > SFC-aware? > > Thanks, > > Yuxin > > *å‘件人:*Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > *å‘é€æ—¶é—´:*2014å¹´1月27æ—¥9:29 > *收件人:*Zhuangyuxin; sfc@ietf.org > *主题:*RE: Services eligible for chaining > > Yuxin, > > Both load balancer and NAT are definitely candidates for SFC service > functions. > > Ron > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Zhuangyuxin > *Sent:* Sunday, January 26, 2014 8:06 PM > *To:* sfc@ietf.org > *Subject:* [sfc] Services eligible for chaining > > Hello, Folks, > > For SFC, do you have any concrete service candidates which are eligible > for chaining? How about load balancer and NAT, which usually cross > subnets and change packet header? Are they suitable for the chain we are > discussing here? > > Thanks, > > Yuxin > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From jguichar@cisco.com Tue Jan 28 12:09:45 2014 Return-Path: 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 2076C1A045F for ; Tue, 28 Jan 2014 12:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 LY-EkDaRZI05 for ; Tue, 28 Jan 2014 12:09:42 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADBC1A0477 for ; Tue, 28 Jan 2014 12:09:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1300; q=dns/txt; s=iport; t=1390939762; x=1392149362; h=from:to:subject:date:message-id:mime-version; bh=FsaAfIOTj7ihZ2eDzk73GVNKDU5XriAJA/qAq+HXKgo=; b=KL+krez2HIn7xXFHYoqz3b5tLaTOJGyDEVN353weji7O+HIok7YfBJTL PTE9svwCdzTt0LQhcjZIG3ORPflaqVUGlTAzktbGXODj8kLOjwURFCazl Skx2c38k0kFaUEfjDeku7JaOLpmHQ3unkyL/99QXxOtJEcBop/LBqFxyK M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8FALAN6FKtJV2b/2dsb2JhbABagkhEOFa9fBZ0ghwQSSUdAQsBdCcEHId8DZsKrm8Xkz4EmCiSH4Mtgio X-IronPort-AV: E=Sophos;i="4.95,737,1384300800"; d="scan'208,217";a="16188602" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP; 28 Jan 2014 20:09:21 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0SK9LBI009926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 28 Jan 2014 20:09:21 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.207]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Tue, 28 Jan 2014 14:09:21 -0600 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: IETF Note Well Guidelines Thread-Index: AQHPHGTUkxp2e+3CC0mRT0BlqvrCSA== Date: Tue, 28 Jan 2014 20:09:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.43.183] Content-Type: multipart/alternative; boundary="_000_CF0D789E14B58jguicharciscocom_" MIME-Version: 1.0 Subject: [sfc] IETF Note Well Guidelines X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 20:09:45 -0000 --_000_CF0D789E14B58jguicharciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As we move forward with the work within the SFC WG, the chairs as a reminde= r would like the WG to be aware of the IETF Note Well guidelines which gove= rn the mailing list and all WG correspondence. For more information, go her= e: www.ietf.org/about/note-well-html. Jim & Thomas --_000_CF0D789E14B58jguicharciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
As we move forward with the work within the SFC WG, the chairs as a re= minder would like the WG to be aware of the IETF Note Well guidelines which= govern the mailing list and all WG correspondence. For more information, g= o here: www.ietf.org/about/note-well-html.

Jim & Thomas
--_000_CF0D789E14B58jguicharciscocom_-- From S.Majee@f5.com Tue Jan 28 13:50:11 2014 Return-Path: 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 E66751A0056 for ; Tue, 28 Jan 2014 13:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.435 X-Spam-Level: X-Spam-Status: No, score=-7.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, 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 egswTnLdCm8r for ; Tue, 28 Jan 2014 13:50:09 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id E35881A03A0 for ; Tue, 28 Jan 2014 13:50:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,738,1384300800"; d="scan'208,217";a="99537246" X-IPAS-Result: ArkEANEl6FLAqArr/2dsb2JhbABagkh8Vrx4gSl0giUBAgEDLUEdAQgNAQMDAQIoORQJCgQBEhvRVBeOJ0eEUASfGI5cgWhC Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 28 Jan 2014 21:49:27 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by seaecas02.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Tue, 28 Jan 2014 13:49:26 -0800 From: Sumandra Majee To: Dave Dolson , "sfc@ietf.org" Thread-Topic: [sfc] SFC using VLANs Thread-Index: AQHPHHLPjZtq+A541EijV0WIX1OVrQ== Date: Tue, 28 Jan 2014 21:49:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [192.168.16.250] Content-Type: multipart/alternative; boundary="_000_CF0D60C117F6Asmajeef5com_" MIME-Version: 1.0 Subject: Re: [sfc] SFC using VLANs X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 21:50:12 -0000 --_000_CF0D60C117F6Asmajeef5com_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes it would be interesting. There are other solution which also build a dy= namic chain based of service characteristic. VLAN tag is the most obvious = choice but is it not possible to use other encapsulation technology like GR= E perhaps? From: Dave Dolson > Date: Tuesday, January 28, 2014 at 10:35 AM To: "sfc@ietf.org" > Subject: [sfc] SFC using VLANs Greetings, At Sandvine we have been deploying a form of Service Function Chaining (alb= eit under different nomenclature) for about 5 years now. Our Policy Traffic Switch (PTS) platform can initiate and terminate chains,= steering traffic to different chains based on a variety of traffic and sub= scriber conditions. The encapsulation is VLAN tagging, and the requirement on the SF node is to= transparently bridge an Ethernet trunk, forwarding or injecting traffic us= ing the same Ethernet addresses and VLAN tag. We have addressed issues of chain symmetry, health checking, failure, load = balancing and sending different chains through the same node. A benefit of this approach is that explicit chain configuration is not requ= ired in the SF node itself. An obvious con is the limited number of VLAN tags (no more than 4095), and = the complexity of the switch configuration may lower that further. If this group is interested, I could elaborate, including the details and p= ros/cons, either on this mailing list or in a draft. Any interest? David Dolson Senior Software Architect, Sandvine Inc. --_000_CF0D60C117F6Asmajeef5com_ Content-Type: text/html; charset="us-ascii" Content-ID: <1EA0B25CBD50CE47895E2A5F4230CF2F@F5.com> Content-Transfer-Encoding: quoted-printable
Yes it would be interesting. There are other solution which also build= a dynamic chain based of service characteristic.  VLAN tag is the mos= t obvious choice but is it not possible to use other encapsulation technolo= gy like GRE perhaps?  

From: Dave Dolson <ddolson@sandvine.com>
Date: Tuesday, January 28, 2014 at = 10:35 AM
To: "sfc@ietf.org" <sfc@ietf.= org>
Subject: [sfc] SFC using VLANs

Greetings,

 

At Sandvine we have been deploying a form of Service= Function Chaining (albeit under different nomenclature) for about 5 years = now.

Our Policy Traffic Switch (PTS) platform can initiat= e and terminate chains, steering traffic to different chains based on a var= iety of traffic and subscriber conditions.

 

The encapsulation is VLAN tagging, and the requireme= nt on the SF node is to transparently bridge an Ethernet trunk, forwarding = or injecting traffic using the same Ethernet addresses and VLAN tag.

We have addressed issues of chain symmetry, health c= hecking, failure, load balancing and sending different chains through the s= ame node.

A benefit of this approach is that explicit chain co= nfiguration is not required in the SF node itself.

An obvious con is the limited number of VLAN tags (n= o more than 4095), and the complexity of the switch configuration may lower= that further.

 

If this group is interested, I could elaborate, incl= uding the details and pros/cons, either on this mailing list or in a draft.= Any interest?

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;          

 

David Dolson

Senior Software Architect, Sandvine Inc.<= /p>

 

 --_000_CF0D60C117F6Asmajeef5com_-- From mikebianc@aol.com Tue Jan 28 14:27:43 2014 Return-Path: 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 3DBE61A02ED for ; Tue, 28 Jan 2014 14:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 QvY30ZXf4ZLm for ; Tue, 28 Jan 2014 14:27:40 -0800 (PST) Received: from omr-m09.mx.aol.com (omr-m09.mx.aol.com [64.12.143.82]) by ietfa.amsl.com (Postfix) with ESMTP id A36021A0069 for ; Tue, 28 Jan 2014 14:27:40 -0800 (PST) Received: from mtaout-mbe01.mx.aol.com (mtaout-mbe01.mx.aol.com [172.26.254.173]) by omr-m09.mx.aol.com (Outbound Mail Relay) with ESMTP id B77EC701BA859; Tue, 28 Jan 2014 17:27:37 -0500 (EST) Received: from mgs-aam01.mail.aol.com (mgs-aam01.mail.aol.com [64.12.250.54]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-mbe01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 8A22538000083; Tue, 28 Jan 2014 17:27:37 -0500 (EST) Date: Tue, 28 Jan 2014 17:27:37 -0500 From: "mikebianc@aol.com" To: S.Majee@F5.com, ddolson@sandvine.com, sfc@ietf.org Message-ID: <1636122887.9122.1390948057480.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9121_1991058863.1390948057479" X-Originating-IP: 10.181.180.254, 64.12.75.136 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1390948057; bh=ikR0QsFci8r6QIz2J28iZmrGCDEkzdT63XOTy/lPzaA=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=EgUJUFtNTpD7K6anowO39iyTKI9Py1FlMMztaQRLZ4Vbugv+Wpyb9L7gZLTORGOKt FBnih9KEVBPpyWvsJCnsKOHKiM+Iq+cYXo3SZjLYjM7r/gN5cXMn82KX1CWr9qvVIa nt7lWVvFphKiLFUB2Qe8BU6Y+yZSXzh1PhU4YF8c= x-aol-sid: 3039ac1afead52e82ed907ef X-AOL-IP: 64.12.250.54 Subject: Re: [sfc] SFC using VLANs X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 22:27:43 -0000 ------=_Part_9121_1991058863.1390948057479 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable There are a number of ways to do this without SFC. =C2=A0You could create y= our chain using DSCP markings and use OF in the underlay to forward traffic= with markings set (defaulting to standard IP networking if not set). =C2= =A0Many router vendors support a form of Policy Based Routing (aka filter b= ased forwarding) that can be used code in the chains per flow. =C2=A0You co= uld even run an overlay like VXLAN or Contrail or Nuage that support a chai= ning-like feature. =C2=A0And, yes, you could build a GRE encapsulation over= lay as well. =C2=A0 My hope is for SFC to provide a standard, simplified method of doing this. I'm definitely interested to hear more about David's specific implementatio= n, problems worked around, and features still not possible to implement wit= h the current configuration. From: S.Majee@F5.com To: Dave Dolson,sfc@ietf.org Sent: Tuesday, January 28, 2014 Subject: Re: [sfc] SFC using VLANs Yes it would be interesting. There are other solution which also build a dy= namic chain based of service characteristic. VLAN tag is the most obvious = choice but is it not possible to use other encapsulation technology like GR= E perhaps? =20 From: Dave Dolson Date: Tuesday, January 28, 2014 at 10:35 AM To: "sfc@ietf.org" Subject: [sfc] SFC using VLANs Greetings, =20 At Sandvine we have been deploying a form of Service Function Chaining (alb= eit under different nomenclature) for about 5 years now. Our Policy Traffic Switch (PTS) platform can initiate and terminate chains,= steering traffic to different chains based on a variety of traffic and sub= scriber conditions. =20 The encapsulation is VLAN tagging, and the requirement on the SF node is to= transparently bridge an Ethernet trunk, forwarding or injecting traffic us= ing the same Ethernet addresses and VLAN tag. We have addressed issues of chain symmetry, health checking, failure, load = balancing and sending different chains through the same node. A benefit of this approach is that explicit chain configuration is not requ= ired in the SF node itself. An obvious con is the limited number of VLAN tags (no more than 4095), and = the complexity of the switch configuration may lower that further. =20 If this group is interested, I could elaborate, including the details and p= ros/cons, either on this mailing list or in a draft. Any interest? = =20 =20 David Dolson Senior Software Architect, Sandvine Inc. =20 ------=_Part_9121_1991058863.1390948057479 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
There are a num= ber of ways to do this without SFC.  You could create your chain using= DSCP markings and use OF in the underlay to forward traffic with markings = set (defaulting to standard IP networking if not set).  Many router ve= ndors support a form of Policy Based Routing (aka filter based forwarding) = that can be used code in the chains per flow.  You could even run an o= verlay like VXLAN or Contrail or Nuage that support a chaining-like feature= .  And, yes, you could build a GRE encapsulation overlay as well. &nbs= p;

My hope is for SFC to provide a standard, simpl= ified method of doing this.

I'm definitely interes= ted to hear more about David's specific implementation, problems worked aro= und, and features still not possible to implement with the current configur= ation.



From: S.Majee@F5.com<S.Majee@F5.com>
To: Dave Dolson&l= t;ddolson@sandvine.com>,sfc@ietf.org<sfc@ietf.org>
Sent: Tuesday, January 28, 2014
Subject: Re: [sfc] SFC using VLANs
=
Yes it would be interesting. There are other solution which also build= a dynamic chain based of service characteristic. VLAN tag is the most obv= ious choice but is it not possible to use other encapsulation technology li= ke GRE perhaps?

From: Dave Dolson <ddolson@sandvine.com>
Date: Tuesday, January 28, 2014 at = 10:35 AM
To: "sfc@ietf.org" <sfc@ietf.org>= ;
Subject: [sfc] SFC using VLANs

Greetings,

At Sandvine we have been deploying a form of Service= Function Chaining (albeit under different nomenclature) for about 5 years = now.

Our Policy Traffic Switch (PTS) platform can initiat= e and terminate chains, steering traffic to different chains based on a var= iety of traffic and subscriber conditions.

The encapsulation is VLAN tagging, and the requireme= nt on the SF node is to transparently bridge an Ethernet trunk, forwarding = or injecting traffic using the same Ethernet addresses and VLAN tag.

We have addressed issues of chain symmetry, health c= hecking, failure, load balancing and sending different chains through the s= ame node.

A benefit of this approach is that explicit chain co= nfiguration is not required in the SF node itself.

An obvious con is the limited number of VLAN tags (n= o more than 4095), and the complexity of the switch configuration may lower= that further.

If this group is interested, I could elaborate, incl= uding the details and pros/cons, either on this mailing list or in a draft.= Any interest?

= = =20

David Dolson

Senior Software Architect, Sandvine Inc.<= /p>

------=_Part_9121_1991058863.1390948057479-- From jenapper@cisco.com Tue Jan 28 14:40:42 2014 Return-Path: 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 8030A1A03EB for ; Tue, 28 Jan 2014 14:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 s4AhFLA6kqVK for ; Tue, 28 Jan 2014 14:40:40 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id BA52B1A035A for ; Tue, 28 Jan 2014 14:40:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2831; q=dns/txt; s=iport; t=1390948838; x=1392158438; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=5DhFLpu0y+3UxtIByuHOzb9pKw5Ais+QbX8nI0j9ktY=; b=aNEXhdAvVmTiQbD6l02YC5N1vSBBV2fkaDQOeVL/93nA4RnwUKR4Fcb7 xFbKv22b1n63jWiOWSjNtDWZZ/uyQcIAv4ZJbs0GX02PouH5P0NWPtx0W POuAe4m0CO15wTrcCODUcj/lx1zMpxc4EqTI8Fc6UTZK9pj6tZijw5vmQ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFABUx6FKtJXHB/2dsb2JhbABagww4Vrx6gRMWdIIlAQEBBDotEAIMBAIBCBEDAQIfEDIbAQEFAwIEDgUJh3wNyWoXjn8HBoQyBJgogTKQbYMtgio X-IronPort-AV: E=Sophos;i="4.95,738,1384300800"; d="scan'208";a="16226628" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-3.cisco.com with ESMTP; 28 Jan 2014 22:40:37 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0SMeb6t004506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Jan 2014 22:40:37 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.217]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Tue, 28 Jan 2014 16:40:37 -0600 From: "Jeffrey Napper (jenapper)" To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPHHf70f5aYymi3U6ZFMlHO+OqR5qbMFQA Date: Tue, 28 Jan 2014 22:40:37 +0000 Message-ID: References: <20140128222615.27147.51166.idtracker@ietfa.amsl.com> In-Reply-To: <20140128222615.27147.51166.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.104.28] Content-Type: text/plain; charset="us-ascii" Content-ID: <5C4DB65260870D42A6BD76A0D7D2B2AC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Walter Haeffner Subject: [sfc] FW: New Version Notification for draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 22:40:42 -0000 Howdy, This draft is meant to be specifically for requirements and use cases related to 3GPP mobility, which is one of the specific areas mentioned in the recent discussion of the progression of use case documents. We have included background and discussion of weaknesses of current approaches w.r.t. mobility. Looking forward to your comments, Jeff -----Original Message----- From: "internet-drafts@ietf.org" Date: Tuesday, January 28, 2014 at 11:26 PM To: Jeffrey Napper , Walter Haeffner , Walter Haeffner , Jeffrey Napper Subject: New Version Notification for draft-haeffner-sfc-use-case-mobility-00.txt > >A new version of I-D, draft-haeffner-sfc-use-case-mobility-00.txt >has been successfully submitted by Jeffrey Napper and posted to the >IETF repository. > >Name: draft-haeffner-sfc-use-case-mobility >Revision: 00 >Title: Service Function Chaining Use Cases in Mobile Networks >Document date: 2014-01-29 >Group: Individual Submission >Pages: 17 >URL: =20 >http://www.ietf.org/internet-drafts/draft-haeffner-sfc-use-case-mobility-0 >0.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ >Htmlized: =20 >http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 > > >Abstract: > This document provides some exemplary use cases for service function > chaining in mobile service provider networks. The objective of this > draft is not to cover all conceivable service chains in detail. > Rather, the intention is to localize and explain the application > domain of service chaining within mobile networks as far as it is > required to complement the problem statement and framework statements > of the working group. > > Service function chains typically reside in a LAN segment which links > the mobile access network to the actual application platforms located > in the carrier's datacenters or somewhere else in the Internet. > Service function chains ensure a fair distribution of network > resources according to agreed service policies, enhance the > performance of service delivery, take care of security and privacy or > support application and business support platforms. General > considerations and specific use cases are presented in this document > to demonstrate the different technical requirements of these goals > for service function chaining in mobile service provider networks. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > From leaf.yeh.sdo@gmail.com Tue Jan 28 18:13:38 2014 Return-Path: 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 963A21A02B2 for ; Tue, 28 Jan 2014 18:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 UQ37wBJEEt9Z for ; Tue, 28 Jan 2014 18:13:36 -0800 (PST) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id B2CC61A0282 for ; Tue, 28 Jan 2014 18:13:36 -0800 (PST) Received: by mail-pb0-f53.google.com with SMTP id md12so1128125pbc.26 for ; Tue, 28 Jan 2014 18:13:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=zdVD/SSQ4t7mivowi47dqmpJn1/WGiMnMCsxVljAt+o=; b=U5h/38U1LNDV1s/P2WyS0WXDhyVm05JIJ2VrW2Kvq7SchGIYy4WjGn8x+c6/waYdvF 4EmCR8gXTwgL1aKtNB0GY70zA8up02JUKVVygl8x1yA4ItDgeNALdCaoQt6yuRr6uZMm ql+zOgShnNsF4H0lRfc5pQy1OS311b7Kg25EZJUXgeBBE659F2/3DDs2/mMUnACyhVNI MDbDHY0SSuV/2bl8v5IQDS7zbk+JZUFoatqJ0ArWD68Oi2MUoC3G99xuhEynkuD7+1Wm vXquFyM3m12Jicc/lqfDJWQ+L6VO2EGwiq+wINq+2zLKbOhB1xPo2w+hux7ZTeDS5Z+Y hBsA== X-Received: by 10.68.40.138 with SMTP id x10mr5193131pbk.8.1390961614008; Tue, 28 Jan 2014 18:13:34 -0800 (PST) Received: from PC ([218.241.103.137]) by mx.google.com with ESMTPSA id pe3sm1358430pbc.23.2014.01.28.18.13.32 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 28 Jan 2014 18:13:33 -0800 (PST) From: "Leaf Yeh" To: "'Jim Guichard \(jguichar\)'" , References: In-Reply-To: Date: Wed, 29 Jan 2014 10:13:28 +0800 Message-ID: <52e863cd.43da440a.61cf.4611@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0097_01CF1CDA.C3EFBAB0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPHGTUkxp2e+3CC0mRT0BlqvrCSJqa9Eww Content-Language: zh-cn Subject: Re: [sfc] IETF Note Well Guidelines X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 02:13:38 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0097_01CF1CDA.C3EFBAB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit FYI - http://www.ietf.org/about/note-well.html Best Regards, Leaf From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Wednesday, January 29, 2014 4:09 AM To: sfc@ietf.org Subject: [sfc] IETF Note Well Guidelines As we move forward with the work within the SFC WG, the chairs as a reminder would like the WG to be aware of the IETF Note Well guidelines which govern the mailing list and all WG correspondence. For more information, go here: www.ietf.org/about/note-well-html. Jim & Thomas ------=_NextPart_000_0097_01CF1CDA.C3EFBAB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI - http://www.ietf.org/abo= ut/note-well.html

 

 

Best Regards,

Leaf

 

 

 

From:= sfc = [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard = (jguichar)
Sent: Wednesday, January 29, 2014 4:09 = AM
To: sfc@ietf.org
Subject: [sfc] IETF Note Well = Guidelines

 

As we move forward with the work within the SFC WG, the chairs as a = reminder would like the WG to be aware of the IETF Note Well guidelines = which govern the mailing list and all WG correspondence. For more = information, go here: www.ietf.org/about/note= -well-html.

 

Jim & Thomas

------=_NextPart_000_0097_01CF1CDA.C3EFBAB0-- From haibin.song@huawei.com Tue Jan 28 19:44:45 2014 Return-Path: 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 E5CB51A0366 for ; Tue, 28 Jan 2014 19:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 CBAchLz5HJDf for ; Tue, 28 Jan 2014 19:44:43 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 31D251A0236 for ; Tue, 28 Jan 2014 19:44:42 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAN86865; Wed, 29 Jan 2014 03:44:39 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 29 Jan 2014 03:44:19 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 29 Jan 2014 03:44:37 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Wed, 29 Jan 2014 11:44:33 +0800 From: "Songhaibin (A)" To: "mikebianc@aol.com" , "S.Majee@F5.com" , "ddolson@sandvine.com" , "sfc@ietf.org" Thread-Topic: [sfc] SFC using VLANs Thread-Index: AQHPHHLPjZtq+A541EijV0WIX1OVrZqaMUmAgADee9A= Date: Wed, 29 Jan 2014 03:44:32 +0000 Message-ID: References: <1636122887.9122.1390948057480.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: <1636122887.9122.1390948057480.JavaMail.tomcat@mgs-aam01.mail.aol.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.70] Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F24829E95nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [sfc] SFC using VLANs X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 03:44:46 -0000 --_000_E33E01DFD5BEA24B9F3F18671078951F24829E95nkgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V291bGQgbGlrZSB0byBoZWFyIG1vcmUgYWJvdXQgRGF2aWTigJlzIGltcGxlbWVudGF0aW9uIHRv by4NCg0KQmVzdCBSZWdhcmRzIQ0KLUhhaWJpbg0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIG1pa2ViaWFuY0Bhb2wuY29tDQpTZW50OiBXZWRu ZXNkYXksIEphbnVhcnkgMjksIDIwMTQgNjoyOCBBTQ0KVG86IFMuTWFqZWVARjUuY29tOyBkZG9s c29uQHNhbmR2aW5lLmNvbTsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NmY10gU0ZDIHVz aW5nIFZMQU5zDQoNClRoZXJlIGFyZSBhIG51bWJlciBvZiB3YXlzIHRvIGRvIHRoaXMgd2l0aG91 dCBTRkMuICBZb3UgY291bGQgY3JlYXRlIHlvdXIgY2hhaW4gdXNpbmcgRFNDUCBtYXJraW5ncyBh bmQgdXNlIE9GIGluIHRoZSB1bmRlcmxheSB0byBmb3J3YXJkIHRyYWZmaWMgd2l0aCBtYXJraW5n cyBzZXQgKGRlZmF1bHRpbmcgdG8gc3RhbmRhcmQgSVAgbmV0d29ya2luZyBpZiBub3Qgc2V0KS4g IE1hbnkgcm91dGVyIHZlbmRvcnMgc3VwcG9ydCBhIGZvcm0gb2YgUG9saWN5IEJhc2VkIFJvdXRp bmcgKGFrYSBmaWx0ZXIgYmFzZWQgZm9yd2FyZGluZykgdGhhdCBjYW4gYmUgdXNlZCBjb2RlIGlu IHRoZSBjaGFpbnMgcGVyIGZsb3cuICBZb3UgY291bGQgZXZlbiBydW4gYW4gb3ZlcmxheSBsaWtl IFZYTEFOIG9yIENvbnRyYWlsIG9yIE51YWdlIHRoYXQgc3VwcG9ydCBhIGNoYWluaW5nLWxpa2Ug ZmVhdHVyZS4gIEFuZCwgeWVzLCB5b3UgY291bGQgYnVpbGQgYSBHUkUgZW5jYXBzdWxhdGlvbiBv dmVybGF5IGFzIHdlbGwuDQoNCk15IGhvcGUgaXMgZm9yIFNGQyB0byBwcm92aWRlIGEgc3RhbmRh cmQsIHNpbXBsaWZpZWQgbWV0aG9kIG9mIGRvaW5nIHRoaXMuDQoNCkknbSBkZWZpbml0ZWx5IGlu dGVyZXN0ZWQgdG8gaGVhciBtb3JlIGFib3V0IERhdmlkJ3Mgc3BlY2lmaWMgaW1wbGVtZW50YXRp b24sIHByb2JsZW1zIHdvcmtlZCBhcm91bmQsIGFuZCBmZWF0dXJlcyBzdGlsbCBub3QgcG9zc2li bGUgdG8gaW1wbGVtZW50IHdpdGggdGhlIGN1cnJlbnQgY29uZmlndXJhdGlvbi4NCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogUy5NYWplZUBGNS5jb208Uy5NYWpl ZUBGNS5jb208bWFpbHRvOlMuTWFqZWVARjUuY29tJTNjUy5NYWplZUBGNS5jb20+Pg0KVG86IERh dmUgRG9sc29uPGRkb2xzb25Ac2FuZHZpbmUuY29tPG1haWx0bzpkZG9sc29uQHNhbmR2aW5lLmNv bT4+LHNmY0BpZXRmLm9yZzxzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQpTZW50 OiBUdWVzZGF5LCBKYW51YXJ5IDI4LCAyMDE0DQpTdWJqZWN0OiBSZTogW3NmY10gU0ZDIHVzaW5n IFZMQU5zDQpZZXMgaXQgd291bGQgYmUgaW50ZXJlc3RpbmcuIFRoZXJlIGFyZSBvdGhlciBzb2x1 dGlvbiB3aGljaCBhbHNvIGJ1aWxkIGEgZHluYW1pYyBjaGFpbiBiYXNlZCBvZiBzZXJ2aWNlIGNo YXJhY3RlcmlzdGljLiBWTEFOIHRhZyBpcyB0aGUgbW9zdCBvYnZpb3VzIGNob2ljZSBidXQgaXMg aXQgbm90IHBvc3NpYmxlIHRvIHVzZSBvdGhlciBlbmNhcHN1bGF0aW9uIHRlY2hub2xvZ3kgbGlr ZSBHUkUgcGVyaGFwcz8NCg0KRnJvbTogRGF2ZSBEb2xzb24gPGRkb2xzb25Ac2FuZHZpbmUuY29t PG1haWx0bzpkZG9sc29uQHNhbmR2aW5lLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBKYW51YXJ5IDI4 LCAyMDE0IGF0IDEwOjM1IEFNDQpUbzogInNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3Jn PiIgPHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPj4NClN1YmplY3Q6IFtzZmNdIFNG QyB1c2luZyBWTEFOcw0KDQpHcmVldGluZ3MsDQpBdCBTYW5kdmluZSB3ZSBoYXZlIGJlZW4gZGVw bG95aW5nIGEgZm9ybSBvZiBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIChhbGJlaXQgdW5kZXIg ZGlmZmVyZW50IG5vbWVuY2xhdHVyZSkgZm9yIGFib3V0IDUgeWVhcnMgbm93Lg0KT3VyIFBvbGlj eSBUcmFmZmljIFN3aXRjaCAoUFRTKSBwbGF0Zm9ybSBjYW4gaW5pdGlhdGUgYW5kIHRlcm1pbmF0 ZSBjaGFpbnMsIHN0ZWVyaW5nIHRyYWZmaWMgdG8gZGlmZmVyZW50IGNoYWlucyBiYXNlZCBvbiBh IHZhcmlldHkgb2YgdHJhZmZpYyBhbmQgc3Vic2NyaWJlciBjb25kaXRpb25zLg0KVGhlIGVuY2Fw c3VsYXRpb24gaXMgVkxBTiB0YWdnaW5nLCBhbmQgdGhlIHJlcXVpcmVtZW50IG9uIHRoZSBTRiBu b2RlIGlzIHRvIHRyYW5zcGFyZW50bHkgYnJpZGdlIGFuIEV0aGVybmV0IHRydW5rLCBmb3J3YXJk aW5nIG9yIGluamVjdGluZyB0cmFmZmljIHVzaW5nIHRoZSBzYW1lIEV0aGVybmV0IGFkZHJlc3Nl cyBhbmQgVkxBTiB0YWcuDQpXZSBoYXZlIGFkZHJlc3NlZCBpc3N1ZXMgb2YgY2hhaW4gc3ltbWV0 cnksIGhlYWx0aCBjaGVja2luZywgZmFpbHVyZSwgbG9hZCBiYWxhbmNpbmcgYW5kIHNlbmRpbmcg ZGlmZmVyZW50IGNoYWlucyB0aHJvdWdoIHRoZSBzYW1lIG5vZGUuDQpBIGJlbmVmaXQgb2YgdGhp cyBhcHByb2FjaCBpcyB0aGF0IGV4cGxpY2l0IGNoYWluIGNvbmZpZ3VyYXRpb24gaXMgbm90IHJl cXVpcmVkIGluIHRoZSBTRiBub2RlIGl0c2VsZi4NCkFuIG9idmlvdXMgY29uIGlzIHRoZSBsaW1p dGVkIG51bWJlciBvZiBWTEFOIHRhZ3MgKG5vIG1vcmUgdGhhbiA0MDk1KSwgYW5kIHRoZSBjb21w bGV4aXR5IG9mIHRoZSBzd2l0Y2ggY29uZmlndXJhdGlvbiBtYXkgbG93ZXIgdGhhdCBmdXJ0aGVy Lg0KSWYgdGhpcyBncm91cCBpcyBpbnRlcmVzdGVkLCBJIGNvdWxkIGVsYWJvcmF0ZSwgaW5jbHVk aW5nIHRoZSBkZXRhaWxzIGFuZCBwcm9zL2NvbnMsIGVpdGhlciBvbiB0aGlzIG1haWxpbmcgbGlz dCBvciBpbiBhIGRyYWZ0LiBBbnkgaW50ZXJlc3Q/DQpEYXZpZCBEb2xzb24NClNlbmlvciBTb2Z0 d2FyZSBBcmNoaXRlY3QsIFNhbmR2aW5lIEluYy4NCg== --_000_E33E01DFD5BEA24B9F3F18671078951F24829E95nkgeml501mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNl dGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IuaJueazqOah huaWh+acrCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkNoYXINCgl7bXNvLXN0eWxl LW5hbWU6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms65om55rOo5qGG5paH5pysOw0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQg NzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldvdWxk IGxpa2UgdG8gaGVhciBtb3JlIGFib3V0IERhdmlk4oCZcyBpbXBsZW1lbnRhdGlvbiB0b28uDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1 c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXN0IFJlZ2FyZHMhPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVz dGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1IYWliaW48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPm1pa2ViaWFuY0Bhb2wuY29tPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwg SmFudWFyeSAyOSwgMjAxNCA2OjI4IEFNPGJyPg0KPGI+VG86PC9iPiBTLk1hamVlQEY1LmNvbTsg ZGRvbHNvbkBzYW5kdmluZS5jb207IHNmY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW3NmY10gU0ZDIHVzaW5nIFZMQU5zPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoZXJlIGFyZSBhIG51bWJlciBvZiB3YXlz IHRvIGRvIHRoaXMgd2l0aG91dCBTRkMuICZuYnNwO1lvdSBjb3VsZCBjcmVhdGUgeW91ciBjaGFp biB1c2luZyBEU0NQIG1hcmtpbmdzIGFuZCB1c2UgT0YgaW4gdGhlIHVuZGVybGF5IHRvIGZvcndh cmQgdHJhZmZpYyB3aXRoIG1hcmtpbmdzDQogc2V0IChkZWZhdWx0aW5nIHRvIHN0YW5kYXJkIElQ IG5ldHdvcmtpbmcgaWYgbm90IHNldCkuICZuYnNwO01hbnkgcm91dGVyIHZlbmRvcnMgc3VwcG9y dCBhIGZvcm0gb2YgUG9saWN5IEJhc2VkIFJvdXRpbmcgKGFrYSBmaWx0ZXIgYmFzZWQgZm9yd2Fy ZGluZykgdGhhdCBjYW4gYmUgdXNlZCBjb2RlIGluIHRoZSBjaGFpbnMgcGVyIGZsb3cuICZuYnNw O1lvdSBjb3VsZCBldmVuIHJ1biBhbiBvdmVybGF5IGxpa2UgVlhMQU4gb3IgQ29udHJhaWwgb3Ig TnVhZ2UgdGhhdA0KIHN1cHBvcnQgYSBjaGFpbmluZy1saWtlIGZlYXR1cmUuICZuYnNwO0FuZCwg eWVzLCB5b3UgY291bGQgYnVpbGQgYSBHUkUgZW5jYXBzdWxhdGlvbiBvdmVybGF5IGFzIHdlbGwu ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TXkgaG9wZSBpcyBmb3Ig U0ZDIHRvIHByb3ZpZGUgYSBzdGFuZGFyZCwgc2ltcGxpZmllZCBtZXRob2Qgb2YgZG9pbmcgdGhp cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkknbSBkZWZpbml0ZWx5IGludGVy ZXN0ZWQgdG8gaGVhciBtb3JlIGFib3V0IERhdmlkJ3Mgc3BlY2lmaWMgaW1wbGVtZW50YXRpb24s IHByb2JsZW1zIHdvcmtlZCBhcm91bmQsIGFuZCBmZWF0dXJlcyBzdGlsbCBub3QgcG9zc2libGUg dG8gaW1wbGVtZW50IHdpdGggdGhlIGN1cnJlbnQNCiBjb25maWd1cmF0aW9uLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbi1ib3R0b206 Ni43NXB0O3RleHQtYWxpZ246Y2VudGVyIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj4NCjxociBzaXpl PSIxIiB3aWR0aD0iMTAwJSIgbm9zaGFkZT0iIiBzdHlsZT0iY29sb3I6Izk5OTk5OSIgYWxpZ249 ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOiA8L3NwYW4+DQo8 L2I+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Im1haWx0bzpTLk1hamVlQEY1LmNvbSUzY1Mu TWFqZWVARjUuY29tIj5TLk1hamVlQEY1LmNvbSZsdDtTLk1hamVlQEY1LmNvbTwvYT4mZ3Q7PGJy Pg0KPGI+VG86IDwvYj5EYXZlIERvbHNvbiZsdDs8YSBocmVmPSJtYWlsdG86ZGRvbHNvbkBzYW5k dmluZS5jb20iPmRkb2xzb25Ac2FuZHZpbmUuY29tPC9hPiZndDssc2ZjQGlldGYub3JnJmx0Ozxh IGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+ U2VudDogPC9iPlR1ZXNkYXksIEphbnVhcnkgMjgsIDIwMTQ8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+ UmU6IFtzZmNdIFNGQyB1c2luZyBWTEFOczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo2Ljc1cHQiPjxzcGFuIGxh bmc9IkVOLVVTIj5ZZXMgaXQgd291bGQgYmUgaW50ZXJlc3RpbmcuIFRoZXJlIGFyZSBvdGhlciBz b2x1dGlvbiB3aGljaCBhbHNvIGJ1aWxkIGEgZHluYW1pYyBjaGFpbiBiYXNlZCBvZiBzZXJ2aWNl IGNoYXJhY3RlcmlzdGljLiBWTEFOIHRhZyBpcyB0aGUgbW9zdCBvYnZpb3VzIGNob2ljZSBidXQg aXMgaXQgbm90IHBvc3NpYmxlIHRvIHVzZSBvdGhlcg0KIGVuY2Fwc3VsYXRpb24gdGVjaG5vbG9n eSBsaWtlIEdSRSBwZXJoYXBzPyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo2Ljc1cHQiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjYuNzVwdCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RGF2ZSBEb2xzb24gJmx0OzxhIGhyZWY9Im1h aWx0bzpkZG9sc29uQHNhbmR2aW5lLmNvbSI+ZGRvbHNvbkBzYW5kdmluZS5jb208L2E+Jmd0Ozxi cj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBKYW51YXJ5IDI4LCAyMDE0IGF0IDEwOjM1IEFNPGJy Pg0KPGI+VG86IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0 Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bc2ZjXSBTRkMgdXNpbmcgVkxBTnM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo2Ljc1cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkdyZWV0aW5ncyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5B dCBTYW5kdmluZSB3ZSBoYXZlIGJlZW4gZGVwbG95aW5nIGEgZm9ybSBvZiBTZXJ2aWNlIEZ1bmN0 aW9uIENoYWluaW5nIChhbGJlaXQgdW5kZXIgZGlmZmVyZW50IG5vbWVuY2xhdHVyZSkgZm9yIGFi b3V0IDUgeWVhcnMgbm93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPk91ciBQb2xpY3kgVHJhZmZpYyBTd2l0Y2ggKFBUUykg cGxhdGZvcm0gY2FuIGluaXRpYXRlIGFuZCB0ZXJtaW5hdGUgY2hhaW5zLCBzdGVlcmluZyB0cmFm ZmljIHRvIGRpZmZlcmVudCBjaGFpbnMgYmFzZWQgb24gYSB2YXJpZXR5IG9mIHRyYWZmaWMgYW5k IHN1YnNjcmliZXINCiBjb25kaXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBlbmNhcHN1bGF0aW9uIGlzIFZM QU4gdGFnZ2luZywgYW5kIHRoZSByZXF1aXJlbWVudCBvbiB0aGUgU0Ygbm9kZSBpcyB0byB0cmFu c3BhcmVudGx5IGJyaWRnZSBhbiBFdGhlcm5ldCB0cnVuaywgZm9yd2FyZGluZyBvciBpbmplY3Rp bmcgdHJhZmZpYyB1c2luZyB0aGUNCiBzYW1lIEV0aGVybmV0IGFkZHJlc3NlcyBhbmQgVkxBTiB0 YWcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+V2UgaGF2ZSBhZGRyZXNzZWQgaXNzdWVzIG9mIGNoYWluIHN5bW1ldHJ5LCBo ZWFsdGggY2hlY2tpbmcsIGZhaWx1cmUsIGxvYWQgYmFsYW5jaW5nIGFuZCBzZW5kaW5nIGRpZmZl cmVudCBjaGFpbnMgdGhyb3VnaCB0aGUgc2FtZSBub2RlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkEgYmVuZWZpdCBvZiB0 aGlzIGFwcHJvYWNoIGlzIHRoYXQgZXhwbGljaXQgY2hhaW4gY29uZmlndXJhdGlvbiBpcyBub3Qg cmVxdWlyZWQgaW4gdGhlIFNGIG5vZGUgaXRzZWxmLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkFuIG9idmlvdXMgY29uIGlz IHRoZSBsaW1pdGVkIG51bWJlciBvZiBWTEFOIHRhZ3MgKG5vIG1vcmUgdGhhbiA0MDk1KSwgYW5k IHRoZSBjb21wbGV4aXR5IG9mIHRoZSBzd2l0Y2ggY29uZmlndXJhdGlvbiBtYXkgbG93ZXIgdGhh dCBmdXJ0aGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPklmIHRoaXMgZ3JvdXAgaXMgaW50ZXJlc3RlZCwgSSBjb3VsZCBl bGFib3JhdGUsIGluY2x1ZGluZyB0aGUgZGV0YWlscyBhbmQgcHJvcy9jb25zLCBlaXRoZXIgb24g dGhpcyBtYWlsaW5nIGxpc3Qgb3IgaW4gYSBkcmFmdC4gQW55IGludGVyZXN0PzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkRh dmlkIERvbHNvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPlNlbmlvciBTb2Z0d2FyZSBBcmNoaXRlY3QsIFNhbmR2aW5lIElu Yy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E33E01DFD5BEA24B9F3F18671078951F24829E95nkgeml501mbschi_-- From jguichar@cisco.com Wed Jan 29 05:51:22 2014 Return-Path: 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 1C9BB1A02EA for ; Wed, 29 Jan 2014 05:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 88KouV0Hz1Eo for ; Wed, 29 Jan 2014 05:51:21 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id F0ECA1A02C8 for ; Wed, 29 Jan 2014 05:51:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1645; q=dns/txt; s=iport; t=1391003478; x=1392213078; h=from:to:cc:subject:date:message-id:mime-version; bh=SAmAoZkOeXiLLjCMaSIVoRlZ5f3obhJ7ZiVdA/rn3rU=; b=hVdVDelHqORsPz4WuIeQcsKo/Cio07NuAimr6jLelwf7HAoJ3JezrXVF hB2yRrxe0ENzWdR0vX5trrO4Yx0SH4EcGdaAA/DMBdw1NKPhruh7Hox4D aXGcU3maSPwlDOm9A6UM+/u/6fMGaafTXNAVMg+qSQXRH1O93/GgJ4U3U I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAAIH6VKtJXHA/2dsb2JhbABZgkhEgQ68foEGFnSCHBB5EgELAXQnBA6ICsoAF45/hD8EmCiSH4Mtgio X-IronPort-AV: E=Sophos;i="4.95,742,1384300800"; d="scan'208,217";a="300274945" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 29 Jan 2014 13:51:18 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0TDpIch027979 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Jan 2014 13:51:18 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.207]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Wed, 29 Jan 2014 07:51:17 -0600 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: Working adoption of draft-quinn-sfc-problem-statement-02 Thread-Index: AQHPHPkuFnHOq5hgxk+K8FBRv5s7VA== Date: Wed, 29 Jan 2014 13:51:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.43.183] Content-Type: multipart/alternative; boundary="_000_CF0E718214BCCjguicharciscocom_" MIME-Version: 1.0 Cc: Thomas Nadeau , "Paul Quinn \(paulq\)" Subject: [sfc] Working 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 13:51:22 -0000 --_000_CF0E718214BCCjguicharciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings, We have received good support for the adoption of draft-quinn-sfc-problem-s= tatement-02 as a working group draft. Authors, please post a new version as= draft-ietf-sfc-problem-statement-00. During the poll for adoption we asked the authors to confirm that they had = disclosed all related IPR. We received a positive response from all. Many thanks, Jim & Thomas --_000_CF0E718214BCCjguicharciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <47D5EE2659075F41B7C86A0E8B0E180E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Greetings,

We have received good support for the adoption of draft-quinn-sfc-prob= lem-statement-02 as a working group draft. Authors, please post a new versi= on as draft-ietf-sfc-problem-statement-00. 

During the poll for adoption we asked the authors to confirm that they= had disclosed all related IPR. We received a positive response from all.&n= bsp;

Many thanks,

Jim & Thomas


--_000_CF0E718214BCCjguicharciscocom_-- From jguichar@cisco.com Wed Jan 29 06:16:12 2014 Return-Path: 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 09B0D1A03A7 for ; Wed, 29 Jan 2014 06:16:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 EwiDeCH_hVdV for ; Wed, 29 Jan 2014 06:16:09 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 19DB71A037D for ; Wed, 29 Jan 2014 06:16:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20822; q=dns/txt; s=iport; t=1391004966; x=1392214566; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=woqqcCm/P46vseoL8gOqV8Yz/c4mqpc+ZcJ/uP/o9lQ=; b=WvyXu7JSrFC8fSPUHO3+3I/58L2LSgp6rgBDYtErh99/NIin8Il/fIWe n1tToLwe1BSq7KazgN1bAO3F9r/pMYWyanzULMgPziLw6Yat3JeT5qLIk gMQO+r0fVftLQ8Q2VMt2iHZMRqXdpPAFNOnYzgXvnOntIaI2EZk3DL397 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8GAAEM6VKtJXHB/2dsb2JhbABZgkhEOFapcoo4iFSBBxZ0giUBAQEELVwCAQgRAwECKAcyFAkIAgQBEhQHh2oNyWwXjh0RAT8XAYQ4BJgogTKQbYMtgXE5 X-IronPort-AV: E=Sophos;i="4.95,742,1384300800"; d="scan'208,217";a="297473644" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 29 Jan 2014 14:16:05 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0TEG5m7001939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Jan 2014 14:16:05 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.207]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Wed, 29 Jan 2014 08:16:05 -0600 From: "Jim Guichard (jguichar)" To: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Thread-Topic: [sfc] Progression of use case documents within the SFC working group Thread-Index: AQHPHPyldZjNgVZ0CEKUURS3OROEYQ== Date: Wed, 29 Jan 2014 14:16:04 +0000 Message-ID: References: <94C682931C08B048B7A8645303FDC9F36F473607AF@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36F47360A1B@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F47360A1B@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.43.183] Content-Type: multipart/alternative; boundary="_000_CF0E76ED14BDCjguicharciscocom_" MIME-Version: 1.0 Subject: Re: [sfc] Progression of use case documents within the SFC working group X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 14:16:12 -0000 --_000_CF0E76ED14BDCjguicharciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Med. Could you work with the authors of draft-liu-sfc-use-cases and the editors = of draft-ietf-sfc-problem-statement (once published; see recent email) to f= acilitate this change? From: "mohamed.boucadair@orange.com" <= mohamed.boucadair@orange.com> Date: Monday, January 27, 2014 at 8:28 AM To: Jim Guichard >, "sfc@ietf= .org" > Subject: RE: [sfc] Progression of use case documents within the SFC working= group Re-, I meant to adopt =93draft-liu-sfc-use-cases=94 as the use-case document. dr= aft-liu-service-chaining-use-cases was replaced by draft-liu-sfc-use-cases. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de mohamed.boucadair@oran= ge.com Envoy=E9 : lundi 27 janvier 2014 07:51 =C0 : Jim Guichard (jguichar); sfc@ietf.org Objet : Re: [sfc] Progression of use case documents within the SFC working = group Hi Jim, all, I support the adoption of draft-liu-service-chaining-use-cases as a place t= o record some the use cases already discussed in this list. As I=92m the author of the "3GPP Gi Interface Service Function Chaining=94 = section of the PS document, I=92m fine to remove that text from the PS and = merge it with the text of draft-liu-service-chaining-use-cases. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard (jguichar= ) Envoy=E9 : vendredi 24 janvier 2014 19:01 =C0 : sfc@ietf.org Objet : [sfc] Progression of use case documents within the SFC working grou= p Greetings, The documentation and applicability of use cases for the SFC WG was discuss= ed during both the Berlin and Vancouver BOFs. The main purpose of those dis= cussions was to show support for our work and subsequent formation of a wor= king group. As we move forward with our work we would like to solicit opinions of how b= est to approach use cases within the WG. The SFC charter left it open as to= whether we should have a single problem statement that includes use cases = or whether to separate out the use cases. Some background: 1) An important purpose for having use cases is to connect a problem or sol= ution to a real concrete scenario. On the problem side, a use case can high= light requirements for any solution. Hence, having SFC use cases is importa= nt. Lack of use cases could lead to missed requirements. 2) Having just one use case is probably not enough, but having too many qui= ckly leads to diminishing returns. The sweet spot is a relatively small num= ber (3? 4?) that are different enough that they flesh out the (different) k= ey requirements. We know that more use cases aren't helping when they simpl= y reaffirm requirements that have already been made apparent by other use c= ases. 3) Some use cases may be detailed and complicated , i.e., because the scena= rio or technology involved is complicated. Or they may be oriented towards = a particular community. Such use cases may warrant having their own standa= lone document. 4) If we try to put all use cases into a single document, we run the risk t= hat folk will continue to ask that additional scenarios be added, making it= difficult to close out and finish the document. With that in mind, the WG needs to make some choices. We propose: 1) Have the WG develop one use case document that documents a small number = of representative use cases. The document presented by Hongyu Li at the Va= ncouver BOF could serve for this purpose (http://datatracker.ietf.org/doc/d= raft-liu-service-chaining-use-cases). 2) Remove "Section 4. Service Function Chaining Use Cases=94 from draft-qu= inn-sfc-problem-statement. At present, one section is TBD, and the other s= ection "3GPP Gi Interface Service Function Chaining=94 would need significa= nt expansion, and that expansion probably makes more sense in a separate do= cument. If there was a simple use case that could be explained (to an IETF = reader) in 1-2 pages, we could consider putting it here, but we'd need a pr= oposal. (Any takers?) 3) For additional use cases not covered in 1) above, allow for a small numb= er of documents that are applicable to specific environments (e.g. mobilit= y, data center, broadband, and so forth.) These documents would provide mor= e detailed information and applicability of SFC to these specific environme= nts, and would need to go beyond what is covered in the general use case do= cument (1). Note that it is not the intention to have every potential use c= ase documented. Comments? Does the above approach seem reasonable to folks on the list? Any= objections? Jim & Thomas --_000_CF0E76ED14BDCjguicharciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <17530FC7DB5752479530220DE617EED7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Thanks Med.

Could you work with the authors of draft-liu-sfc-use-cases and the edi= tors of draft-ietf-sfc-problem-statement (once published; see recent email)= to facilitate this change?

From: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com&g= t;
Date: Monday, January 27, 2014 at 8= :28 AM
To: Jim Guichard <jguichar@cisco.com>, "sfc@ietf.org" <s= fc@ietf.org>
Subject: RE: [sfc] Progression of u= se case documents within the SFC working group

Re-,

 

I meant to adopt =93draft-liu-sfc-use-ca= ses=94 as the use-case document. draft-liu-service-chaining-use-cases was r= eplaced by draft-liu-sfc-use-cases.

 

Cheers,

Med

 

De : sfc [mailto:sfc-bounces@ietf.org] De la part de mohame= d.boucadair@orange.com
Envoy=E9 : lundi 27 janvier 2014 07:51
=C0 : Jim Guichard (jguichar); = sfc@ietf.org
Objet : Re: [sfc] Progression of use case documents within the = SFC working group

 

Hi Jim, all,

 

I support the adoption of draft-liu-servi= ce-chaining-use-cases as a place to record some the use cases already discu= ssed in this list.

 

As I=92m the author of the "3GPP Gi = Interface Service Function Chaining=94 section of the PS document, I=92m fi= ne to remove that text from the PS and merge it with the text of draft-liu-service-chaining-use-cases.

 

Cheers,

Med

 

De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard (jguichar)
Envoy=E9 : vendredi 24 janvier 2014 19:01
=C0 : sfc@ietf.org
Objet : [sfc] Progression of use case documents within the SFC = working group

 

Greetings,

 

The documentation and applicability of use c= ases for the SFC WG was discussed during both the Berlin and Vancouver BOFs= . The main purpose of those discussions was to show support for our work and subsequent formation of a working gro= up.

 

As we move forward with our work we would li= ke to solicit opinions of how best to approach use cases within the WG. The= SFC charter left it open as to whether we should have a single problem statement that includes use cases or wheth= er to separate out the use cases.

 

Some background:

 

1) An important purpose for having use cases= is to connect a problem or solution to a real concrete scenario. On the pr= oblem side, a use case can highlight requirements for any solution. Hence, having SFC use cases is important. L= ack of use cases could lead to missed requirements.

 

2) Having just one use case is probably not = enough, but having too many quickly leads to diminishing returns. The sweet= spot is a relatively small number (3? 4?) that are different enough that they flesh out the (different) key requ= irements. We know that more use cases aren't helping when they simply reaff= irm requirements that have already been made apparent by other use cases.

 

3) Some use cases may be detailed and compli= cated , i.e., because the scenario or technology involved is complicated. O= r they may be oriented towards a particular community.  Such use cases may warrant having their own standalo= ne document.

 

4) If we try to put all use cases into a sin= gle document, we run the risk that folk will continue to ask that additiona= l scenarios be added, making it difficult to close out and finish the document.

 

With that in mind, the WG needs to make some= choices. We propose:

 

1) Have the WG develop one use case document= that documents a small number of representative use cases.  The = document presented by Hongyu Li at the Vancouver BOF could serve for this purpose (http://datatracker.ietf.org/doc/dr= aft-liu-service-chaining-use-cases).

 

2) Remove "Section 4.  Servic= e Function Chaining Use Cases=94 from draft-quinn-sfc-problem-statement. At= present, one section is TBD,  and the other section "3GPP Gi Interface Service Function Chaining=94 would need significan= t expansion, and that expansion probably makes more sense in a separate doc= ument. If there was a simple use case that could be explained (to an IETF r= eader) in 1-2 pages, we could consider putting it here, but we'd need a proposal. (Any takers?)=

 

3) For additional use cases not covered in 1= ) above, allow for a small number of documents that are applicable to speci= fic environments (e.g.  mobility, data center, broadband, and so forth.) These documents would provide more detai= led information and applicability of SFC to these specific environments, an= d would need to go beyond what is covered in the general use case document = (1). Note that it is not the intention to have every potential use case documented.

 

Comments? Does the above approach seem reaso= nable to folks on the list? Any objections?

 

Jim & Thomas

 --_000_CF0E76ED14BDCjguicharciscocom_-- From mohamed.boucadair@orange.com Wed Jan 29 06:40:48 2014 Return-Path: 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 3B5B81A0448 for ; Wed, 29 Jan 2014 06:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 Mo_DUWY6Cfsn for ; Wed, 29 Jan 2014 06:40:43 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 307BF1A03E9 for ; Wed, 29 Jan 2014 06:40:43 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 904AA3B4477; Wed, 29 Jan 2014 15:40:39 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 730FF238089; Wed, 29 Jan 2014 15:40:39 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Wed, 29 Jan 2014 15:40:39 +0100 From: To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Date: Wed, 29 Jan 2014 15:40:37 +0100 Thread-Topic: [sfc] Progression of use case documents within the SFC working group Thread-Index: AQHPHPyldZjNgVZ0CEKUURS3OROEYZqbxhBQ Message-ID: <94C682931C08B048B7A8645303FDC9F36F48634AAD@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36F473607AF@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36F47360A1B@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36F48634AADPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.29.135714 Subject: Re: [sfc] Progression of use case documents within the SFC working group X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 14:40:48 -0000 --_000_94C682931C08B048B7A8645303FDC9F36F48634AADPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jim, Will do. Cheers, Med De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Envoy=E9 : mercredi 29 janvier 2014 15:16 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : Re: [sfc] Progression of use case documents within the SFC working = group Thanks Med. Could you work with the authors of draft-liu-sfc-use-cases and the editors = of draft-ietf-sfc-problem-statement (once published; see recent email) to f= acilitate this change? From: "mohamed.boucadair@orange.com" <= mohamed.boucadair@orange.com> Date: Monday, January 27, 2014 at 8:28 AM To: Jim Guichard >, "sfc@ietf= .org" > Subject: RE: [sfc] Progression of use case documents within the SFC working= group Re-, I meant to adopt "draft-liu-sfc-use-cases" as the use-case document. draft-= liu-service-chaining-use-cases was replaced by draft-liu-sfc-use-cases. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de mohamed.boucadair@oran= ge.com Envoy=E9 : lundi 27 janvier 2014 07:51 =C0 : Jim Guichard (jguichar); sfc@ietf.org Objet : Re: [sfc] Progression of use case documents within the SFC working = group Hi Jim, all, I support the adoption of draft-liu-service-chaining-use-cases as a place t= o record some the use cases already discussed in this list. As I'm the author of the "3GPP Gi Interface Service Function Chaining" sect= ion of the PS document, I'm fine to remove that text from the PS and merge = it with the text of draft-liu-service-chaining-use-cases. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard (jguichar= ) Envoy=E9 : vendredi 24 janvier 2014 19:01 =C0 : sfc@ietf.org Objet : [sfc] Progression of use case documents within the SFC working grou= p Greetings, The documentation and applicability of use cases for the SFC WG was discuss= ed during both the Berlin and Vancouver BOFs. The main purpose of those dis= cussions was to show support for our work and subsequent formation of a wor= king group. As we move forward with our work we would like to solicit opinions of how b= est to approach use cases within the WG. The SFC charter left it open as to= whether we should have a single problem statement that includes use cases = or whether to separate out the use cases. Some background: 1) An important purpose for having use cases is to connect a problem or sol= ution to a real concrete scenario. On the problem side, a use case can high= light requirements for any solution. Hence, having SFC use cases is importa= nt. Lack of use cases could lead to missed requirements. 2) Having just one use case is probably not enough, but having too many qui= ckly leads to diminishing returns. The sweet spot is a relatively small num= ber (3? 4?) that are different enough that they flesh out the (different) k= ey requirements. We know that more use cases aren't helping when they simpl= y reaffirm requirements that have already been made apparent by other use c= ases. 3) Some use cases may be detailed and complicated , i.e., because the scena= rio or technology involved is complicated. Or they may be oriented towards = a particular community. Such use cases may warrant having their own standa= lone document. 4) If we try to put all use cases into a single document, we run the risk t= hat folk will continue to ask that additional scenarios be added, making it= difficult to close out and finish the document. With that in mind, the WG needs to make some choices. We propose: 1) Have the WG develop one use case document that documents a small number = of representative use cases. The document presented by Hongyu Li at the Va= ncouver BOF could serve for this purpose (http://datatracker.ietf.org/doc/d= raft-liu-service-chaining-use-cases). 2) Remove "Section 4. Service Function Chaining Use Cases" from draft-quin= n-sfc-problem-statement. At present, one section is TBD, and the other sec= tion "3GPP Gi Interface Service Function Chaining" would need significant e= xpansion, and that expansion probably makes more sense in a separate docume= nt. If there was a simple use case that could be explained (to an IETF read= er) in 1-2 pages, we could consider putting it here, but we'd need a propos= al. (Any takers?) 3) For additional use cases not covered in 1) above, allow for a small numb= er of documents that are applicable to specific environments (e.g. mobilit= y, data center, broadband, and so forth.) These documents would provide mor= e detailed information and applicability of SFC to these specific environme= nts, and would need to go beyond what is covered in the general use case do= cument (1). Note that it is not the intention to have every potential use c= ase documented. Comments? Does the above approach seem reasonable to folks on the list? Any= objections? Jim & Thomas --_000_94C682931C08B048B7A8645303FDC9F36F48634AADPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jim,=

 

 =

Cheers,

Med<= o:p>

 

=

De : Jim Guichard= (jguichar) [mailto:jguichar@cisco.com]
Envoy=E9 : mercredi= 29 janvier 2014 15:16
=C0 : BOUCADAIR Mohamed IMT/OLN; sfc@= ietf.org
Objet : Re: [sfc] Progression of use case documents= within the SFC working group

 

Thanks Med.

 

Could you work with the autho= rs of draft-liu-sfc-use-cases and the editors of draft-ietf-sfc-problem-sta= tement (once published; see recent email) to facilitate this change?

 

From: &quo= t;mohamed.boucadair@orange.= com" <mohamed.b= oucadair@orange.com>
Date: Monday, January 27, 2014 at 8:2= 8 AM
To: Jim Guichard <j= guichar@cisco.com>, "sfc@ietf.o= rg" <sfc@ietf.org>
Subject: RE: [sfc] Progression of use case documents within the SFC wo= rking group

=  

Re-,

 

I mea= nt to adopt “draft-liu-sfc-use-cases” as the use-case document.= draft-liu-service-chaining-use-cases was replaced by draft-liu-sfc-use-cas= es.

 

Cheers,

=

Med=

 =

De&nb= sp;: sfc [= mailto:sfc-bounces@ietf.org] De la part de mohamed.boucadair@orange.com
Envoy=E9&= nbsp;: lundi 27 janvier 2014 07:51
=C0 : Jim Guichard (j= guichar); sfc@ietf.org
Objet = ;: Re: [sfc] Progression of use case documents within the SFC working g= roup

 

=

Hi Jim, all,

 

I support the adoption of draft-liu-= service-chaining-use-cases as a place to record some the use cases already = discussed in this list.

 

As I’m the author of the "3GPP G= i Interface Service Function Chaining” section of the PS document, I&= #8217;m fine to remove that text from the PS and merge it with the text of = draft-liu-service-chaining-use-cases.

 

Cheers,

Med

 

De : sfc [mailto:sfc-bounces@ietf.org] De l= a part de Jim Guichard (jguichar)
Envoy=E9 : vendredi 24= janvier 2014 19:01
=C0 : sf= c@ietf.org
Objet : [sfc] Progression of use case documen= ts within the SFC working group

&= nbsp;

Greetings,=

 

=

The documentation and applicability of= use cases for the SFC WG was discussed during both the Berlin and Vancouve= r BOFs. The main purpose of those discussions was to show support for our w= ork and subsequent formation of a working group.

 =

As we move forward with our work we would like to solici= t opinions of how best to approach use cases within the WG. The SFC charter= left it open as to whether we should have a single problem statement that = includes use cases or whether to separate out the use cases.

<= span style=3D'font-size:13.5pt;font-family:"Calibri","sans-serif";color:bla= ck'> 

Some background:

 

1) An important purpose for having use cases is to connect a = problem or solution to a real concrete scenario. On the problem side, a use= case can highlight requirements for any solution. Hence, having SFC use ca= ses is important. Lack of use cases could lead to missed requirements.

 

2) Having just one use case is proba= bly not enough, but having too many quickly leads to diminishing returns. T= he sweet spot is a relatively small number (3? 4?) that are different enoug= h that they flesh out the (different) key requirements. We know that more u= se cases aren't helping when they simply reaffirm requirements that have al= ready been made apparent by other use cases.

 

3) Some use cases may be detailed and complicated , i.e., beca= use the scenario or technology involved is complicated. Or they may be orie= nted towards a particular community.  Such use cases may warrant = having their own standalone document.

 

4) If we try to put all use cases into a single document, we run the = risk that folk will continue to ask that additional scenarios be added, mak= ing it difficult to close out and finish the document.

&n= bsp;

With that in mind, the WG needs to make some choices= . We propose:

 

1) Have the WG dev= elop one use case document that documents a small number of representative = use cases.  The document presented by Hongyu Li at the Vancouver = BOF could serve for this purpose (http://datatracker.ietf.org/doc/dra= ft-liu-service-chaining-use-cases).<= o:p>

 

2) Remove "Section 4.  Service Function Chaining Use= Cases” from draft-quinn-sfc-problem-statement. At present, one secti= on is TBD,  and the other section "3GPP Gi Interface Service Func= tion Chaining” would need significant expansion, and that expansion p= robably makes more sense in a separate document. If there was a simple use = case that could be explained (to an IETF reader) in 1-2 pages, we could con= sider putting it here, but we'd need a proposal. (Any takers?)

 

=

3) For additional use cases not covered in 1= ) above, allow for a small number of documents that are applicable to speci= fic environments (e.g.  mobility, data center, broadband, and so = forth.) These documents would provide more detailed information and applica= bility of SFC to these specific environments, and would need to go beyond w= hat is covered in the general use case document (1). Note that it is not th= e intention to have every potential use case documented.

 

=

Comments? Does the above approach seem reasonable= to folks on the list? Any objections?

 

Jim & Thomas

= --_000_94C682931C08B048B7A8645303FDC9F36F48634AADPUEXCB1Bnante_-- From mls.ietf@gmail.com Wed Jan 29 06:45:46 2014 Return-Path: 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 CAA4C1A03E9 for ; Wed, 29 Jan 2014 06:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 7SMihR_5jk_8 for ; Wed, 29 Jan 2014 06:45:45 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id B1B4E1A042A for ; Wed, 29 Jan 2014 06:45:44 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id a1so3633450wgh.28 for ; Wed, 29 Jan 2014 06:45:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=cIJqO8ewPJZN7ajnK+lM5u4v+QYlbVUFTo8Y70844BQ=; b=ZnE93NTyAxZKL+F+K6Hz40asBuWome3yuHeYcpXU4mqpmGCpiPrhLQSzmD2Q/mUY2Y vA2OjCxHr+1ZpSQJIg/Jjm62F70XzB2PPwKU8cK5O/n7PQe2S1NMKcyBAGVGSktrog1W b5TbiDpBLL1O/aSYfMRASVgFLGnGiI+0QelJ+Xn7q9wHlDBU8HHg27B2JYe0FAbgpCR9 Ac+BdKAC+UWMahFFUQf0eXnPSWDgft9PtIZw8PNoHsrhMxqbZEteK36EBBQ7FhV1sOVX S0U+X80UyBZYVyA7d1hE3v4SA3y4sDenk5/BG7/LAUtlXpxIdkNydWfTkpjWNR0LG2T/ C11A== X-Received: by 10.194.93.67 with SMTP id cs3mr5396019wjb.26.1391006741383; Wed, 29 Jan 2014 06:45:41 -0800 (PST) Received: from [10.1.1.137] (mito.netlab.nec.de. [195.37.70.39]) by mx.google.com with ESMTPSA id jw4sm5295122wjc.20.2014.01.29.06.45.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Jan 2014 06:45:40 -0800 (PST) Message-ID: <52E91413.6040808@gmail.com> Date: Wed, 29 Jan 2014 15:45:39 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: sfc@ietf.org References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> In-Reply-To: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 14:45:46 -0000 Hi all, I wanted to raise your attention to the below quoted draft, as it wasn't posted to the SFC list. The draft outlines very well the use cases in mobile networks. Thanks, Martin -------- Original Message -------- Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Date: Tue, 28 Jan 2014 14:26:15 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Service Function Chaining Use Cases in Mobile Networks Authors : Walter Haeffner Jeffrey Napper Filename : draft-haeffner-sfc-use-case-mobility-00.txt Pages : 17 Date : 2014-01-28 Abstract: This document provides some exemplary use cases for service function chaining in mobile service provider networks. The objective of this draft is not to cover all conceivable service chains in detail. Rather, the intention is to localize and explain the application domain of service chaining within mobile networks as far as it is required to complement the problem statement and framework statements of the working group. Service function chains typically reside in a LAN segment which links the mobile access network to the actual application platforms located in the carrier's datacenters or somewhere else in the Internet. Service function chains ensure a fair distribution of network resources according to agreed service policies, enhance the performance of service delivery, take care of security and privacy or support application and business support platforms. General considerations and specific use cases are presented in this document to demonstrate the different technical requirements of these goals for service function chaining in mobile service provider networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From paulq@cisco.com Wed Jan 29 06:58:26 2014 Return-Path: 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 CA6F81A0416 for ; Wed, 29 Jan 2014 06:58:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 ySyxGvzAzc-H for ; Wed, 29 Jan 2014 06:58:25 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 6427A1A0218 for ; Wed, 29 Jan 2014 06:58:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1453; q=dns/txt; s=iport; t=1391007503; x=1392217103; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=Vn/TieknDW0dxMvPvr0Lrlszst+Kll/ZNyt/Igc10bM=; b=aqvKwFhr8fWYltt0469ASKqwvv3+1Z36xQ3P4kmjuR0ycsSnNu4AdBwe 7qqGEg4z29VXs0+lPeiAHJaklU7eIRacsXtpWiVKTZLtXWJI+DFTx4oIo rr0CgfqAlUraIOBilwcLwBjd0KxfDtBltttLEbfbQdAm142pRlfe/aNue w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQFABcW6VKtJV2a/2dsb2JhbABZgww4UAa+BRZ0giUBAQEDATo9EgIBGiQQMhcECgIEHBKHYggIBcl7F5IqgRQEmCiBMpBtgy2CKg X-IronPort-AV: E=Sophos;i="4.95,742,1384300800"; d="scan'208";a="300439474" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 29 Jan 2014 14:58:22 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0TEwMQu013608 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 29 Jan 2014 14:58:22 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.19]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Wed, 29 Jan 2014 08:58:22 -0600 From: "Paul Quinn (paulq)" To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPHQE+740iIXkVW06tWQcece0meg== Date: Wed, 29 Jan 2014 14:58:21 +0000 Message-ID: <35A9A6D9-3ECF-41C9-B145-BDAA0254C771@cisco.com> References: <20140129144857.28482.61199.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.229] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 14:58:27 -0000 Hi folks, The only change to this version is that we moved to two editors, and listed= the other co-authors in a contributors section. As always, your comments and feedback is appreciated! Paul >=20 > A new version of I-D, draft-quinn-sfc-arch-04.txt > has been successfully submitted by Paul Quinn and posted to the > IETF repository. >=20 > Name: draft-quinn-sfc-arch > Revision: 04 > Title: Service Function Chaining (SFC) Architecture > Document date: 2014-01-28 > Group: Individual Submission > Pages: 21 > URL: http://www.ietf.org/internet-drafts/draft-quinn-sfc-arch-= 04.txt > Status: https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/ > Htmlized: http://tools.ietf.org/html/draft-quinn-sfc-arch-04 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-quinn-sfc-arch-0= 4 >=20 > Abstract: > This document describes an architecture used for the creation of > Service Function Chains (SFC). It includes architectural concepts, > principles, and components used in the construction of composite > services through deployment of SFCs in a network. This document does > not propose solutions, protocols, or extensions to existing > protocols. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From internet-drafts@ietf.org Wed Jan 29 07:07:56 2014 Return-Path: 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 D620C1A042C; Wed, 29 Jan 2014 07:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 6GPmRRAqutAT; Wed, 29 Jan 2014 07:07:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 944C81A03DF; Wed, 29 Jan 2014 07:07:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140129150755.28902.55580.idtracker@ietfa.amsl.com> Date: Wed, 29 Jan 2014 07:07:55 -0800 X-Mailman-Approved-At: Wed, 29 Jan 2014 07:11:29 -0800 Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 15:07:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Service Function Chaining Working Group o= f the IETF. Title : Service Function Chaining Problem Statement Authors : Paul Quinn Thomas Nadeau Filename : draft-ietf-sfc-problem-statement-00.txt Pages : 18 Date : 2014-01-29 Abstract: This document provides an overview of the issues associated with the deployment of service functions (such as firewalls, load balancers) in large-scale environments. The term service function chaining is used to describe the definition and instantiation of an ordered set of such service functions, and the subsequent "steering" of traffic flows through those service functions. The set of enabled service function chains reflect operator service offerings and is designed in conjunction with application delivery and service and network policy. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Wed Jan 29 07:18:41 2014 Return-Path: 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 233B51A0456 for ; Wed, 29 Jan 2014 07:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 EXWmNykMZSP9 for ; Wed, 29 Jan 2014 07:18:39 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 43AA41A0443 for ; Wed, 29 Jan 2014 07:18:39 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 96FCA374824 for ; Wed, 29 Jan 2014 16:18:35 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 8214F18009F for ; Wed, 29 Jan 2014 16:18:35 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Wed, 29 Jan 2014 16:18:32 +0100 From: To: "sfc@ietf.org" Date: Wed, 29 Jan 2014 16:18:32 +0100 Thread-Topic: I-D Action: draft-boucadair-sfc-requirements-01.txt Thread-Index: Ac8c/rfN9arXHXmESka81pkzQR12ywABnVog Message-ID: <94C682931C08B048B7A8645303FDC9F36F48634B0A@PUEXCB1B.nanterre.francetelecom.fr> References: <20140129143039.19852.70687.idtracker@ietfa.amsl.com> In-Reply-To: <20140129143039.19852.70687.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.29.140915 Subject: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-01.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 15:18:41 -0000 Dear all, An updated version of this draft is available online. A diff to track the c= hanges is provided below. Comments and contributions are more than welcome. Cheers, Med -----Message d'origine----- De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de in= ternet-drafts@ietf.org Envoy=E9=A0: mercredi 29 janvier 2014 15:31 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D Action: draft-boucadair-sfc-requirements-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Requirements for Service Function Chaining Authors : Mohamed Boucadair Christian Jacquenet Yuanlong Jiang Ron Parker Carlos Pignataro Filename : draft-boucadair-sfc-requirements-01.txt Pages : 13 Date : 2014-01-29 Abstract: This document identifies the requirements for the Service Function Chaining (SFC). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-boucadair-sfc-requirements-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-sfc-requirements-01 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From jmh@joelhalpern.com Wed Jan 29 07:53:24 2014 Return-Path: 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 D5F7B1A0216 for ; Wed, 29 Jan 2014 07:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 QyDj-TgtJMEL for ; Wed, 29 Jan 2014 07:53:23 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 18BBD1A0207 for ; Wed, 29 Jan 2014 07:53:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 7D5451BD6E54; Wed, 29 Jan 2014 07:53:20 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-128.clppva.east.verizon.net [70.106.135.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id CE0BE1BD6E52; Wed, 29 Jan 2014 07:53:19 -0800 (PST) Message-ID: <52E923EF.5030706@joelhalpern.com> Date: Wed, 29 Jan 2014 10:53:19 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, "sfc@ietf.org" References: <20140129143039.19852.70687.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F48634B0A@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F48634B0A@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-01.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 15:53:25 -0000 My apologies if I am misreading the document. Many of the requirements are couched in terms of SF-Maps and specific kinds of IDs. Both of those are aspects of solutions, not requirements. I found it very hard to separate the actual requirements from the presumption of solution in the draft. Also, have you checked that the requirements are aligned with the agreed architecture? Yours, Joel M. Halpern On 1/29/14, 10:18 AM, mohamed.boucadair@orange.com wrote: > Dear all, > > An updated version of this draft is available online. A diff to track the changes is provided below. > > Comments and contributions are more than welcome. > > Cheers, > Med > > -----Message d'origine----- > De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de internet-drafts@ietf.org > Envoyé : mercredi 29 janvier 2014 15:31 > À : i-d-announce@ietf.org > Objet : I-D Action: draft-boucadair-sfc-requirements-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Requirements for Service Function Chaining > Authors : Mohamed Boucadair > Christian Jacquenet > Yuanlong Jiang > Ron Parker > Carlos Pignataro > Filename : draft-boucadair-sfc-requirements-01.txt > Pages : 13 > Date : 2014-01-29 > > Abstract: > This document identifies the requirements for the Service Function > Chaining (SFC). > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-boucadair-sfc-requirements-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-boucadair-sfc-requirements-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From linda.dunbar@huawei.com Wed Jan 29 09:31:29 2014 Return-Path: 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 A33C41A043B for ; Wed, 29 Jan 2014 09:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 08lTJyuh6jTo for ; Wed, 29 Jan 2014 09:31:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CA5321A03FD for ; Wed, 29 Jan 2014 09:31:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDB42935; Wed, 29 Jan 2014 17:31:20 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 29 Jan 2014 17:30:45 +0000 Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 29 Jan 2014 17:31:19 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml705-chm.china.huawei.com ([169.254.7.245]) with mapi id 14.03.0158.001; Wed, 29 Jan 2014 09:31:15 -0800 From: Linda Dunbar To: "mohamed.boucadair@orange.com" Thread-Topic: Comments and suggestions to draft-boucadair-sfc-framework-00 Thread-Index: Ac8dF+h8j+p/oQfZTT2XWc7eCXJVWg== Date: Wed, 29 Jan 2014 17:31:14 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C74864@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.174] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645C74864dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "sfc@ietf.org" Subject: [sfc] Comments and suggestions to draft-boucadair-sfc-framework-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 17:31:29 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645C74864dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mohamed, I have some comments and suggestions to your draft "draft-boucadair-sfc-fra= mework-00": 1.5 Rationale: First bullet: Does "Dynamic Provisioning" mean the "provisioning of the ser= vice functions" or dynamically steering traffic to service functions? Third to last bullet (p6): "Nodes are provisioned with the policy table of= the SFC enabled domain they belong to": what is the "policy table"? Do nod= es include SF nodes and transport nodes? Section 2 Terminology: "Legacy Node": We need to acknowledge the existence of "Legacy Service Functions" that don= 't terminate any new SF header to be specified by IETF SFC WG. The term "= proxy node" is introduced by [NSC-header] as an entity to remove and insert= service layer encapsulation on behalf of service nodes that are not aware = service layer encapsulation. Suggest the following warding for the "Legacy Node": "Legacy service node: the existing service nodes that are not aware of the= new service encapsulation layers or overlay encapsulation layer being spec= ified in SFC WG. " "SF proxy node: a node, most likely a network node along the data path, to = terminate and encapsulate service layer encapsulation on behalf of legacy s= ervice nodes." Section 3: "SFC Classifier": the policy for service chain can also be based on port or= other attributes that are not in the packet header. Therefore suggest the = following wording. "SFC Classifier: an entity that classifiers packets for service chaining ac= cording to classification rules defined in a SFC Policy Table. Packets are = then marked with the corresponding SF Map Index. SFC Classifier is embedded= in a SFC boundary (Ingress) Node." Maybe also worth mentioning: "SFC Egress Node removes the SF Map Index from= the packets"? Section 4.4: Direction can be reflected by the ports for the Ingress SFC boundary nodes.= It can be easier to eliminate the "direction" attribute in the SFC Policy = Table. BR, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F645C74864dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mohamed,

 

I have some commen= ts and suggestions to your draft “draft-boucadair-sfc-framework-00= 221;:

 <= /p>

 <= /p>

 

1.5 Rationale:

First bullet:= Does "Dynamic Provisioning" mean the "provisioning of the s= ervice functions" or dynamically steering traffic to service functions= ?

Third to last bullet (p6)= :  “Nodes are provisioned with the policy table of the SFC enabl= ed domain they belong to”: what is the “policy table”? Do= nodes include SF nodes and transport nodes?

 

Section 2 Terminology:

“Legacy Node”:

We need to acknowledge th= e existence of “Legacy Service Functions” that don’t term= inate any new SF header to be specified by IETF SFC WG.   The ter= m “proxy node” is introduced by [NSC-header] as an entity to re= move and insert service layer encapsulation on behalf of service nodes that are= not aware service layer encapsulation.

Suggest the following war= ding for the “Legacy Node”:

“Legacy servi= ce node:  the existing service nodes that are not aware of the new= service encapsulation layers or overlay encapsulation layer being specifie= d in SFC WG. “

“SF proxy node: = a node, most likely a network node along the data path, to terminate and en= capsulate service layer encapsulation on behalf of legacy service nodes.= 221;

 

Section 3:

“SFC ClassifierR= 21;: the policy for service chain can also be based on port or other attrib= utes that are not in the packet header. Therefore suggest the following wor= ding.

&#= 8220;SFC Classifier: an entity that classifiers packets for service = chaining according to classification rules defined in a SFC Policy Table. P= ackets are then marked with the corresponding SF Map Index. SFC Classifier is embedded in a SFC boundary (Ingress) Node.= ”=

 

Maybe also worth mentioni= ng: “SFC Egress Node removes the SF Map Index from the packets”= ?

 

Section 4.4:

Di= rection can be reflected by the ports for the Ingress SFC boundary nodes. I= t can be easier to eliminate the “direction” attribute in the SFC Policy Table.

 

BR,

 

Linda Dunbar

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645C74864dfweml701chmchi_-- From schaganti@versa-networks.com Wed Jan 29 11:57:59 2014 Return-Path: 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 EC11E1A03E1 for ; Wed, 29 Jan 2014 11:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=no 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 O7bjyqoQn9hk for ; Wed, 29 Jan 2014 11:57:56 -0800 (PST) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id 91BF61A03D6 for ; Wed, 29 Jan 2014 11:57:56 -0800 (PST) Received: by mail-ve0-f182.google.com with SMTP id jy13so1512543veb.41 for ; Wed, 29 Jan 2014 11:57:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type :content-transfer-encoding; bh=AfofyjRiG1IqcRg4sBPlc3eUDsZp6OIbVX4X94gL5BQ=; b=BbOsHmkyxLciDfczDrAWqT41KIhjbt3v+nQQUzAabZt0wqNcK6SZf5jLB9o22YBBAH mO8Srq2yFucEDFduLYKEHtBpZ2Hj0diYl+D/z51UPzKDRkvsrfrXsHcgXwaCULEr2NV2 aub2u925VrDgVCeyh0hGH4CbKBElUWFD7ysFl1G+DWapLUlkZozyL2ZA30uvlfRVGLRD kAS5cbGjjaOwqSWbl8Wz1JwvVjt8ChmcCiyRxUz3KP/P2F+WLpKuQVLx9R6IEKZUwfdw nPaUItHNZdWHVxw/VvN1rRwIsUDpv3qMycb6kt36SciEHdgv0jL2QCTL922BMoR43haQ Q63Q== X-Gm-Message-State: ALoCoQlsG9FGJ5aGpDSJ9LQvO/hVhIGJaVPZ5T+wNJiZjI98iVckIws1dezc+RwxlylfX2658C7v X-Received: by 10.52.95.233 with SMTP id dn9mr6829109vdb.3.1391025473371; Wed, 29 Jan 2014 11:57:53 -0800 (PST) From: Srinivasa Chaganti References: <9C2DE4B8FE85984BA1B0581235F6B2ED0F633EAB@SZXEMA502-MBS.china.huawei.com> <9C2DE4B8FE85984BA1B0581235F6B2ED0F633F22@SZXEMA502-MBS.china.huawei.com> <9C2DE4B8FE85984BA1B0581235F6B2ED0F6350D1@SZXEMA502-MBS.china.huawei.com> <81126FE293D58240BD872F99F2606543368E3E75@szxema507-mbs.china.huawei.com> <1989047253.7723.1390921656400.JavaMail.tomcat@mgs-aam01.mail.aol.com> <114745883.8305.1390932975869.JavaMail.tomcat@mgs-aaa01.mail.aol.com> In-Reply-To: <114745883.8305.1390932975869.JavaMail.tomcat@mgs-aaa01.mail.aol.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHdtlUtP47eHupe1jEnNUqnilerIAF0kEPXAhMiJAkDEleneQFvpR2NAYAaGTECf4gEXwGBhZD4mhKRgSA= Date: Wed, 29 Jan 2014 11:54:50 -0800 Message-ID: <169818979a6be3eb69e01fb92967fff3@mail.gmail.com> To: mikebianc@aol.com, jguichar@cisco.com, jun.lee@huawei.com, zhuangyuxin@huawei.com, Ron_Parker@affirmednetworks.com, sfc@ietf.org, melinda.shore@gmail.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [sfc] =?utf-8?b?562U5aSNOiBTZXJ2aWNlcyBlbGlnaWJsZSBmb3IgY2hhaW5p?= =?utf-8?q?ng?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 19:57:59 -0000 I agree, NAT is a good candidate to be a Service Function in SFC architecture especially when it is chained with other service functions. SFC architecture allows any service function to reclassify the traffic and pick a different service-chain if classifier says so. With NAT we may need an additional service-chain "NAT chain" just to perform deNAT functionality on the internet to client direction traffic and do reclassification of translated packets to pick reverse-chain for rest of the service functions to be performed. "NAT chain" will be picked by the classifier for all the traffic destined to public addresses of NAT function. Thanks Chaganti -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mikebianc@aol.com Sent: Tuesday, January 28, 2014 10:16 AM To: jguichar@cisco.com; jun.lee@huawei.com; zhuangyuxin@huawei.com; Ron_Parker@affirmednetworks.com; sfc@ietf.org; melinda.shore@gmail.com Subject: Re: [sfc] =E7=AD=94=E5=A4=8D: Services eligible for chaining Actually, even if all you want to do is NAT, but you don't want to have to put the NAT inline (e.g. you only want some of the traffic to be NATed but don't want to pay for links to support all of the traffic that has no need for the NAT service), SFC would be kind of ideal. That being said, what does it matter if the NAT is one of multiple functions in a chain or the sole function in the chain? Either way, it is a valid SF. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From repenno@cisco.com Wed Jan 29 22:27:04 2014 Return-Path: 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 5150A1A04EA for ; Wed, 29 Jan 2014 22:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 4fvOIHi0rGjG for ; Wed, 29 Jan 2014 22:27:00 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id C963C1A04EB for ; Wed, 29 Jan 2014 22:26:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2912; q=dns/txt; s=iport; t=1391063217; x=1392272817; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=AHz7CBN74k1JCz4ECgeQq5okOuhvNpg7RTyKh0MxL18=; b=hOUGUPt9SG/HCO1Vc1hsIhTbQtFgYhbzswjxWrkAFXrNrlA8tnQIJPkT tAFYL+B1Fg2JlL5sDmteS7nT9U1jhrkoIYjerXk+JnP541kaveg2titsg l0TWRD46rEoZyelgg+8xW499hwzn3FS8uOT14M+M96U1z8etsaZRoNs69 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8FAPnv6VKtJXG//2dsb2JhbABQCYMMOFEGvRyBAhZ0gicBBAEBAWsJFAEIElsLFw4CBAESCRKHaggFy1AXjiQoOoQ4BIkRjxeBMpBtgy2CKg X-IronPort-AV: E=Sophos;i="4.95,747,1384300800"; d="scan'208";a="16603930" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-2.cisco.com with ESMTP; 30 Jan 2014 06:26:56 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0U6Qucx026645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 30 Jan 2014 06:26:56 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.37]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Thu, 30 Jan 2014 00:26:56 -0600 From: "Reinaldo Penno (repenno)" To: "Paul Quinn (paulq)" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPHQE+740iIXkVW06tWQcece0mepqcrP8A Date: Thu, 30 Jan 2014 06:26:55 +0000 Message-ID: In-Reply-To: <35A9A6D9-3ECF-41C9-B145-BDAA0254C771@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.70.20] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9C69009498C2A44FAB2082F9F0B93655@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 06:27:04 -0000 Hi Paul, Reviewing this draft and comparing with the Yang model I have a couple of comments 1 -=20 I noticed that a SFID and SFC-domain might need more wording. "Service Function Identity (SFID): A unique identifier that represents a service function. SFIDs are unique for each SF within an SFC domain.=B2 "SFC-domain" is used within the definition above but then the draft switches to "administrative domain=B2 everywhere else. Also, the definition of Service Function uses =B3administrative domain=B2 instead of of "SFC-domain". 2 -=20 It seems were are missing the definition of a instantiated Service Function: A Service Function is something like NAT44, Firewall, etc. It denotes a class of services that provide the same function. A SFC is an ordered set of SFs. A SFP is an instantiation of a SFC. So, what do we call the SFs that are instantiated and part of the SFP? We can not call them Service Functions again because we are now talking about an specific service and that would cause confusion. Do we call them "Service Function Instances=B2 and therefore a SFP is composed of an ordered set of Service Function Instances? Thanks, -RP On 1/29/14, 6:58 AM, "Paul Quinn (paulq)" wrote: >Hi folks, > >The only change to this version is that we moved to two editors, and >listed the other co-authors in a contributors section. > >As always, your comments and feedback is appreciated! >Paul > > >>=20 >> A new version of I-D, draft-quinn-sfc-arch-04.txt >> has been successfully submitted by Paul Quinn and posted to the >> IETF repository. >>=20 >> Name: draft-quinn-sfc-arch >> Revision: 04 >> Title: Service Function Chaining (SFC) Architecture >> Document date: 2014-01-28 >> Group: Individual Submission >> Pages: 21 >> URL: =20 >>http://www.ietf.org/internet-drafts/draft-quinn-sfc-arch-04.txt >> Status: https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/ >> Htmlized: http://tools.ietf.org/html/draft-quinn-sfc-arch-04 >> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-quinn-sfc-arch-= 04 >>=20 >> Abstract: >> This document describes an architecture used for the creation of >> Service Function Chains (SFC). It includes architectural concepts, >> principles, and components used in the construction of composite >> services through deployment of SFCs in a network. This document does >> not propose solutions, protocols, or extensions to existing >> protocols. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of >>submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From repenno@cisco.com Wed Jan 29 22:33:09 2014 Return-Path: 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 0BC5D1A02F3 for ; Wed, 29 Jan 2014 22:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 EC94X9LLBC1J for ; Wed, 29 Jan 2014 22:33:07 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 31E051A04DF for ; Wed, 29 Jan 2014 22:33:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2719; q=dns/txt; s=iport; t=1391063584; x=1392273184; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=4HTzbJdVtnlWrUTClWzOA0ka5Ky929HGH5OUjwro/tQ=; b=hctUviNwhdj0gT7QBrMNZ7iz5IcNzOn53uOzicendhB3vbWqASoGvzly Ip6gNEkSbjNL5C+HiBpGzpZERZOuMpQkD4uJ/6oTxYpng5hZvPlJTglXu tFQc61Ml6wWOz/sDH4Nk2/8iFPqVuk6rC+eDYHKAQAyJrqZEmBhcmXRlz 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8FAGrx6VKtJV2a/2dsb2JhbABZgww4UQa9HIECFnSCJwEEAQEBax0BCD8uCxQRAQEEARIJEodqCAXLTxeOTDUFhDgEiRGPF4Eyiy+FPoMtgio X-IronPort-AV: E=Sophos;i="4.95,747,1384300800"; d="scan'208";a="16603214" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP; 30 Jan 2014 06:33:03 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0U6X38d024422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jan 2014 06:33:03 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.37]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Thu, 30 Jan 2014 00:33:03 -0600 From: "Reinaldo Penno (repenno)" To: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Thread-Topic: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-01.txt Thread-Index: Ac8c/rfN9arXHXmESka81pkzQR12ywABnVogABvLyQA= Date: Thu, 30 Jan 2014 06:33:02 +0000 Message-ID: In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F48634B0A@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.70.20] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3DA14D940989AB4E882B1E499858A05D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-01.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 06:33:09 -0000 Hi Med, I reviewed your draft and before more detailed comments I have a general question. When you say "The solution MUST=B2, what do mean by =B3solution=B2? Do you mean the IETF must standardize a method for meeting that requirement? Or is this targeted to the service provider, the vendor, etc?=20 Some of the =B3the solution MUST=B2 seems to me more RFP material and outsi= de the scope of IETF and therefore the document...or not. And therefore would like clarification. Thanks, Reinaldo On 1/29/14, 7:18 AM, "mohamed.boucadair@orange.com" wrote: >Dear all, > >An updated version of this draft is available online. A diff to track the >changes is provided below. > >Comments and contributions are more than welcome. > >Cheers, >Med > >-----Message d'origine----- >De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de >internet-drafts@ietf.org >Envoy=E9 : mercredi 29 janvier 2014 15:31 >=C0 : i-d-announce@ietf.org >Objet : I-D Action: draft-boucadair-sfc-requirements-01.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Requirements for Service Function Chaining > Authors : Mohamed Boucadair > Christian Jacquenet > Yuanlong Jiang > Ron Parker > Carlos Pignataro > Filename : draft-boucadair-sfc-requirements-01.txt > Pages : 13 > Date : 2014-01-29 > >Abstract: > This document identifies the requirements for the Service Function > Chaining (SFC). > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-boucadair-sfc-requirements-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-sfc-requirements-01 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From mohamed.boucadair@orange.com Wed Jan 29 22:50:56 2014 Return-Path: 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 84C221A04F4 for ; Wed, 29 Jan 2014 22:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 DEr6iNgPi9va for ; Wed, 29 Jan 2014 22:50:54 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 70E8B1A04F5 for ; Wed, 29 Jan 2014 22:50:54 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 9846822C383; Thu, 30 Jan 2014 07:50:50 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 7F61C238085; Thu, 30 Jan 2014 07:50:50 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Thu, 30 Jan 2014 07:50:50 +0100 From: To: "Joel M. Halpern" , "sfc@ietf.org" Date: Thu, 30 Jan 2014 07:50:47 +0100 Thread-Topic: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-01.txt Thread-Index: Ac8dCj3vBVM7wpBvRhiI2pUy1XfhNAAe/ppA Message-ID: <94C682931C08B048B7A8645303FDC9F36F48634C02@PUEXCB1B.nanterre.francetelecom.fr> References: <20140129143039.19852.70687.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F48634B0A@PUEXCB1B.nanterre.francetelecom.fr> <52E923EF.5030706@joelhalpern.com> In-Reply-To: <52E923EF.5030706@joelhalpern.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.30.61814 Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-01.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 06:50:56 -0000 Hi Joel, The requirements are drawn from a functional perspective with a constraint = to avoid binding them specific to a solution. If there are some that you th= ink are solution-specific, then it would be helpful to point those and disc= uss them.=20 The document uses the reference architecture defined in the "architecture a= nd framework" document cited in the draft. That architecture defines a set = of functional elements.=20 Does the "agreed architecture" you are referring define an architecture dis= tinct than the one cited in the requirements draft? Cheers, Med >-----Message d'origine----- >De=A0: Joel M. Halpern [mailto:jmh@joelhalpern.com] >Envoy=E9=A0: mercredi 29 janvier 2014 16:53 >=C0=A0: BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org >Objet=A0: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-01.tx= t > >My apologies if I am misreading the document. >Many of the requirements are couched in terms of SF-Maps and specific >kinds of IDs. Both of those are aspects of solutions, not requirements. > I found it very hard to separate the actual requirements from the >presumption of solution in the draft. > >Also, have you checked that the requirements are aligned with the agreed >architecture? > >Yours, >Joel M. Halpern > >On 1/29/14, 10:18 AM, mohamed.boucadair@orange.com wrote: >> Dear all, >> >> An updated version of this draft is available online. A diff to track th= e >changes is provided below. >> >> Comments and contributions are more than welcome. >> >> Cheers, >> Med >> >> -----Message d'origine----- >> De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de >internet-drafts@ietf.org >> Envoy=E9 : mercredi 29 janvier 2014 15:31 >> =C0 : i-d-announce@ietf.org >> Objet : I-D Action: draft-boucadair-sfc-requirements-01.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >directories. >> >> >> Title : Requirements for Service Function Chaining >> Authors : Mohamed Boucadair >> Christian Jacquenet >> Yuanlong Jiang >> Ron Parker >> Carlos Pignataro >> Filename : draft-boucadair-sfc-requirements-01.txt >> Pages : 13 >> Date : 2014-01-29 >> >> Abstract: >> This document identifies the requirements for the Service Function >> Chaining (SFC). >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-01 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-sfc-requirements-01 >> >> >> Please note that it may take a couple of minutes from the time of >submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> From mohamed.boucadair@orange.com Wed Jan 29 23:09:50 2014 Return-Path: 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 EBF981A04F5 for ; Wed, 29 Jan 2014 23:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 R3unQCiWQaSf for ; Wed, 29 Jan 2014 23:09:48 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id A8A5C1A04F4 for ; Wed, 29 Jan 2014 23:09:47 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 087ECC0C7B; Thu, 30 Jan 2014 08:09:44 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id E1094C80E0; Thu, 30 Jan 2014 08:09:43 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Thu, 30 Jan 2014 08:09:43 +0100 From: To: Linda Dunbar Date: Thu, 30 Jan 2014 08:09:41 +0100 Thread-Topic: Comments and suggestions to draft-boucadair-sfc-framework-00 Thread-Index: Ac8dF+h8j+p/oQfZTT2XWc7eCXJVWgAb7ZNw Message-ID: <94C682931C08B048B7A8645303FDC9F36F48634C0D@PUEXCB1B.nanterre.francetelecom.fr> References: <4A95BA014132FF49AE685FAB4B9F17F645C74864@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C74864@dfweml701-chm.china.huawei.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36F48634C0DPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.30.43021 Cc: "sfc@ietf.org" Subject: Re: [sfc] Comments and suggestions to draft-boucadair-sfc-framework-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 07:09:51 -0000 --_000_94C682931C08B048B7A8645303FDC9F36F48634C0DPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Linda, Thank you for the comments. Please see inline. Cheers, Med De : Linda Dunbar [mailto:linda.dunbar@huawei.com] Envoy=E9 : mercredi 29 janvier 2014 18:31 =C0 : BOUCADAIR Mohamed IMT/OLN Cc : sfc@ietf.org Objet : Comments and suggestions to draft-boucadair-sfc-framework-00 Mohamed, I have some comments and suggestions to your draft "draft-boucadair-sfc-fra= mework-00": 1.5 Rationale: First bullet: Does "Dynamic Provisioning" mean the "provisioning of the ser= vice functions" or dynamically steering traffic to service functions? [Med] It refers to the provisioning of the "Service Functions" and "SFC Cla= ssier". Third to last bullet (p6): "Nodes are provisioned with the policy table of= the SFC enabled domain they belong to": what is the "policy table"? [Med] The policy table is defined in Section 2: o SFC Policy Table: is a table containing a list of SF Maps, SFC classification rules and Locators for all SF Nodes. A SFC Policy Table may contain a default SF Map. Do nodes include SF nodes and transport nodes? [Med] It includes only "SF Nodes" and "SFC Boundary Node". Section 2 Terminology: "Legacy Node": We need to acknowledge the existence of "Legacy Service Functions" that don= 't terminate any new SF header to be specified by IETF SFC WG. The term "= proxy node" is introduced by [NSC-header] as an entity to remove and insert= service layer encapsulation on behalf of service nodes that are not aware = service layer encapsulation. Suggest the following warding for the "Legacy Node": "Legacy service node: the existing service nodes that are not aware of the= new service encapsulation layers or overlay encapsulation layer being spec= ified in SFC WG. " [Med] Shouldn't the wording be updated to reflect that these legacy service= nodes cannot be upgraded to support the (to be defined) SFC features? Ther= e are various considerations to take into account such as the following: =B7 Some of the existing service nodes can be upgraded while other = cannot =B7 Even in the presence of an SFC domain, an operator may decide t= o not enable SFC feature in a node (even if supports the sfc features) "SF proxy node: a node, most likely a network node along the data path, to = terminate and encapsulate service layer encapsulation on behalf of legacy s= ervice nodes." [Med] I see the point. I think this is useful to be discussed in Section "1= 0.2. Deployment Models" (http://tools.ietf.org/html/draft-boucadair-sfc-fra= mework-00#section-10.2) Section 3: "SFC Classifier": the policy for service chain can also be based on port or= other attributes that are not in the packet header. Therefore suggest the = following wording. "SFC Classifier: an entity that classifiers packets for service chaining ac= cording to classification rules defined in a SFC Policy Table. Packets are = then marked with the corresponding SF Map Index. SFC Classifier is embedded= in a SFC boundary (Ingress) Node." [Med] Works for me. Thanks. Maybe also worth mentioning: "SFC Egress Node removes the SF Map Index from= the packets"? [Med] No problem to add it. Section 4.4: Direction can be reflected by the ports for the Ingress SFC boundary nodes.= It can be easier to eliminate the "direction" attribute in the SFC Policy = Table. [Med] In fact there is no "direction" attribute in the SFC Policy Table. Wi= ll double check the text to make it clear. BR, [Med] Thank you for the review and suggestions. Linda Dunbar --_000_94C682931C08B048B7A8645303FDC9F36F48634C0DPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Linda,

 

Thank you for the comments.

=  

Please see inline.<= /span>

 

Cheers,

Med

<= p class=3DMsoNormal> 

De : Linda Dunbar [mailto:linda.dunbar@= huawei.com]
Envoy=E9 : mercredi 29 janvier 2014 18:31
=C0 : BOUCADAIR Mohamed IMT/OLN
Cc : sfc@ietf.org<= br>Objet : Comments and suggestions to draft-boucadair-sfc-fram= ework-00

 <= /o:p>

Mohamed,

=  

I have some commen= ts and suggestions to your draft “draft-boucadair-sfc-framework-00= 221;:

 

 

 

1.5 Rationale:

First bullet: Does "Dynamic Provisioning" mean = the "provisioning of the service functions" or dynamically steeri= ng traffic to service functions?

= [Med] It refers to the provisioning of the “Service FunctionsR= 21; and “SFC Classier”.

Third to last bullet (p6):&nbs= p; “Nodes are provisioned with the policy table of the SFC enabled do= main they belong to”: what is the “policy table”?

[Med]= The policy table is defined in Section 2:

 

=A0=A0 o=A0 = SFC Policy Table: is a table containing a list of SF Maps, SFC

=A0=A0=A0=A0=A0 classification rules and Locators for all SF = Nodes.=A0 A SFC Policy

=A0=A0=A0=A0=A0 Table may = contain a default SF Map.

<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:#1F497D'>

Do nodes include SF nodes and transport nodes?

 

 

Section 2 Terminology:=

“Legacy Node”:

We need to acknowledge the = existence of “Legacy Service Functions” that don’t termin= ate any new SF header to be specified by IETF SFC WG.   The term = “proxy node” is introduced by [NSC-header] as an entity to remo= ve and insert service layer encapsulation on behalf of service nodes that a= re not aware service layer encapsulation.

Suggest the following warding for the ̶= 0;Legacy Node”:

“Legacy service node:  the existing service= nodes that are not aware of the new service encapsulation layers or overla= y encapsulation layer being specified in SFC WG. “

=

[Med] Shouldn’t the wording be updated to re= flect that these legacy service nodes cannot be upgraded to support the (to= be defined) SFC features? There are various considerations to take into ac= count such as the following:

=B7         Some of the existing service nodes can be upgraded while ot= her cannot

=B7         Even in the presence of an SFC domain, an operator may decide to = not enable SFC feature in a node (even if supports the sfc features)

“SF proxy node: a node, most likely a network node alon= g the data path, to terminate and encapsulate service layer encapsulation o= n behalf of legacy service nodes.”

[Med] I see the point. I think this is useful to be discussed in S= ection “10.2. Deployment Models” (http://tools.ietf.org/html/dr= aft-boucadair-sfc-framework-00#section-10.2)

 

Section 3:

“SFC Classifier”: the policy for service chain can also be ba= sed on port or other attributes that are not in the packet header. Therefor= e suggest the following wording.

“SFC Classifier= : an entity that classifiers packets for service chaining according to clas= sification rules defined in a SFC Policy Table. Packets are then marked wit= h the corresponding SF Map Index. SFC Classifier is embedded in a SFC bound= ary (Ingress) Node.”

[Med] Works for me. Thanks.

 

Maybe also w= orth mentioning: “SFC Egress Node removes the SF Map Index from the p= ackets”?

[Med] No problem to a= dd it.

 

Section 4.4:

Direction c= an be reflected by the ports for the Ingress SFC boundary nodes. It can be = easier to eliminate the “direction” attribute in the SFC Policy= Table.

[Med] In fact there = is no “direction” attribute in the SFC Policy Table. Will doubl= e check the text to make it clear.

 

BR,

= [Med] Thank you for the review and suggestions.

 

Linda Dunbar

 = ;

= --_000_94C682931C08B048B7A8645303FDC9F36F48634C0DPUEXCB1Bnante_-- From mohamed.boucadair@orange.com Wed Jan 29 23:21:23 2014 Return-Path: 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 77C501A0476 for ; Wed, 29 Jan 2014 23:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 bvlXVqFPYqJU for ; Wed, 29 Jan 2014 23:21:22 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id BA9A31A04FA for ; Wed, 29 Jan 2014 23:21:19 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id C142A3244E2; Thu, 30 Jan 2014 08:21:15 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id A4E5227C058; Thu, 30 Jan 2014 08:21:15 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Thu, 30 Jan 2014 08:21:15 +0100 From: To: "Reinaldo Penno (repenno)" , "sfc@ietf.org" Date: Thu, 30 Jan 2014 08:21:14 +0100 Thread-Topic: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-01.txt Thread-Index: Ac8c/rfN9arXHXmESka81pkzQR12ywABnVogABvLyQAABX+3MA== Message-ID: <94C682931C08B048B7A8645303FDC9F36F48634C21@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36F48634B0A@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.30.61814 Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-01.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 07:21:23 -0000 Hi Reinaldo, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] >Envoy=E9=A0: jeudi 30 janvier 2014 07:33 >=C0=A0: BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org >Objet=A0: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-01.tx= t > >Hi Med, > >I reviewed your draft and before more detailed comments I have a general >question. > >When you say "The solution MUST=B2, what do mean by =B3solution=B2? [Med] What is actually meant by "The solution" is called out in each sectio= n: * Section 3: indicates " The following set of functional requirements sho= uld be considered for the design of the Service Function Chaining solution:" * Section 4: says " This section lists the set of requirements for the Se= rvice Function Discovery procedure (denoted hereafter as "the solution")." * Section 5: says " This section lists the set of requirements for the SF= C Diagnosis & Troubleshooting procedure (denoted hereafter as "the solution")." Ideally, the requirements in Section 3 should be grouped, for instance per = Functional Element. But, we didn't done that yet.=20 > >Do you mean the IETF must standardize a method for meeting that >requirement?=20 [Med] Those are functional requirements for the IETF work. Detailed require= ments can be added but it will be hard to be keep a document solution-indep= endent. =20 Or is this targeted to the service provider, the vendor, >etc? > >Some of the =B3the solution MUST=B2 seems to me more RFP material and outs= ide >the scope of IETF and therefore the document...or not. And therefore would >like clarification. [Med] Let's discuss those requirements that you think should be out of scop= e. The list is not frozen, it is here to be alive.=20 > >Thanks, [Med] Thank for this input. > >Reinaldo > >On 1/29/14, 7:18 AM, "mohamed.boucadair@orange.com" > wrote: > >>Dear all, >> >>An updated version of this draft is available online. A diff to track the >>changes is provided below. >> >>Comments and contributions are more than welcome. >> >>Cheers, >>Med >> >>-----Message d'origine----- >>De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de >>internet-drafts@ietf.org >>Envoy=E9 : mercredi 29 janvier 2014 15:31 >>=C0 : i-d-announce@ietf.org >>Objet : I-D Action: draft-boucadair-sfc-requirements-01.txt >> >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> >> >> Title : Requirements for Service Function Chaining >> Authors : Mohamed Boucadair >> Christian Jacquenet >> Yuanlong Jiang >> Ron Parker >> Carlos Pignataro >> Filename : draft-boucadair-sfc-requirements-01.txt >> Pages : 13 >> Date : 2014-01-29 >> >>Abstract: >> This document identifies the requirements for the Service Function >> Chaining (SFC). >> >> >> >>The IETF datatracker status page for this draft is: >>https://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/ >> >>There's also a htmlized version available at: >>http://tools.ietf.org/html/draft-boucadair-sfc-requirements-01 >> >>A diff from the previous version is available at: >>http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-sfc-requirements-01 >> >> >>Please note that it may take a couple of minutes from the time of >>submission >>until the htmlized version and diff are available at tools.ietf.org. >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>_______________________________________________ >>I-D-Announce mailing list >>I-D-Announce@ietf.org >>https://www.ietf.org/mailman/listinfo/i-d-announce >>Internet-Draft directories: http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>_______________________________________________ >>sfc mailing list >>sfc@ietf.org >>https://www.ietf.org/mailman/listinfo/sfc From jmh@joelhalpern.com Thu Jan 30 07:00:54 2014 Return-Path: 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 42B781A038C for ; Thu, 30 Jan 2014 07:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 aWg-hM4orQM7 for ; Thu, 30 Jan 2014 07:00:52 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 49C871A0385 for ; Thu, 30 Jan 2014 07:00:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 536321BCC3DA; Thu, 30 Jan 2014 07:00:49 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-128.clppva.east.verizon.net [70.106.135.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 83E011BCC3DF; Thu, 30 Jan 2014 07:00:48 -0800 (PST) Message-ID: <52EA6920.6040306@joelhalpern.com> Date: Thu, 30 Jan 2014 10:00:48 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, "sfc@ietf.org" References: <20140129143039.19852.70687.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F48634B0A@PUEXCB1B.nanterre.francetelecom.fr> <52E923EF.5030706@joelhalpern.com> <94C682931C08B048B7A8645303FDC9F36F48634C02@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F48634C02@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-01.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 15:00:54 -0000 My apologies about the architecture reference. There is no WG agreed architecture. My talking abou tthat is both wrong and confusing. The larger point however remains. The requirements as written treat elements like the SF-Map and the SF-ID as if they are information that will appear in the data packet. That would be part of a solution. I found that to be quite confusing, and it made it hard to determine what the solution-independent requirements are. We really need such requirements, particularly from folks like you on the operator side. Yours, Joel On 1/30/14, 1:50 AM, mohamed.boucadair@orange.com wrote: > Hi Joel, > > The requirements are drawn from a functional perspective with a constraint to avoid binding them specific to a solution. If there are some that you think are solution-specific, then it would be helpful to point those and discuss them. > > The document uses the reference architecture defined in the "architecture and framework" document cited in the draft. That architecture defines a set of functional elements. > > Does the "agreed architecture" you are referring define an architecture distinct than the one cited in the requirements draft? > > Cheers, > Med > >> -----Message d'origine----- >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Envoyé : mercredi 29 janvier 2014 16:53 >> À : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org >> Objet : Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-01.txt >> >> My apologies if I am misreading the document. >> Many of the requirements are couched in terms of SF-Maps and specific >> kinds of IDs. Both of those are aspects of solutions, not requirements. >> I found it very hard to separate the actual requirements from the >> presumption of solution in the draft. >> >> Also, have you checked that the requirements are aligned with the agreed >> architecture? >> >> Yours, >> Joel M. Halpern >> >> On 1/29/14, 10:18 AM, mohamed.boucadair@orange.com wrote: >>> Dear all, >>> >>> An updated version of this draft is available online. A diff to track the >> changes is provided below. >>> >>> Comments and contributions are more than welcome. >>> >>> Cheers, >>> Med >>> >>> -----Message d'origine----- >>> De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de >> internet-drafts@ietf.org >>> Envoyé : mercredi 29 janvier 2014 15:31 >>> À : i-d-announce@ietf.org >>> Objet : I-D Action: draft-boucadair-sfc-requirements-01.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>> >>> >>> Title : Requirements for Service Function Chaining >>> Authors : Mohamed Boucadair >>> Christian Jacquenet >>> Yuanlong Jiang >>> Ron Parker >>> Carlos Pignataro >>> Filename : draft-boucadair-sfc-requirements-01.txt >>> Pages : 13 >>> Date : 2014-01-29 >>> >>> Abstract: >>> This document identifies the requirements for the Service Function >>> Chaining (SFC). >>> >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-01 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-boucadair-sfc-requirements-01 >>> >>> >>> Please note that it may take a couple of minutes from the time of >> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> From mohamed.boucadair@orange.com Thu Jan 30 07:35:41 2014 Return-Path: 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 941E11A0440 for ; Thu, 30 Jan 2014 07:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 3TSWJB7J1Cj6 for ; Thu, 30 Jan 2014 07:35:39 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 601231A03C2 for ; Thu, 30 Jan 2014 07:35:38 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id ACE1F2DC5F2; Thu, 30 Jan 2014 16:35:34 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 8C19A4C0B7; Thu, 30 Jan 2014 16:35:34 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Thu, 30 Jan 2014 16:35:34 +0100 From: To: "Joel M. Halpern" , "sfc@ietf.org" Date: Thu, 30 Jan 2014 16:35:32 +0100 Thread-Topic: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-01.txt Thread-Index: Ac8dzBLI3fjdeXTHRSiArurLc4PzywAAt90A Message-ID: <94C682931C08B048B7A8645303FDC9F36F48634F42@PUEXCB1B.nanterre.francetelecom.fr> References: <20140129143039.19852.70687.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F48634B0A@PUEXCB1B.nanterre.francetelecom.fr> <52E923EF.5030706@joelhalpern.com> <94C682931C08B048B7A8645303FDC9F36F48634C02@PUEXCB1B.nanterre.francetelecom.fr> <52EA6920.6040306@joelhalpern.com> In-Reply-To: <52EA6920.6040306@joelhalpern.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.30.135714 Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-01.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 15:35:41 -0000 Hi Joel, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Joel M. Halpern [mailto:jmh@joelhalpern.com] >Envoy=E9=A0: jeudi 30 janvier 2014 16:01 >=C0=A0: BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org >Objet=A0: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-01.tx= t > >My apologies about the architecture reference. There is no WG agreed >architecture. My talking abou tthat is both wrong and confusing. [Med] No problem ;-) > >The larger point however remains. The requirements as written treat >elements like the SF-Map and the SF-ID as if they are information that >will appear in the data packet.=20 [Med] No. There is no assumption in the requirements I-D that the "Service = Function Identifier" and the "SF Map" will appear in the packet. These term= s are defined as part of the "architecture & framework" draft cited on the = draft. I'm reproducing what is meant by these terms here:=20 o SF Identifier: is a unique identifier that unambiguously identifies a SF within a SFC-enabled domain. SF Identifiers are assigned, configured and managed by the administrative entity that operates the SFC-enabled domain. SF identifiers can be structured as strings; other formats can be used. SF Identifiers are not required to be globally unique nor be exposed to or used by another SF-enabled domain. o SF Map: refers to an ordered list of SF identifiers. Each SF Map is identified with a unique identifier called SF Map Index. As you can see in the requirements I-D, there is no mention of the "SF Map = Index". That would be part of a solution. [Med] It depends where you position the solution vs architecture frontier. = IMHO, it makes sense to use those terms as they can be seen as part of the = reference functional architecture. I >found that to be quite confusing, and it made it hard to determine what >the solution-independent requirements are. We really need such >requirements, particularly from folks like you on the operator side. [Med] That was our motivation when editing this draft. We are very open to = update the document (including removing text that the wg thinks it is not s= olution-independent). BTW, I would really like to see more operators joinin= g us in this effort.=20 > >Yours, >Joel > >On 1/30/14, 1:50 AM, mohamed.boucadair@orange.com wrote: >> Hi Joel, >> >> The requirements are drawn from a functional perspective with a >constraint to avoid binding them specific to a solution. If there are some >that you think are solution-specific, then it would be helpful to point >those and discuss them. >> >> The document uses the reference architecture defined in the "architectur= e >and framework" document cited in the draft. That architecture defines a se= t >of functional elements. >> >> Does the "agreed architecture" you are referring define an architecture >distinct than the one cited in the requirements draft? >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Envoy=E9 : mercredi 29 janvier 2014 16:53 >>> =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org >>> Objet : Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements- >01.txt >>> >>> My apologies if I am misreading the document. >>> Many of the requirements are couched in terms of SF-Maps and specific >>> kinds of IDs. Both of those are aspects of solutions, not requirements= . >>> I found it very hard to separate the actual requirements from the >>> presumption of solution in the draft. >>> >>> Also, have you checked that the requirements are aligned with the agree= d >>> architecture? >>> >>> Yours, >>> Joel M. Halpern >>> >>> On 1/29/14, 10:18 AM, mohamed.boucadair@orange.com wrote: >>>> Dear all, >>>> >>>> An updated version of this draft is available online. A diff to track >the >>> changes is provided below. >>>> >>>> Comments and contributions are more than welcome. >>>> >>>> Cheers, >>>> Med >>>> >>>> -----Message d'origine----- >>>> De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de >>> internet-drafts@ietf.org >>>> Envoy=E9 : mercredi 29 janvier 2014 15:31 >>>> =C0 : i-d-announce@ietf.org >>>> Objet : I-D Action: draft-boucadair-sfc-requirements-01.txt >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>>> >>>> >>>> Title : Requirements for Service Function Chaining >>>> Authors : Mohamed Boucadair >>>> Christian Jacquenet >>>> Yuanlong Jiang >>>> Ron Parker >>>> Carlos Pignataro >>>> Filename : draft-boucadair-sfc-requirements-01.txt >>>> Pages : 13 >>>> Date : 2014-01-29 >>>> >>>> Abstract: >>>> This document identifies the requirements for the Service Functio= n >>>> Chaining (SFC). >>>> >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/ >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-01 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-sfc-requirements-01 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> From linda.dunbar@huawei.com Thu Jan 30 08:05:20 2014 Return-Path: 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 AC08E1A03D4 for ; Thu, 30 Jan 2014 08:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 L8vTwQT-DzuI for ; Thu, 30 Jan 2014 08:05:17 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CC2B31A03AA for ; Thu, 30 Jan 2014 08:05:16 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDC27786; Thu, 30 Jan 2014 16:05:12 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 30 Jan 2014 16:04:47 +0000 Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 30 Jan 2014 16:04:55 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml703-chm.china.huawei.com ([169.254.5.188]) with mapi id 14.03.0158.001; Thu, 30 Jan 2014 08:04:44 -0800 From: Linda Dunbar To: "mohamed.boucadair@orange.com" Thread-Topic: Comments and suggestions to draft-boucadair-sfc-framework-00 Thread-Index: Ac8dF+h8j+p/oQfZTT2XWc7eCXJVWgAb7ZNwABJxH0A= Date: Thu, 30 Jan 2014 16:04:44 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C750E8@dfweml701-chm.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645C74864@dfweml701-chm.china.huawei.com> <94C682931C08B048B7A8645303FDC9F36F48634C0D@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F48634C0D@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.151.152] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645C750E8dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "sfc@ietf.org" Subject: Re: [sfc] Comments and suggestions to draft-boucadair-sfc-framework-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 16:05:20 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645C750E8dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Med, Thanks for the reply. Some additional comments inserted below. Hope you can= incorporate them into 01 version. 1.5 Rationale: First bullet: Does "Dynamic Provisioning" mean the "provisioning of the ser= vice functions" or dynamically steering traffic to service functions? [Med] It refers to the provisioning of the "Service Functions" and "SFC Cla= ssier". [Linda] You don't mean including dynamically provisioning service function = behavior, do you? Provisioning Video Optimizer is so different than provis= ioning Firewall. It will be too much for SFC WG to address the individual s= ervice function behavior. Section 2 Terminology: "SF proxy node: a node, most likely a network node along the data path, to = terminate and encapsulate service layer encapsulation on behalf of legacy s= ervice nodes." [Med] I see the point. I think this is useful to be discussed in Section "1= 0.2. Deployment Models" (http://tools.ietf.org/html/draft-boucadair-sfc-fra= mework-00#section-10.2) [Linda] The section 10.2 in the current 00 version is very brief. You can = consider adding some sections from https://datatracker.ietf.org/doc/draft-d= unbar-sfc-legacy-l4-l7-chain-architecture/, especially the Section 3.3: 1.1. Proxy Node for Legacy Service Functions Section 3.4 of [NSC-Header] describes a scenario that the service nodes are= not aware of service encapsulation header. The term "proxy node" is introd= uced by [NSC-header] as an entity to remove and insert service layer encaps= ulation on behalf of service nodes that are not aware service layer encapsu= lation. Even though Service Nodes can be instantiated anywhere in the network, it i= s not uncommon to have multiple [legacy] service nodes located in close vic= inity with a service chain proxy node, or one to two links away. The follow= ing figure depicts typical network architecture for chaining those service = nodes that are not aware of service layer encapsulation. |1 ----- |n |21 ---- |2m +---+---+ +---+---+ +-+---+ +--+-----+ | Ad | |Content| |Video| |Security| |Insert | | Opt | | Opt | | App | +---+---+ +---+---+ +--+--+ +--+--+--+ : : : : : : : : : : \ / \ / +--------------+ +--------+ +---------+ -- >| Chain | ->| Proxy |---------> | Proxy | ----> |classification| |Node-1 | | Node-i | +--------------+ +----+---+ +----+--+-+ |-- | | V +---> +--------+ | Proxy | | -j |-----> +--------+ Figure 1 Chaining existing service nodes When there are multiple service nodes located in the vicinity of a service = chain "proxy node", the Proxy node needs to steer designated traffic to the= designated service functions. The service chain proxy nodes can be standalone devices, or can be embedded= with routers or switches in the network. Overlay tunnels are expected to c= onnect the "proxy nodes" together. Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F645C750E8dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Med,

 

Thanks for the reply. = Some additional comments inserted below. Hope you can incorporate them into= 01 version.

 

 

1.5 Rationale:

First bullet:= Does "Dynamic Provisioning" mean the "provisioning of the s= ervice functions" or dynamically steering traffic to service functions= ?

[Med] It refers to the provisioning of= the “Service Functions” and “SFC Classier”.

 

[Linda] You don’= t mean including dynamically provisioning service function behavior, do you= ?  Provisioning Video Optimizer is so different than provisioning Fire= wall. It will be too much for SFC WG to address the individual service function behavior.

 

 

 

 

Section 2 Terminology:

“SF proxy node: = a node, most likely a network node along the data path, to terminate and en= capsulate service layer encapsulation on behalf of legacy service nodes.= 221;

[Med] I see the point. I think this is= useful to be discussed in Section “10.2. Deployment Models” (<= a href=3D"http://tools.ietf.org/html/draft-boucadair-sfc-framework-00#secti= on-10.2">http://tools.ietf.org/html/draft-boucadair-sfc-framework-00#sectio= n-10.2)

 

[Linda] The section 10= .2 in the current  00 version is very brief. You can consider adding s= ome sections from https://datatracker.ietf.org/doc/draft-dunbar-sf= c-legacy-l4-l7-chain-architecture/, especially the Section 3.3:=

 

1.1. Proxy Node for Legacy Service Functions

Section 3.4 of [NSC-Header] describes a scenario tha= t the service nodes are not aware of service encapsulation header. The term= “proxy node” is introduced by [NSC-header] as an entity to rem= ove and insert service layer encapsulation on behalf of service nodes that are not aware service layer encapsulation.

Even though Service Nodes can be instantiated anywhe= re in the network, it is not uncommon to have multiple [legacy] service nod= es located in close vicinity with a service chain proxy node, or one to two= links away. The following figure depicts typical network architecture for chaining those service nodes that= are not aware of service layer encapsulation.  

 

        &nbs= p;            |= 1  -----   |n        |21&= nbsp;  ---- |2m

        &nbs= p;        +---+---+ &nb= sp; +---+---+   +-+---+   += --+-----+

        &nbs= p;        | Ad    | =   |Content|   |Video|   |Security|

        &nbs= p;        |Insert |   | Opt&nb= sp;  |   | Opt |   | App    |<= /o:p>

        &nbs= p;        +---+---+ &nb= sp; +---+---+   +--+--+   += --+--+--+

        &nbs= p;            : = ;          :    = ;      :      &= nbsp;  :  :

        &nbs= p;            : = ;          :   =        :      &= nbsp;  :  :

        &nbs= p;             = \         /    =         \     &= nbsp; /

    +--------------+ &nb= sp; +--------+         = ;    +---------+

-- >| Chain      &n= bsp; | ->| Proxy  |--------->   | Proxy   | = ---->

    |classification|   |Nod= e-1  |          &nbs= p;  | Node-i  |

    +--------------+ &nb= sp; +----+---+        &= nbsp;    +----+--+-+

        &nbs= p;            &= nbsp;        |--    =             &nb= sp; |  |

        &nbs= p;            &= nbsp;        V    &n= bsp;            = ;   +--->

        &nbs= p;            &= nbsp;   +--------+

        &nbs= p;            &= nbsp;   | Proxy  |

        &nbs= p;            &= nbsp;   |   -j   |----->

        &nbs= p;            &= nbsp;   +--------+

 

Figure 1           = ;             Chaining existing service nodes

When there are multiple service nodes located in the= vicinity of a service chain “proxy node”, the Proxy node needs= to steer designated traffic to the designated service functions.

The service chain proxy nodes can be standalone devi= ces, or can be embedded with routers or switches in the network. Overlay tu= nnels are expected to connect the “proxy nodes” together.<= /o:p>

 

 

 

 

Linda Dunbar

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645C750E8dfweml701chmchi_-- From mohamed.boucadair@orange.com Thu Jan 30 22:42:55 2014 Return-Path: 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 2997D1A054F for ; Thu, 30 Jan 2014 22:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 QLI1Val0hefD for ; Thu, 30 Jan 2014 22:42:51 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id E198D1A054D for ; Thu, 30 Jan 2014 22:42:50 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 0C1FC22C5B1; Fri, 31 Jan 2014 07:42:46 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id E56A923808E; Fri, 31 Jan 2014 07:42:45 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Fri, 31 Jan 2014 07:42:45 +0100 From: To: Linda Dunbar Date: Fri, 31 Jan 2014 07:42:43 +0100 Thread-Topic: Comments and suggestions to draft-boucadair-sfc-framework-00 Thread-Index: Ac8dF+h8j+p/oQfZTT2XWc7eCXJVWgAb7ZNwABJxH0AAH1BP8A== Message-ID: <94C682931C08B048B7A8645303FDC9F36F48635019@PUEXCB1B.nanterre.francetelecom.fr> References: <4A95BA014132FF49AE685FAB4B9F17F645C74864@dfweml701-chm.china.huawei.com> <94C682931C08B048B7A8645303FDC9F36F48634C0D@PUEXCB1B.nanterre.francetelecom.fr> <4A95BA014132FF49AE685FAB4B9F17F645C750E8@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C750E8@dfweml701-chm.china.huawei.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36F48635019PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.31.25115 Cc: "sfc@ietf.org" Subject: Re: [sfc] Comments and suggestions to draft-boucadair-sfc-framework-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 06:42:55 -0000 --_000_94C682931C08B048B7A8645303FDC9F36F48635019PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Linda, Please see inline. Cheers, Med De : Linda Dunbar [mailto:linda.dunbar@huawei.com] Envoy=E9 : jeudi 30 janvier 2014 17:05 =C0 : BOUCADAIR Mohamed IMT/OLN Cc : sfc@ietf.org Objet : RE: Comments and suggestions to draft-boucadair-sfc-framework-00 Med, Thanks for the reply. Some additional comments inserted below. Hope you can= incorporate them into 01 version. 1.5 Rationale: First bullet: Does "Dynamic Provisioning" mean the "provisioning of the ser= vice functions" or dynamically steering traffic to service functions? [Med] It refers to the provisioning of the "Service Functions" and "SFC Cla= ssier". [Linda] You don't mean including dynamically provisioning service function = behavior, do you? Provisioning Video Optimizer is so different than provis= ioning Firewall. It will be too much for SFC WG to address the individual s= ervice function behavior. [Med] What is meant is SFC-specific provisioning. Note, the same entity res= ponsible for provisioning SFC-specific features may be responsible for prov= isioning SF-specific features, but IMHO that is out of scope of SFC WG. Section 2 Terminology: "SF proxy node: a node, most likely a network node along the data path, to = terminate and encapsulate service layer encapsulation on behalf of legacy s= ervice nodes." [Med] I see the point. I think this is useful to be discussed in Section "1= 0.2. Deployment Models" (http://tools.ietf.org/html/draft-boucadair-sfc-fra= mework-00#section-10.2) [Linda] The section 10.2 in the current 00 version is very brief. You can = consider adding some sections from https://datatracker.ietf.org/doc/draft-d= unbar-sfc-legacy-l4-l7-chain-architecture/, especially the Section 3.3: [Med] Will consider adding that text. Thanks. 1.1. Proxy Node for Legacy Service Functions Section 3.4 of [NSC-Header] describes a scenario that the service nodes are= not aware of service encapsulation header. The term "proxy node" is introd= uced by [NSC-header] as an entity to remove and insert service layer encaps= ulation on behalf of service nodes that are not aware service layer encapsu= lation. Even though Service Nodes can be instantiated anywhere in the network, it i= s not uncommon to have multiple [legacy] service nodes located in close vic= inity with a service chain proxy node, or one to two links away. The follow= ing figure depicts typical network architecture for chaining those service = nodes that are not aware of service layer encapsulation. |1 ----- |n |21 ---- |2m +---+---+ +---+---+ +-+---+ +--+-----+ | Ad | |Content| |Video| |Security| |Insert | | Opt | | Opt | | App | +---+---+ +---+---+ +--+--+ +--+--+--+ : : : : : : : : : : \ / \ / +--------------+ +--------+ +---------+ -- >| Chain | ->| Proxy |---------> | Proxy | ----> |classification| |Node-1 | | Node-i | +--------------+ +----+---+ +----+--+-+ |-- | | V +---> +--------+ | Proxy | | -j |-----> +--------+ Figure 1 Chaining existing serv= ice nodes When there are multiple service nodes located in the vicinity of a service = chain "proxy node", the Proxy node needs to steer designated traffic to the= designated service functions. The service chain proxy nodes can be standalone devices, or can be embedded= with routers or switches in the network. Overlay tunnels are expected to c= onnect the "proxy nodes" together. Linda Dunbar --_000_94C682931C08B048B7A8645303FDC9F36F48635019PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Linda,

 

Please see inline.

 <= /o:p>

Cheers,

Med

 

De : = Linda Dunbar [mailto:linda.dunbar@huawei.com]
Envoy=E9 : je= udi 30 janvier 2014 17:05
=C0 : BOUCADAIR Mohamed IMT/OLNCc : sfc@ietf.org
Objet : RE: Comments and sugg= estions to draft-boucadair-sfc-framework-00

 

Med,

 

Thanks for the reply. Some additional comments i= nserted below. Hope you can incorporate them into 01 version.

 

 

1.5 Rationale:

First bullet: Does "Dynamic Provisioning" mean the "provi= sioning of the service functions" or dynamically steering traffic to s= ervice functions?

[Med] It re= fers to the provisioning of the “Service Functions” and “= SFC Classier”.

 

= [Linda] You don’t mean including dynami= cally provisioning service function behavior, do you?  Provisioning Vi= deo Optimizer is so different than provisioning Firewall. It will be too mu= ch for SFC WG to address the individual service function behavior.

[Med] What is meant is SFC-specific = provisioning. Note, the same entity responsible for provisioning SFC-specif= ic features may be responsible for provisioning SF-specific features, but I= MHO that is out of scope of SFC WG. =A0

<= p class=3DMsoNormal style=3D'margin-left:36.0pt'> 

Section 2 Terminology:

“SF proxy node: a node, most likely a = network node along the data path, to terminate and encapsulate service laye= r encapsulation on behalf of legacy service nodes.”

[Med] I see the point. I think this is useful to = be discussed in Section “10.2. Deployment Models” (ht= tp://tools.ietf.org/html/draft-boucadair-sfc-framework-00#section-10.2)=

 

[Linda] The section 10.2 in the current  00 ver= sion is very brief. You can consider adding some sections from https://datatracker.ietf.org/doc/draft-dunbar-sfc-legacy-l4-= l7-chain-architecture/, especially the Se= ction 3.3:

[Med] Will conside= r adding that text. Thanks.

 

1.1. Proxy Node for Legac= y Service Functions

Section 3.4 of = [NSC-Header] describes a scenario that the service nodes are not aware of s= ervice encapsulation header. The term “proxy node” is introduce= d by [NSC-header] as an entity to remove and insert service layer encapsula= tion on behalf of service nodes that are not aware service layer encapsulat= ion.

Even though Service Nodes can be in= stantiated anywhere in the network, it is not uncommon to have multiple [le= gacy] service nodes located in close vicinity with a service chain proxy no= de, or one to two links away. The following figure depicts typical network = architecture for chaining those service nodes that are not aware of service= layer encapsulation.  

 = ;

      &n= bsp;            = ;  |1  -----   |n     &nb= sp;  |21   ---- |2m

 = ;            &n= bsp;   +---+---+   +---+---+   +-+---+ &= nbsp; +--+-----+

    = ;             |= Ad    |   |Content|   |Video| &nbs= p; |Security|

    &n= bsp;            |Ins= ert |   | Opt   |   | Opt |   | App=     |

   &= nbsp;           &nbs= p; +---+---+   +---+---+   +--+--+   +--+--+-= -+

      &= nbsp;           &nbs= p;  :           :&nb= sp;         :   &nbs= p;     :  :

&nb= sp;            =         :     &= nbsp;     :       &n= bsp;  :         :  :=

       &n= bsp;            = ;  \         /  &nbs= p;         \    = ;   /

    +----= ----------+   +--------+       = ;      +---------+

-- >| Chain        | ->| Proxy=   |--------->   | Proxy   | ---->=

    |classification|   |N= ode-1  |          &n= bsp;  | Node-i  |

  =   +--------------+   +----+---+     = ;        +----+--+-+

          = ;            &n= bsp;       |--     &= nbsp;            |&n= bsp; |

     &nb= sp;            =             V &= nbsp;           &nbs= p;      +--->

            &= nbsp;            +--= ------+

     &n= bsp;            = ;       | Proxy  |

          &= nbsp;           &nbs= p;  |   -j   |----->

           =             &nb= sp; +--------+

 

Figure 1         &nb= sp;            =             &nb= sp;          Chaining existing service nodes

When there are multiple service nodes located in the vicinity of a se= rvice chain “proxy node”, the Proxy node needs to steer designa= ted traffic to the designated service functions.

The service chain proxy nodes can be standalone devices, or can b= e embedded with routers or switches in the network. Overlay tunnels are exp= ected to connect the “proxy nodes” together.

 

=

 =

 

 

Linda Dunbar

 =

= --_000_94C682931C08B048B7A8645303FDC9F36F48635019PUEXCB1Bnante_--